Why teams use GoDizzy
AI agents depend on APIs that fail in messy ways: timeouts, malformed payloads, partial results, schema drift, and rate limits. GoDizzy lets you reproduce those conditions on demand without rewriting the agent.Stable gateway URL
Every route collection gets its own GoDizzy URL. Your agent keeps calling that URL while you change behavior in the dashboard.
Mock or proxy per route
Each routing rule can return a fixture or forward to a live backend.
Latency and failures
Simulate slow responses, broken schemas, and error codes before they happen in production.
No client-code rewrites
Most routing changes happen in GoDizzy, not in your agent config or application code.
Core building blocks
Environments — GoDizzy uses a shared production environment and a private development environment per userGoDizzy uses a shared production environment and a private development environment per user. Environments — GoDizzy uses a shared production environment and a private development environment per user. Route collections — A collection is a gateway with a generated subdomain, a target endpoint, and a set of routing rules. Routing rules — Rules match by HTTP method and path, then either mock or proxy. Higher-priority rules win first. Mock responses — Return deterministic JSON fixtures, custom status codes, headers, and optional latency. Proxy response shaping — Forward to a real upstream and optionally override status, headers, or JSON body fields before the response goes back to your agent. Mock webhooks — Fire outbound callbacks after serving a mock response so you can test async integrations. MCP — GoDizzy exposes an MCP server for environments, collections, and rules. See MCP.Get started
Quick Start
Create a development environment, a collection, and your first rule.
How It Works
Learn the routing model, default rule behavior, and request flow.
MCP
Connect an MCP client and manage environments, collections, and rules programmatically.
Mock Responses
Build deterministic fixtures with templates, latency, and rollback.
Stable gateway URL
Every route collection gets its own GoDizzy URL. Your agent keeps calling that URL while you change behavior in the dashboard.
Mock or proxy per route
Each routing rule can return a fixture or forward to a live backend.
Latency and failures
Simulate slow responses, broken schemas, and error codes before they happen in production.
No client-code rewrites
Most routing changes happen in GoDizzy, not in your agent config or application code.
Core building blocks
Environments — GoDizzy uses a shared production environment and a private development environment per user. GoDizzy uses a shared production environment and a private development environment per userRoute collections — A collection is a gateway with a generated subdomain, a target endpoint, and a set of routing rules. Routing rules — Rules match by HTTP method and path, then either mock or proxy. Higher-priority rules win first. Mock responses — Return deterministic JSON fixtures, custom status codes, headers, and optional latency. Proxy response shaping — Forward to a real upstream and optionally override status, headers, or JSON body fields before the response goes back to your agent. Mock webhooks — Fire outbound callbacks after serving a mock response so you can test async integrations. MCP — GoDizzy exposes an MCP server for environments, collections, and rules. See MCP.Quick Start
Create a development environment, a collection, and your first rule.
How It Works
Learn the routing model, default rule behavior, and request flow.
MCP
Connect an MCP client and manage environments, collections, and rules programmatically.
Mock Responses
Build deterministic fixtures with templates, latency, and rollback.