What to Look For in an API Mocking Tool

Articles comparing mocking tools usually score vendors on features. This chapter does something narrower and lists the criteria that still matter after the trial, written as questions you can put to any tool including one you already run.

The criteria, and why each one is on the list

1. Where does the response body come from

This is the first question because everything else follows from it.

A tool where bodies are typed by hand is a text editor with routing. A tool that generates them from a schema removes the copy that drifts, and one that can also serve curated records removes the choice between plausible and stable. Ask specifically whether the schema is read at request time or only once at generation, since those two answers differ enormously three weeks later.

2. What happens when the contract changes

The question that separates a mock from an archive.

Ask whether a rule can keep following its source, whether it can be pinned deliberately, and what the tool does when a pinned rule falls behind. A tool with no concept of the source document gives the same answer to all three, which is nothing, and the staleness becomes somebody's afternoon.

3. How much of the network can it imitate

Ask which of latency, failure, timeout, connection reset and rate limiting the tool can produce. Then ask the sharper version, which is whether it can produce them at a probability rather than on a button.

A failure you trigger while watching tests the screen you were already thinking about. A failure that lands at random tests everything else, and only the second one finds the half-filled form and the retry that made things worse.

4. Can it remember anything

Ask whether a rule can hold state across requests, and whether that state can be reset to a defined starting point.

Without it, every flow that involves a sequence is unbuildable against the mock, which covers carts, wizards, polling and anything idempotent. With it, ask who shares the state, because a single shared memory across a team behaves very differently from one per caller.

5. Which requests can it tell apart

Ask what the matcher can see. Method and path is the floor, and query parameters and headers are what let one route answer differently for an authenticated and an unauthenticated caller.

Then ask how ties are broken when two rules both qualify, since the answer is either an explicit priority you control or an implicit order you will eventually fight.

6. Who can reach it

Ask where the mock runs and who can call it, because this decides how many of your problems it can solve.

A process on one laptop cannot be called by a designer, a preview build or a pipeline. A reachable address can be, at the cost of sharing its configuration. Ask about cross-origin access, since a mock that a browser refuses to read is a mock a frontend cannot use, and ask how it is closed off if it needs to be.

7. What does it tell you about what it did

Ask whether there is a log, and then ask what is in an entry.

A list of paths and status codes is a start. An entry showing the headers and body that arrived, plus which rule matched and why, is what turns most integration debugging into a lookup. The second most useful thing a log can show is a request that matched nothing at all.

8. What exactly is metered

Two questions catch most surprises, and both are about the meter rather than the headline price.

Ask what is counted, since requests, rules, endpoints, seats and servers all get used as meters and each one rewards a different behaviour. Then ask what happens at the limit, because a mock that stops answering mid-sprint is a different risk from one that sends an invoice.

A scorecard you can use

Criterion	Question	Weight it if
Body source	Generated from the schema, or typed	Your contract changes more than rarely
Contract drift	Following, pinning, and a diff when it moves	Anything outside the team depends on a version
Network realism	Latency, failures, timeouts, limits, at a probability	The client has to survive production
State	Memory across requests, and a reset	You are building a flow rather than a screen
Matching	Query and header conditions, explicit priority	One route needs more than one answer
Reach	A callable address, cross-origin access, a way to close it	Anyone but you needs to call it
Log	Headers, bodies, matched rule, unmatched requests	You will debug against it
Metering	What is counted, and what happens at the limit	Usage will grow

Two exercises that settle it faster

A feature grid takes an afternoon and tells you less than these two.

Generate the whole thing from your own specification. Not a sample API. Your document, including the endpoints with the weakest schemas, and then call each route once. The empty bodies show you both the tool's ceiling and your document's floor.

Then change one field and watch. Rename a property in the specification and see what the mock does. Whether it follows, reports the difference or says nothing at all is the behaviour you will actually be relying on, and it is the one thing no feature page describes accurately.

In Routebase

The mock is generated from the specification the rest of the lifecycle already uses, so the first criterion is the one it is built on.

Rules come off the contract in one step and their bodies are produced from the response schemas. A rule generated from a draft projects the current schema on every request rather than storing a snapshot. A rule pinned to a published version reports the difference when the contract moves and shows it field by field before anything is regenerated.

The rest sits in the same workspace. Matching covers query and header patterns with an explicit priority order, and each rule carries its own delay, failure probability, rate limit and optional state. Conditional responses give one route as many answers as it needs. The server has a stable public address with configurable origins and an optional access token, and the log records every request with the rule that matched it. The chapters from generating a mock through when not to mock work through each of those in turn.