Match Strategies

When a page sends a request, reqable evaluates enabled rules in list order and uses the first matching rule.

Four strategies

Precise match (default)

The strictest strategy. The normalized URL, including its query, and the request-body fingerprint must both match. Configured timestamp parameters are removed first.

Use it when: the same endpoint must return different mocks for different request parameters.

Request: POST /api/order/create  body: {"type": "A"}
Request: POST /api/order/create  body: {"type": "B"}
→ Each request matches its own rule and response.

Smart match

Attempts a precise match first. If none exists, it falls back to endpoint matching and ignores the query and request body.

Use it when: replaying captured traffic. Exported requests retain precise responses, while uncovered variations can fall back to the same endpoint rule.

Exported:   GET /api/list?page=1&size=10 → Precise exported response
Uncovered:  GET /api/list?page=2&size=20 → Endpoint fallback to the same mock

Endpoint match

Matches only the URL path and ignores query parameters and the request body. This is the broadest built-in strategy.

Use it when: every request to one endpoint should receive the same response.

GET /api/list?page=1  → Match
GET /api/list?page=5  → Match; the query is ignored

Custom match

Combine a URL mode with optional request-body comparison when the built-in strategies are not sufficient.

Select Custom match in the details view, then open Custom match rules.

URL mode

Mode	Compared value	Typical use
Full URL	Complete URL, including query and hash.	Different queries under the same path need different mocks.
Endpoint URL	Path only; query and hash are ignored.	Different parameters should share one mock.
Contains	Matches if the current URL contains the configured fragment.	Dynamic IDs or prefixes in the path.
Regex	Tests the URL string with a regular expression.	Complex path rules. Enter the expression without wrapping / characters.

Contains and regex modes require an additional pattern.

Request-body comparison

Setting	Behavior
Off (default)	A matching URL is enough.
On	The request-body fingerprint must also match.

Ignore domain

Ignore domain is an independent switch that applies to every strategy.

Setting	URL comparison
Off	Compare the origin and path, plus query/hash when required by the URL mode.
On	Compare the path and other required URL parts, but not the origin.

Use it to share one rule across local, test, staging, and production origins that expose the same endpoint path.

Rule URL: https://test.example.com/api/order/list
Ignore domain off → Only the test origin matches
Ignore domain on  → localhost, test, and staging can all match the same path

TIP

Ignoring the domain changes only the URL comparison. For example, Precise + Ignore domain still compares the query and request body.

Whether new rules ignore domains by default is controlled by Settings → Default Mock strategy. It is enabled in the initial defaults.

Matching details

URL normalization

Before matching, reqable:

• Resolves relative paths to absolute URLs.
• Removes timestamp parameters configured in Settings, such as _t and timestamp.

Query ordering depends on the mode:

• Precise matching and request fingerprints sort query parameters, so order alone does not cause a miss.
• Contains and regex modes use the normalized URL without reordering the remaining parameters.
• Endpoint matching does not compare the query.

Request-body fingerprint

When body comparison is enabled:

• A JSON body is parsed and serialized into a stable representation before hashing.
• Other body types use their original content.

Method matching

Each rule can either:

• Match all methods, ignoring whether the request is GET, POST, PUT, or DELETE.
• Match one method, using the HTTP method recorded when the rule was created.

Default strategy

Configure defaults for new rules in Settings → Default Mock strategy.

After changing a default, select Apply to current group or Apply to all mocks to update existing rules.