Skip to main content
GoDizzy is a programmable gateway that sits between your AI agent and its tools. Every request your agent makes passes through GoDizzy, which evaluates your routing rules and decides whether to return a fixture or forward the request to a real backend.

​
The data model

GoDizzy organizes your configuration in a four-level hierarchy: 
Organization
  └── Environments  (production | staging | development)
        └── Route Collections  (one stable gateway URL each)
              └── Routing Rules  (match + action, evaluated in priority order)
Each level has a distinct purpose.

​
Organization

Your organization is the top-level account, shared across your team. All members of an organization can see and edit production and staging environments. Development environments are personal — only their creator can see them.

​
Environments

Environments isolate routing configurations from each other. An organization can have:
  • One production environment — shared, visible to all org members
  • One staging environment — shared, visible to all org members
  • One development environment per user — personal sandbox, only visible to its creator
Switching environments never changes your agent’s URL. Each environment’s rules are completely independent, so you can run mock fixtures in development while staging proxies to a real backend.

​
Route collections

A route collection is a group of routing rules with a single target endpoint — the base URL GoDizzy uses when proxying requests. Each collection gets a stable subdomain: 
https://<subdomain>.godizzy.dev
This URL is permanent. Whether your rules are returning mocks or proxying to a live server, your agent always calls the same address. You change the behavior in the dashboard.
You can copy a collection from one environment to another. This lets you promote a working development configuration to staging without recreating every rule by hand.

​
Routing rules

Rules are the core of GoDizzy. Each rule defines:
  • Match criteria — an HTTP method (or * for any method) and a path pattern
  • Priority — a number; higher values are evaluated first
  • Action — mock or proxy

​
How rules are evaluated

When a request arrives at your gateway URL, GoDizzy evaluates your rules in priority order — highest priority number first. The first rule whose method and path both match the incoming request wins. No further rules are evaluated after a match.
1

Request arrives

Your agent sends a request to https://<subdomain>.godizzy.dev/api/payments/charge. GoDizzy identifies the route collection from the subdomain.
2

Rules evaluated in priority order

GoDizzy checks each rule from highest priority to lowest. For each rule it asks: does the HTTP method match, and does the path pattern match the request path?
3

First match wins

The first rule that satisfies both criteria determines the response. GoDizzy stops evaluating once a rule matches.
4

Default rule catches the rest

Every collection has one default rule that cannot be deleted. It matches any method and any path, so requests that don’t match a specific rule always have a defined behavior. By default, the default rule proxies to the collection’s target endpoint.

​
Path matching

Rule paths support three matching styles:
StyleExample rule pathMatches
Exact/api/usersOnly /api/users
Parameter segment/api/users/:id/api/users/123, /api/users/abc, etc.
Wildcard*Any path
Query parameters are not considered during matching. A request to /api/users?page=2 matches a rule with path /api/users. Path matching is case-sensitive. Method matching is case-insensitive.

​
Mock vs proxy

Each routing rule has one of two actions.
When a rule’s action is mock, GoDizzy returns the fixture you configured — no request is ever forwarded to your backend.A mock response includes:
  • A status code (for example, 200, 429, 500)
  • Optional response headers
  • A JSON body
  • An optional latency range (min and max milliseconds) — GoDizzy delays the response by a random amount within the range
Mock responses are versioned. Every time you update the fixture, the previous version is preserved. You can view the history and revert to any prior version at any time.
You switch a rule between mock and proxy in the dashboard. The rule’s URL never changes.

​
Request flow

Here’s how a single request travels through GoDizzy: 
Agent
  │
  │  GET https://abc12345.godizzy.dev/api/search
  ▼
GoDizzy gateway
  │
  ├── Look up route collection by subdomain
  ├── Load routing rules, sorted by priority (highest first)
  ├── Evaluate rules: method match + path match
  ├── First match found → check action
  │     ├── mock  → return configured fixture (+ optional latency)
  │     └── proxy → forward to target endpoint, return response
  │
  └── No match → default rule → proxy to target endpoint
If the subdomain doesn’t correspond to any active collection, GoDizzy returns a 404 with code COLLECTION_NOT_FOUND. If no routing rule matches the request, GoDizzy returns a 404 with code NO_MATCHING_ROUTE. If the target endpoint is unreachable on a proxy rule, GoDizzy returns 502 with code PROXY_ERROR.

​
Error responses

GoDizzy returns structured JSON for all gateway-level errors: 
{
  "error": {
    "code": "COLLECTION_NOT_FOUND",
    "message": "No collection found for subdomain: your-collection"
  }
}
Common error codes:
CodeHTTP statusMeaning
COLLECTION_NOT_FOUND404The subdomain doesn’t match any collection
NO_MATCHING_ROUTE404No rule matched the incoming request
PROXY_ERROR502The target endpoint returned an error or was unreachable
INTERNAL_ERROR500An unexpected error occurred

​
What doesn’t require agent changes

The following actions change routing behavior without any modification to your agent:
  • Toggling a rule between mock and proxy
  • Updating a mock fixture (including rollback to a previous version)
  • Changing latency ranges
  • Adjusting rule priority
  • Adding or removing rules
  • Switching between environments (if you configure each environment separately)
Your agent always calls the same subdomain URL. GoDizzy handles the rest.

​
Learn more

Environments

Production, staging, and per-user development environments in detail.

Route Collections

Subdomains, target endpoints, and collection copying.

Routing Rules

Method and path matching, priority, and the default rule.

Mock vs Proxy

When to use each action and how to switch between them.