> ## Documentation Index
> Fetch the complete documentation index at: https://docs.godizzy.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Routing Rules
> Routing rules determine how GoDizzy handles each incoming request — by matching on HTTP method and path, then either mocking or proxying.
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:
An HTTP method (or wildcard) and a path pattern (exact, parameterized, or wildcard). Both must match for the rule to trigger.
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.
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.
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 value | Matches |
| ------------ | ---------------------- |
| `GET` | Only `GET` requests |
| `POST` | Only `POST` requests |
| `PUT` | Only `PUT` requests |
| `DELETE` | Only `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:
| Priority | Method | Path | Action | Purpose |
| -------- | ------ | ----------------- | ------- | ------------------------------------------ |
| 100 | `POST` | `/v1/charges` | `mock` | Return a fixture charge response |
| 90 | `GET` | `/v1/charges/:id` | `mock` | Return a fixture charge by ID |
| 80 | `POST` | `/v1/refunds` | `mock` | Simulate a 429 rate-limit response |
| 10 | `*` | `*` | `proxy` | Default: 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.