API Mock Server

What this is for

Waiting on a backend is the most common form of avoidable idleness in software work. A mock endpoint removes the dependency: you agree what the response will look like, mock it, and both sides build in parallel against the same contract.

It is equally useful in automation. Building a Make or n8n scenario against an API that only exists in a specification means every test run is guesswork. Point it at a mock and the scenario becomes deterministic — same input, same output, every time.

A worked example: the mock that earns its keep

Suppose you are building a page that shows a customer's recent orders, and the orders API is two weeks away. Mock the success case first:

GET /api/orders  →  200
{
  "data": [
    { "id": "ORD-1", "total": 24.5, "currency": "GBP", "status": "shipped" },
    { "id": "ORD-2", "total": 119.0, "currency": "GBP", "status": "pending" }
  ],
  "next_cursor": null
}

That gets the happy path built in an afternoon. The value comes from the four mocks you make next, because these are the states real code meets and demo code never does.

Empty. {"data": [], "next_cursor": null}. Does the page show an empty state, or a blank rectangle? A surprising amount of software has never been run against no data.

Slow. The same 200, with a two-second delay. Now you find out whether there is a loading state and whether an impatient double-click fires two requests.

Failing. A 500 with {"error": "upstream_unavailable"}. Does the UI show something a human can act on, or does it hang forever on a spinner?

Rate limited. A 429 with a Retry-After: 30 header. Does the client back off, or hammer the endpoint until it gets blocked?

Build all five before the real API lands and integration day is uneventful. Build only the first and integration day is where you discover the other four.

Where mocking fits among the alternatives

Most projects want the second row early and the last row late. The trap is stopping at the second.

The rule that makes mocks safe

A mock is a claim about someone else's API, and claims rot. The failure mode is not that mocking is wrong; it is that the mock and reality drift apart, everything passes, and the first honest test happens in production.

Three habits prevent it. Derive the mock from the provider's own documentation or OpenAPI description rather than from what you assume the response looks like. Keep the mock URL out of anything that could ship — a mock URL in production configuration is a genuine incident, not a tidiness issue. And run at least one test against the real sandbox before launch, because that is the only run that can tell you the mock was wrong.

Also worth saying plainly: a public mock endpoint is public. Anyone with the URL can call it. Do not put a real customer record in a mock response just to make the demo look convincing.

Frequently Asked Questions

Can a mock endpoint store data I send it?

No — the response is whatever you configured, regardless of the request. That is what makes it deterministic and therefore useful for testing. If you need a POST to change what a later GET returns, you need a real backend, even a small one.

Can I use it as a webhook target?

Yes, and it is a good way to check that a platform actually sends what its documentation claims. Configure the response your receiver would return, point the sender at the mock URL, and watch what arrives. To test the other direction — your endpoint receiving a request — use the API Request Tester instead.

Why is my mock reachable from the terminal but not from my web app?

Cross-origin restrictions in the browser. The request is being sent and answered; the browser is refusing to let your page read the response because the required Access-Control-Allow-Origin header is not present. It is the single most common surprise when moving from curl to a real frontend.

How long does a mock endpoint stay live?

Treat any hosted mock as temporary. It is scaffolding for the days or weeks before the real thing exists, not infrastructure. Anything you would be upset to lose should live in your own repository as a fixture or a locally-run mock server.

Should the mock return realistic data or obviously fake data?

Obviously fake, and deliberately awkward. Use names with apostrophes and accents, an empty list, a very long string, a zero, a negative number and a null. Perfectly tidy sample data hides exactly the bugs a mock exists to surface.

Next steps

For the receiving half of the same problem — building the endpoint that takes the webhook rather than the one that answers it — the Make.com Webhook Tutorial and the n8n Webhook Tutorial cover it end to end, and the JSON Validator is handy for checking a mock body before you paste it in.

When the mock has to become real, that is the work I do as a freelancer — authentication, retries, rate limiting and monitoring included. Start a project on Fiverr or hire me on Upwork.