Net Tinker: Mock API Responses od NetTinker

Net Tinker does one thing: it lets you decide what an API answers while you work 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, importers, network simulation — is built on that one idea.

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, or overwrite one JSON field and leave the rest as the server sent it.
• Modify a real request — headers, query parameters, body, or one JSON field of the body by its dotted path.
• Redirect it, or rewrite part of the URL. A regex can reuse what it matched, so "send /api/v1/ to /api/v2/" is one rule, not one per endpoint.
• Block it, or 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.
• Fill one of your variables from the response, so the next requests can use what this one returned.
• Print a line in the page's console when the rule fires — a breakpoint that doesn't stop anything.

MAKE THE NETWORK MISBEHAVE ON PURPOSE

• Random latency — a min-max range drawn fresh on every request.
• A simulated timeout that fails the way a real one does: a TimeoutError for fetch, the timeout event for XMLHttpRequest. 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.
• A call limit — the first N calls go through and everything after answers with the status you choose: what your interface does when something breaks AND stays broken.
• Intermittent failure — one request in every N fails, never the first.

The count belongs to the page: reloading starts it over 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 by HTTP method, request header, request body or the page making the call, and list URLs to leave alone. Paste a real URL into the test box and the form tells you whether it would be caught before you save. Pin a rule to a single tab when you don't want it anywhere else.

Because GraphQL sends every operation to the same endpoint, matching on the body is what lets you mock one operation without touching the rest.

SEE WHAT ACTUALLY HAPPENED

Net Tinker adds a panel to the browser's 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.
• Repeated calls carry an xN badge, so a component that renders twice stands out.
• A timing summary — how many, median and P95 — with the requests your own rules delayed counted apart.
• Search inside the bodies, not only the URLs.
• Compare two responses field by field, with volatile fields set aside and personal data masked.
• GraphQL operation names are detected and shown.
• One click turns any request into a rule, and "Mock" fills in the real status, headers and body.

TAKE IT SOMEWHERE ELSE

Copy a request or a rule as curl, as a fetch() call, as a Playwright or Cypress mock, as TypeScript types for the response, or as a bug report with request, response and a curl to reproduce it. Credentials are masked, and the snippet says what it hid. Sessions export as standard HAR. And the other way round: paste a curl command 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 — Login > Success / Invalid credentials / Backend down — with one variant live at a time. Rules of a variant that isn't live are never even looked at. You switch from the popup, per scenario, so two services can be in different states at once.

Six ready-made scenarios spare you the empty list: HTTP errors, a REST collection in four states, sign-in, rate limiting, pagination and GraphQL — including errors returned with a 200. Every variant arrives with its rule written.

KEEP TWO JOBS APART

Rules, groups, scenarios, variables, environments, scope, bin and activity all live inside a project. Only the active project is shown and applied, so the client you are not working on today cannot answer one of your requests.

REUSE THE SAME RULES EVERYWHERE

Write {{variables}} into bodies, headers, redirect URLs and query parameters, and define environments — Local, Dev, Staging, Prod — that override only what changes. Switch from the popup and the same rules follow you from localhost to staging; one shortcut repoints a whole environment at another backend.

A rule can fill a variable from a JSON field or a regex of a response, so {{JWT}} interpolates the token your login just issued. Captured values live in session memory only: never on disk, never in an export.

DON'T TYPE WHAT YOU ALREADY HAVE

One Import button — or a file dropped anywhere on the options page — reads five kinds of file and tells them apart by their contents:

• A Net Tinker export.
• An OpenAPI or Swagger spec (3.0, 3.1, 2.0, JSON): every endpoint, method and response code becomes a rule with pattern, status and body written; several codes become a scenario.
• A Postman collection (v2.0, v2.1): each saved example becomes a mock with its real status, headers and body. Environment exports bring their variables.
• A HAR capture, turned into mocks — and it tells you how many carry credentials.
• A ModHeader profile, with its headers, URL filter and exclusions.

You untick the endpoints you don't want and they are never created. Everything arrives switched off, what could not be translated is listed with the reason, and importing the same spec again shows what changed since last time.

STAY IN CONTROL

• Choose where it works: everywhere, only on localhost, only on the domains you list, or everywhere except those. Outside that scope Net Tinker removes its own patches and doesn't touch the page, and the toolbar icon says so.
• A permissions screen explains in plain words what the extension asks for and why.
• When two rules match, the lower one wins, and you reorder them. A conflict check lists the active rules that silently cancel each other, and says which clashes are certain.
• Filter by name, URL, description, tag, rule type, group, or scenario and variant — including rules in no group and rules outside every scenario.
• Select what the filter shows and enable, disable, export or delete it in one go.
• Group rules and switch a whole group on or off in one click.
• Undo a delete: the last ten are kept, and one gesture is one entry.
• Export and import to share a setup, optionally stripping credentials first.
• A built-in help page explains each rule type and why a rule might not fire.
• Light and dark themes: follow your system, or pick one.
• Keyboard shortcuts: / to search, Alt+N for a new rule, Ctrl+S to save.

Your rules run from the moment the page loads, whether or not DevTools is open.

PRIVACY

Everything is stored locally in your browser. No server, no account, no analytics, no tracking. Requests in the DevTools panel live in memory only; recording a tab keeps its 200 most recent requests, locally, only while you have it on.

Net Tinker needs broad host access because it cannot know in advance which site you will write a rule for; that access only runs the rules you configure. It declares two permissions in total: storage, and that host access. No tabs, no scripting, no browsing data. Firefox lets you withdraw that access in the add-on's permissions; if you do, the popup tells you and offers to give it back, instead of leaving your rules silently doing nothing.

NO LIMITS AND NO UPSELL

Every rule type is free, with no cap on how many rules you create or keep active. That is worth saying plainly, because it is where comparable tools draw their paid line — the best-known one stops you at five rules, three of them active at a time.

WHAT IT CANNOT DO

It acts on the requests a page makes with fetch or XMLHttpRequest. Images, stylesheets, navigations and a site's own service worker are out of reach, and the DevTools panel says so. Specs and collections are read as JSON; YAML is recognised only to tell you to convert it. It needs Firefox 140 or later, and the DevTools panel is for Firefox on desktop.

Useful for testing APIs, simulating backend errors, exercising the loading and error states of your frontend, or debugging an integration without depending on a real environment.

Available in English and Spanish; the interface follows your browser unless you choose otherwise.