Your screen is too small. Please widen your browser window or use a device with a screen width of at least 300px to use this app.
Six mock API tools compared by where they run, what it takes to start, and whether a write survives the next request. The choice turns on one question most comparisons skip: does your mock need to remember anything, or does it only need to answer.
Every comparison of these tools opens with features and prices, and both are the wrong place to start. The axis that actually separates them is whether a request can change what the next request sees. A mock with state has a database behind it. A mock without state has a body you wrote, returned as often as you ask for it.
You need state when the flow you are building is about the change itself. A cart that has to hold what you added to it, a signup wizard whose second step depends on the first, an optimistic update that has to survive the refetch behind it. Nothing stateless will show you whether those work, and no amount of careful fixture writing substitutes.
You do not need state for most of the rest, and most of the rest is most of the work. A list, a detail view, an empty state, a permission error, a slow response, a row long enough to wrap. Each of those is one request with one answer, and a tool that keeps a database for them is charging you for a feature that is going to get in your way.
Ordered by how much each one remembers, most at the top. They are not ranked, because the top half and the bottom half are not doing the same job. Free tiers and feature lists move, so check the service before you depend on it.
| Tool | Where it runs | Account to start | Writes that stick | Best at |
|---|---|---|---|---|
| MockAPI | A hosted service | Yes | Yes, into a real data store | A CRUD backend generated from a schema |
| Beeceptor | Hosted, and as a proxy in front of your own backend | Not to create one, yes to keep it | Yes, a small object store | Watching live traffic and rewriting it |
| Mockoon | Your own machine, as a desktop app or a CLI | No |
A generated CRUD backend is genuinely impressive the first afternoon. You describe a resource, pick a generator for each field, and a full set of REST routes appears with a hundred rows behind them. The cost arrives on the second day, and it arrives as drift.
# first run: the fixture has three orders
curl -s https://your-mock.example/orders | jq length
3
# the test under way posts one
curl -s -X POST https://your-mock.example/orders -d '{"total": 10}'
# second run, same test, same assertion, different answer
curl -s https://your-mock.example/orders | jq length
4A test that writes has changed the data the next test reads. That is the same problem a real database gives you, which is fair, because you are now running one. The fix is the same too: a reset step before each run, seed data kept somewhere it can be restored from, and an agreement that nobody edits the shared mock by hand while a suite is running.
There is a smaller cost beside it. A schema has to be described before it can serve anything, so the shape lives in the tool rather than in your repository, and it has to be updated in both places every time the API changes. When your flow needs state, all of that is worth paying. When it does not, you have bought a database to render a table.
A stateless endpoint is a written down fact. It does not drift, so a screenshot taken today and a test run next month disagree only if somebody edited it on purpose. Nothing has to be reset between runs, because nothing changed.
It also changes how you handle the awkward states. Instead of one endpoint you keep editing to reproduce an empty list, then a 500, then a slow response, you point three paths at the same shape and leave all three alive. Switching between them costs a base URL change rather than a code change, and the 500 is still sitting there next week when somebody asks whether the error banner still works.
What you put in those bodies decides whether any of this is worth doing. Mock data covers the values that find bugs rather than hiding them, which is the difference between a mock that proves a fetch worked and one that proves a screen works.
Free tiers sweep, and the retention rule is usually a line on a pricing page rather than anything the product tells you while you work. Beeceptor keeps an unclaimed endpoint for seven days and a claimed one for ninety on its free plan. Mockoon lives exactly as long as the process you started. A mock URL you pasted into a ticket in March is a link somebody will click in June, and a dead one sends them to you instead of to the answer.
The related question is what it costs to change a response once the URL exists. An immutable mock means a new URL and a code change every time the shape shifts, which is fine for a one off and painful for a screen still being designed. Before you reach for any tool on this page, free APIs for testing covers the public datasets that need no setup at all, and how far they take you.
Six questions, in the order they usually start to matter.
This is the first question and it decides most of the rest. A cart, a signup wizard or an optimistic update followed by a refetch needs state. A list, a detail page and an error banner do not.
An error branch is only tested when something returns an error on demand, repeatably, on the route your screen actually calls. Some tools treat this as a rule to configure, others do not offer it at all.
No schema to describe and no process to keep running. Paste a body and call it over HTTPS.
| Yes, until the process stops |
| Working offline, and running a mock inside CI |
| Postman mock server | Hosted, inside a Postman workspace | Yes | No, it replays saved examples | Teams already running their contracts through Postman |
| Mocky | A hosted service | No | No, the body is fixed to the URL | One response, written once and linked forever |
| Fake API | A hosted service | No, a trial sandbox runs without one | No, every call sees the body you wrote | Several endpoints answering one shape differently |
The fourth column is the one to read first, and the bottom three rows all answer it the same way. None of them keep a write, which sounds like a missing feature until you notice what it buys: the endpoint returns exactly what you wrote, on the tenth call and on the thousandth, no matter what ran against it in between.
Skeletons, spinners and timeout branches run only when a response is slow. A mock that answers in four milliseconds hides every one of them until someone on a train finds them for you.
A mock on your laptop cannot be opened by a designer checking a state, a tester reproducing a bug, or a CI runner on another machine. A hosted URL can be pasted into a ticket. That is a different job.
Free tiers sweep. Some expire an unclaimed endpoint within days, some expire it after months, and some keep it until you delete it. Find out before the URL is in a ticket rather than after.
Some mocks are edited in place, so the URL in your app never moves. Others are immutable, so a changed body means a new URL and a code change every time the shape shifts.