Mockingbird — Help & Guide

Hold, edit, and mock HTTP traffic for one tab — from a side panel, with no backend.

New here? Read Quick start, then jump to Mocking or Breakpoints. Everything runs locally — nothing leaves your machine (see the Privacy Policy).

Quick start

Mockingbird works on one tab at a time — the tab you “arm.”

  1. Open the page you want to debug.
  2. Click the Mockingbird toolbar icon. The side panel opens and Chrome shows a yellow “Mockingbird is debugging this browser” banner — that’s normal and expected.
  3. Interact with the page. Requests stream into the Traffic tab.
  4. To stop, click Disarm (bottom of the panel) or close the panel.
The debug banner is unavoidable — pausing and rewriting live traffic requires Chrome’s debugger. It appears only while a tab is armed.

Capturing & inspecting

Every request the armed tab makes appears newest-first: method, path, host, status, and duration. Click a row to open its detail — request line, query params, headers, response/request bodies (pretty-printed JSON), and a timing breakdown.

Mocking an endpoint

A mock returns a synthetic response without touching the network. Fastest path:

  1. Right-click a request → Mock this. The rule form opens pre-filled. (If the real body wasn’t captured and it’s a GET, Mockingbird fetches it in the background to seed the editor.)
  2. Edit status, headers, and body. Hit Format JSON to tidy/validate the body.
  3. Save. The row now shows a MOCKED tag and returns your response.

Mocks are an ordered list, first match wins — reorder with the ▲▼ buttons, toggle each on/off, and set optional latency (seconds) to simulate a slow endpoint.

Cross-origin just works. Mockingbird auto-adds CORS headers (and answers OPTIONS preflights) so a mock for a third-party API isn’t blocked by the browser. Set your own Access-Control-Allow-Origin to override.

Dynamic bodies — templates

Mock bodies (and header values) can contain {{ … }} tokens that are filled in per request — so one rule behaves like a real API instead of returning a frozen blob. No eval, no scripting; just a fixed set of lookups and helpers.

TokenResolves to
{{request.body.userId}}a field from the request JSON body (also {{body.items[0].sku}})
{{query.page}}a URL query parameter (?page=33)
{{header.x-tenant}}a request header (case-insensitive)
{{method}} · {{path}} · {{url}}request line parts
{{rawBody}}the raw request body (for XML/SOAP/form that isn’t JSON)
{{uuid()}}a fresh UUID
{{now()}} · {{now(unix)}} · {{timestamp()}}ISO time · unix seconds · epoch ms
{{randomInt(1,100)}}a random integer in range
{
  "id": "{{uuid()}}",
  "echo": {{request.body.qty}},
  "createdAt": "{{now()}}",
  "tenant": "{{header.x-tenant}}"
}

Unknown lookups render as empty — templates never throw or break the response.

Sequenced (stateful) mocks

Need a rule that responds differently each call — e.g. fail once then succeed, or page through results? In a synthetic mock, turn on “Sequenced — respond differently on each call.”

Per-call position is tracked per rule for the session; use Reset hits (Rules tab) to rewind sequences back to step 1.

Passthrough + rewrite

Sometimes you want the real response, lightly modified. Choose Passthrough + rewrite as the rule type. Mockingbird lets the request hit the network, then on the way back:

$.user.plan = "free"
$.items[0].price = 0
$.flags.beta = true

The right-hand side is parsed as JSON (so true, 0, "text", arrays all work). Rows rewritten this way show an edited tag.

Redirect (AutoResponder-style)

Choose Redirect as the rule type to send a matching request to a different URL on the network — e.g. point production traffic at a local mock server. With a regex pattern you can reuse captured groups:

PatternRedirect toResult
/\/api\/(.*)/https://localhost:3000/mocks/$1/api/orders/42…/mocks/orders/42

Use $1$9 for capture groups and $0 for the whole match. The request hits the network at the rewritten URL (subject to that target’s CORS).

GraphQL, SOAP & other APIs

Mockingbird works on any HTTP API, not just REST/JSON:

Scenarios & profiles

Rules live in named scenarios (profiles) so you can keep several worlds ready and flip between them instantly — empty-state, error-storm, logged-out, slow-network.

Upgrading from an older version? Your existing rules are migrated into a scenario called Default automatically — nothing is lost.

Breakpoints — pause & edit live

A breakpoint holds a real request on the wire so you can edit it before it continues.

Arm one

Right-click a row → Breakpoint on request or on response (or create one in the Rules tab with a URL pattern + method + stage). Armed rows show a BP·→ marker. The Break on all toggle (Rules) pauses everything for quick exploration.

When it hits

Tip: from a held response you can Save as mock to capture it as a reusable rule. Resolve hands-free with keyboard shortcuts⌘/Ctrl+Enter to continue, ⌘/Ctrl+Backspace to abort.

Replay & composer

Re-send a request, or build one from scratch.

Replays run in the armed page’s own context (real cookies & origin). They also pass through Mockingbird’s interception — if a matching mock or breakpoint is active, disable it first to see the genuine response.

cURL import & export

Move requests in and out as curl commands — the fastest on-ramp from docs, a terminal, or a teammate.

Diffing

In a request’s detail, use Compare to another request to pick a second capture. You’ll get a line-by-line body diff (green added / red removed) plus highlighted header and status differences — handy for spotting what changed between two calls.

URL pattern syntax

TypeExampleMatches
Substring/api/usersany URL containing that text (case-insensitive)
Glob*/api/v2/** matches any characters, including /
Regex/\/orders\/\d+/iwrap in slashes; flags optional

The rule form shows the detected type and how many captured requests currently match — so you can confirm a pattern before saving.

Network conditions (chaos)

Test how your app behaves on a slow or flaky connection. In Settings, under Network conditions, set any of:

ControlEffect
Throttle (ms)baseline delay added to every request that hits the network
Jitter (ms)extra random delay of 0…jitter on top, for realistic variance
Fail rate (%)that percentage of requests are dropped with a synthetic network error

These apply to traffic going to the real network (not to synthetic mocks, which have their own latency). Dropped requests show a failed tag. Set everything to 0 to turn chaos off.

Hit counters & matched-rule

When a mock “silently doesn’t fire,” these remove the guesswork:

Rules, export & import

Settings

SettingWhat it does
Break on all requestsPause every request at the request stage — exploratory.
Intercept responsesCapture response bodies for every request (needed to inspect bodies & “Save as mock”). Slightly higher overhead.
Persist capture logKeep a metadata-only history across restarts (no bodies stored).
Max retained body sizeCap on stored body size; larger bodies are truncated with a marker.
Throttle / Jitter (ms)Network conditions — delay every networked request (+ random jitter).
Fail rate (%)Drop a percentage of requests with a synthetic network error.

Keyboard shortcuts

While a request is held at a breakpoint, you can resolve it without the mouse:

KeysAction
/Ctrl + EnterContinue the shown held request (sending any edits)
/Ctrl + BackspaceAbort the shown held request
EscClose the right-click menu

With several requests paused, the shortcut acts on the one currently shown in the queue strip.

How it stays safe

A paused request could otherwise hang a page forever. Mockingbird guarantees it won’t:

Troubleshooting

“Can’t attach” when arming

A mocked request shows “Failed to fetch”

Usually a cross-origin response without CORS headers — Mockingbird adds them automatically, but if you set custom headers, make sure they don’t remove Access-Control-Allow-Origin.

Response body says “not captured”

Turn on Intercept responses in Settings, or add a response breakpoint — bodies are only readable at the response stage.

Why only one tab?

By design — it keeps one banner, one clear “armed here” model, and a much simpler (and safer) held-request state machine. You’re debugging a page, not the whole browser.

Can I hide the “debugging this browser” banner?

No — Chrome shows it for any tool that uses the debugger (that’s what lets Mockingbird pause and rewrite live traffic). It appears only while a tab is armed and disappears the moment you disarm. It’s expected, not a bug (see ADR-0001).