Skip to main content
Routing rules are the decision layer inside a route collection. When a request arrives at your collection’s gateway URL, GoDizzy evaluates each rule in priority order until one matches, then executes that rule’s action (mock or proxy). The first matching rule wins — no further rules are evaluated.

​
Rule components

Every routing rule has four parts:

Match criteria

An HTTP method (or wildcard) and a path pattern (exact, parameterized, or wildcard). Both must match for the rule to trigger.

Priority

A number that controls evaluation order. Higher numbers run first. Rules with the same priority can match in any order — use distinct priorities to be explicit.

Action

Either mock (return a configured fixture) or proxy (forward to the collection’s target endpoint). You can switch between them with the toggle in the dashboard.

Configuration

For mock rules: response status, headers, body, and latency range. For proxy rules: optional response shaping (status, headers, body transforms).

​
Method matching

The method field on a rule can be a specific HTTP verb or a wildcard:
Method valueMatches
GETOnly GET requests
POSTOnly POST requests
PUTOnly PUT requests
DELETEOnly DELETE requests
*Any HTTP method
Method matching is case-insensitive.

​
Path matching

Path patterns support three styles:
The rule path must match the incoming request path character-for-character. Query parameters are ignored.
Rule path:    /api/users
Matches:      /api/users
              /api/users?page=2   ← query params ignored
No match:     /api/users/123
              /api/admins
Use :param segments to match variable path components. Useful for resource IDs.
Rule path:    /api/users/:id
Matches:      /api/users/123
              /api/users/abc-def
No match:     /api/users
              /api/users/123/orders
A * path matches any request path, regardless of depth or content.
Rule path:    *
Matches:      /api/users
              /api/orders/456
              /health
              /anything/at/all
Wildcards are most useful for the default rule (which uses *) or for catch-all rules that proxy everything below a certain point.
Path matching is case-sensitive. Query parameters are never considered during matching.

​
Priority and evaluation order

Rules are evaluated from highest priority to lowest. The first rule whose method and path both match the incoming request is applied — GoDizzy stops evaluating after that. 
Priority 100 → evaluated first
Priority 50  → evaluated second
Priority 10  → evaluated third
Priority 0   → default rule, evaluated last
If you have two rules that could both match a request, give the more specific one a higher priority number.

​
Example rule set

Here’s what a typical collection’s rules might look like for a payments API:
PriorityMethodPathActionPurpose
100POST/v1/chargesmockReturn a fixture charge response
90GET/v1/charges/:idmockReturn a fixture charge by ID
80POST/v1/refundsmockSimulate a 429 rate-limit response
10**proxyDefault: forward everything else to Stripe
With these rules in place:
  • A POST /v1/charges request triggers rule 100 and gets back a mock fixture.
  • A GET /v1/charges/ch_abc123 triggers rule 90 and gets back a mock charge.
  • A GET /v1/customers doesn’t match rules 100, 90, or 80, so it falls through to the default rule and is proxied to https://api.stripe.com.

​
The default rule

Every collection has exactly one default rule. It matches all methods and all paths (*) and is always the lowest-priority rule in the collection. If no other rule matches an incoming request, the default rule handles it.
The default rule cannot be deleted. It acts as a guaranteed fallback so that no request is left unhandled. You can change its action between mock and proxy, but you cannot remove it.
When a new collection is created, the default rule is set to proxy, which means all traffic is forwarded to the collection’s target endpoint until you add more specific rules.

​
Soft deletion

Deleting a rule removes it from your dashboard and excludes it from routing decisions. The data is preserved and recoverable — contact support if you need to restore an accidentally deleted rule.