Map Local

A Map Local rule answers a matching request from inside the app instead of from the network: the request never reaches the server, and the client gets the status, headers, and body you wrote.

Rules live in their own window, opened from the Tools menu (Cmd/Ctrl + Shift + M). A rule can also be created from a captured request, which pre-fills it with the response that actually came back — usually the fastest way to write one.

Matching

A rule is matched against the full URL — scheme, host, path, and query — using a wildcard or a regular expression, and can be limited to specific methods.

Wildcards:

Token	Matches
*	any characters except / — one path segment
**	any characters, including / — any path
?	a single character

A wildcard pattern has to match the whole URL, so */api/users/* is anchored at both ends. A regular expression is used as written and matches anywhere in the URL unless you anchor it yourself with ^ and $. A pattern can be tried against a sample URL before the rule is saved.

Default ports are normalised on both sides, so https://example.com/v1 matches a captured https://example.com:443/v1.

CONNECT cannot be targeted: a stored body is not a valid answer to a tunnel request. Use a breakpoint if you need to act on tunnel setup.

The response

A rule carries a status code (100–599), a set of headers — duplicates allowed, and each one can be switched off individually — and a body, which can be written as JSON, text, or HTML, or edited as a raw HTTP/1.x message.

It can also carry a delay of up to 60 seconds, applied before the response is sent.

Because the response is assembled from the rule rather than forwarded from a server, a few headers are corrected on the way out:

• Content-Length is recomputed from the stored body;
• Content-Encoding, Transfer-Encoding, ETag, and Content-MD5 are dropped — they describe bytes that never existed;
• hop-by-hop headers are dropped;
• for 1xx, 204, and 304 the body is dropped as well.

When a rule is created from a captured request, the stored headers are limited to the ones the mock will really send: Content-Encoding and Date are left out, because the captured body is stored decompressed.

Behaviour

• If several rules match, the most recently created one wins.
• A mocked request is still recorded, and is marked as answered by a rule. A rule's delay is visible while it waits.
• Rules are resolved before breakpoints, so a URL covered by both is mocked and never pauses.
• A delay holds up only its own request; concurrent requests are unaffected. If the client gives up during the delay, the request is recorded as failed.
• The bypass list is checked first: a rule cannot answer a request to a host that is not being intercepted.

Limitations

• WebSocket upgrades and requests imported from a HAR file cannot be used to pre-fill a rule.
• An SSE request can have a rule, but it answers the next request for that URL with an ordinary response rather than a stream, and nothing is pre-filled as its body.
• Bodies over 8 MB are not opened for editing; they are kept as they are and can be saved to a file. A body with a single line longer than 128 KB is shown wrapped and read-only — the stored bytes stay unchanged either way.

Rules and their bodies are kept in an encrypted local database.