GuideMatching

URL matching and conditions

Four match modes, request methods and conditional hits by query, header, JSON body or GraphQL operation.

Every rule starts with a match: a request method plus a URL pattern in one of four modes. Rules are evaluated in order — projects top to bottom, rules within a project top to bottom — and the first enabled rule that matches wins.

Match modes

Mode	Pattern example	Behaviour
Contains	`/api/users`	Matches when the full URL or the path contains the string
Path params	`/api/orders/:id`	Matches segment by segment; each `:name` becomes a parameter readable in a JS Hook as `context.req.params.id`
Exact	`/api/users`	The full URL or the path must be exactly equal (query string included when you type one)
Regex	`/users/\d+$`	A regular expression tested against the full URL

Use ALL to match any method, or pick GET / POST / PUT / PATCH / DELETE / HEAD / OPTIONS. fetch requests and XHR requests are treated the same way.

A pattern without a leading / or scheme is matched as a plain substring — users also hits /api/users and /v2/users-legacy. Prefer /api/users.

Conditions

Conditions narrow a match further. All conditions must match for the rule to hit; there is no OR group. Four sources are supported:

Source	Key example	Notes
Query	`type`	A URL query parameter, e.g. `type` equals `vip`. Repeated parameters are compared as a list.
Header	`x-token`	A request header; useful for `authorization`, `content-type` or custom debug headers.
Body	`data.type`	A JSON request body field. Dot paths reach nested fields; arrays use `data.list.0.id`.
GraphQL	`operationName`	Only accepts `operationName`, `operationType`, `query` and `variables` (including `variables.*` dot paths).

Each condition supports four operators: equals, contains, exists and regex. exists only checks that the key is present, whatever its value.

The condition block lives under the URL; the test box reports ✓ Matched with the extracted path params.

Test a URL

The test URL box under the conditions verifies matching instantly: it shows ✓ Matched (with the extracted path params) or ✗ No match. It is a pure string test — it does not send a request, so it cannot evaluate conditions that need real traffic.

Header, body and GraphQL conditions need a real request and are skipped in the panel test (marked in the result). Use the request log to confirm those cases.

Ordering and shadowing

Because the first match wins, a broad rule placed above a narrow one hides it. Two habits avoid most surprises: put specific rules (path params, exact URLs) above generic ones (Contains on a common prefix), and use conditions instead of duplicating rules for every variant.

What is matched against

The full URL including scheme, host, path and query — for all four modes.
The path only as a fallback, so /api/users matches https://api.example.com/api/users?page=2.
Fragments (#…) are never part of the request URL and are ignored.
Case sensitivity is preserved; add a regex with i-style alternatives if you need case-insensitive matching.

Stuck, or need something clarified? support@mockrew.com·Terms of Service