Net Tinker: Mock & Modify API Responses

Net Tinker does one thing: it lets you decide what an API answers while you are working on the page that calls it — without touching your backend, without an account, and without anything leaving your machine. A rule says which requests to catch and what to do with them. Everything else — scenarios, the importers, the network-simulation fields — is built on that one idea. There is nothing else to learn. WHAT A RULE CAN DO • Mock a response — your own status, headers and body. The request never reaches the network. • Change the real response — find and replace text in it, or overwrite a single JSON field and leave everything else exactly as the server sent it. • Modify a real request — its headers, its query parameters, its body, or one JSON field of that body by its dotted path. Then let it go out as usual. • Redirect it, or rewrite part of the URL. A regex pattern can reuse what it matched, so "send all of /api/v1/* to /api/v2/* and keep the rest of the path" is one rule, not one per endpoint. • Block it entirely. • Override the status code the real response came back with. • Add latency to any of the above. Mocking an endpoint and slowing it down is one rule, not a choice between two. • Fill one of your variables from the response, so the requests that follow can use what this one returned. • Print a line in the page's console when the rule fires, with the values you ask for — a breakpoint that doesn't stop anything. MAKE THE NETWORK MISBEHAVE ON PURPOSE • Random latency — a min-max range drawn fresh on every request, so the page under test stops seeing a metronome. • A simulated timeout — it waits, and then fails the way a real network timeout does: a TimeoutError for fetch, the timeout event for XMLHttpRequest. Latency succeeds late and blocking fails at once, so this is the branch your code was written for and could never reach. • Chaos, per rule — 20% a 500, 10% a timeout, the rest business as usual. The successful share is whatever you leave over, so the numbers cannot contradict each other. • A call limit — the first N calls go through and everything after them answers with the status you choose. The only way to see what your interface does when something stops working AND does not come back. • Intermittent failure — one request in every N fails, and never the first, so you see the rule work before you see it break. The count belongs to the page: reloading starts it over, two tabs count separately, and it is never written to disk. HIT EXACTLY THE REQUESTS YOU MEAN Match by URL or host — contains, exact, regex or wildcard — then narrow it down by HTTP method, by a request header, by what's in the request body, or by which page is making the call, and list the URLs to leave alone even when they match. Paste a real URL into the test box and the form tells you straight away whether it would be caught, before you save anything. Pin a rule to a single tab when you don't want it affecting everything else you have open. Because GraphQL sends every operation to the same endpoint, matching on the body is what finally lets you mock one operation without touching the rest — and rewriting a single field of the outgoing body changes variables.userId without pasting a copy of your query into the rule. SEE WHAT ACTUALLY HAPPENED Net Tinker adds a panel to Chrome DevTools with the requests of the page you are inspecting, and a log you can record and keep. • Every entry says what happened to THAT request: the status it really got, and whether a rule mocked it, delayed it, cut it off or let it through. Ten calls governed by the same rule no longer look alike. • Repeated calls carry an xN badge, so a component that renders twice stops looking like ordinary traffic. • A timing summary over what you are filtering — how many, median and P95 — with the requests your own rules delayed counted apart, so the number describes your backend and not the extension. • Search inside the bodies, not only the URLs: it is the only way to find one GraphQL operation among fifty calls to /graphql. • Compare two responses field by field, with the fields that always change kept out of the way and anything that looks like personal data masked. • GraphQL operation names are detected and shown, so a list of calls to a single endpoint is finally readable. • One click turns any request into a rule — and "Mock" fills in the real status, headers and response body, so you start from what the server actually returned instead of typing a fixture by hand. TAKE IT SOMEWHERE ELSE Copy a request or a rule as a curl command, as a fetch() call, as a Playwright or Cypress mock, as TypeScript types for the response, or as a bug report with the request, the response and a curl to reproduce it — ready to paste into a ticket. Credentials are masked and the snippet itself says what it hid. The whole session exports as a standard HAR. And the other way round: paste a curl command — the one your browser or your colleague just copied — and Net Tinker builds the rule from it, method, headers and body included. SWITCH A WHOLE STATE AT ONCE A scenario is one API and several named variants of it — Login > Success / Invalid credentials / Backend down — with one variant live at a time. Rules belonging to a variant that isn't live aren't merely skipped: the engine never looks at them. You switch from a dropdown in the popup, and the exclusion is per scenario, so two services can be in different states at the same moment. Six ready-made scenarios spare you the empty list: typical HTTP errors, a REST collection across four states, sign-in, rate limiting, pagination and GraphQL responses — including errors returned with a 200, which is the shape that catches people out. Every variant arrives with its rule already written, body included. KEEP TWO JOBS APART Everything you have lives inside a project: its rules, groups, scenarios, variables, environments, scope, bin and activity. Onl…