Match Rules

Match rules let you conditionally route an incoming request to a specific scenario based on its content — without changing any client code.

A scenario with match rules is served only when all of its rules pass. If none match, the default scenario is used as a fallback.

Rule structure

Each rule has four fields:

Adding match rules

On the scenario editor, click + Add Rule. A new row appears:

[source ▾]  [key]  [op ▾]  [value]  [×]

Multiple rules on the same scenario use AND logic — all rules must pass.

Source types

query — URL query parameter

GET /api/mock/products?type=premium

Rule: source=query, key=type, op=eq, value=premium

body — Request body field

{ "user": { "role": "admin" } }

Rule: source=body, key=user.role, op=eq, value=admin

Nested fields use dot notation. Any depth is supported.

header — HTTP header

X-Tenant: enterprise

Rule: source=header, key=x-tenant, op=eq, value=enterprise

Header keys are case-insensitive.

path — Path parameter

For an endpoint with path pattern /users/{id}:

GET /api/mock/users/42

Rule: source=path, key=id, op=eq, value=42

Operations

Priority

When multiple scenarios have match rules that could all match the same request, priority determines which one wins. Scenarios with lower priority numbers are evaluated first.

Set priority in the scenario editor. A priority of 0 (default) means all conditional scenarios are evaluated in the order they were created.

Example

A /api/products endpoint with three scenarios:

Request GET /api/mock/products?type=premium → served by premium-list
Request with body.user.role = admin → served by admin-view
All other requests → served by default

Edge cases