Turn real API traffic into test fixtures

The idea

A browser extension that sits in your devtools and records every API response the page receives while you click through a flow. When you stop recording, it hands you a folder of fixtures: one JSON file per endpoint, a set of Mock Service Worker handlers wired to them, and TypeScript types inferred from the bodies. Secrets and personal data are scrubbed on the way out, with a diff you approve before anything lands on disk.

The pitch is that your staging environment already produces better test data than you will ever write by hand. You just have no way to capture it without copy-pasting from the Network tab.

Why build this

Frontend tests fail for two boring reasons: the fixture was invented by a developer and doesn't match what the backend sends, or it matched once and the API has drifted since. Both are capture problems. Everyone solves them the same way — open devtools, right-click a response, "Copy response", paste into a file, delete the customer's email, forget one field, commit.

HAR export exists, but a HAR is a transcript of a session, not a fixture library: wrong shape, no redaction, no types, full of analytics beacons and font requests. Mock Service Worker has won enough mindshare that "fixtures plus handlers" is now a standard target to generate for, which it wasn't three years ago. And the reason nobody shipped this earlier is that Chrome's MV3 migration broke the obvious approach — webRequest can observe a response but cannot read its body. The workaround is the chrome.debugger API, which most extension developers never touch.

Stack sketch

• Chrome MV3 extension, with a devtools panel for the record/stop/review UI.
• Capture via chrome.debugger attached to the inspected tab, driving the CDP Network domain: requestWillBeSent, responseReceived, then Network.getResponseBody for the payload. This is the only MV3 path to response bodies.
• Firefox build later via webRequest.filterResponseData, which gives bodies directly.
• IndexedDB (through idb) as a capped ring buffer so a long session can't fill the profile's quota.
• Redaction as an ordered ruleset: drop Authorization, Cookie, and Set-Cookie headers unconditionally; then JSONPath-style field rules, plus detectors for emails, JWT-shaped strings, and Luhn-valid card numbers. Replacements are stable per value, so the same user stays the same fake user across fixtures.
• Endpoint grouping by path template — collapse UUID and all-digit segments to :id — then dedupe on method, template, and status so one flow yields one fixture per case, not forty.
• Export with quicktype for TypeScript types and a small template layer emitting MSW http.get(...) handlers, Playwright page.route stubs, or plain JSON plus HAR 1.2.

Scope for v1

In:

• Chrome only, manual record and stop from the devtools panel.
• URL include/exclude patterns, defaulting to same-origin XHR and fetch, so beacons and CDN assets never get captured.
• Redaction preview: a side-by-side of raw and scrubbed body, per endpoint, with an explicit approve step.
• One export bundle: JSON fixtures, MSW handlers, inferred types, written through the File System Access API into the repo folder you pick.

Out:

• Any automatic or background capture. Recording is always an explicit act.
• Firefox and Safari, GraphQL operation splitting, request-body capture, team sync, CI integration.

Where it could go

The interesting second act is drift detection. Once fixtures carry the request that produced them, a nightly job can replay those requests against the real API and diff the response schema — not the values. That turns a fixture library into a contract test suite that nobody had to write, and it answers the question frontend teams actually have: did the backend change something we depend on? A small Node CLI reading the same bundle format is enough to run it in CI.

After that, sharing. Fixtures are most valuable when the whole team has the same ones, and a git-committed bundle gets you most of the way, with a tiny sync service only if teams want central redaction rules they can't bypass. A third path is serving the bundle as a local mock server, which gives you offline development and reliable demos from the same recordings.

Watch out for

The redaction rules are the product; one leaked production response committed to a public repo is the kind of incident that ends the tool's reputation, so default to aggressive scrubbing and fail closed when a detector fires on an unmapped field. Separately, chrome.debugger makes Chrome display a prominent "started debugging this browser" banner and draws extra scrutiny in Web Store review — budget real time for the listing, and explain the banner in onboarding before users assume something is broken.