What is a mock API and why would I use one?

A mock API is a fake HTTP endpoint that returns responses you define, without a real backend. Developers use one to build and test a frontend before the backend is ready, to reproduce specific responses like errors or slow requests, and to develop offline. With MockBase you create a live mock endpoint in seconds and point your app at it.

How do I mock a REST API without writing any backend code?

Create a mock in MockBase, add a route such as GET /users, and set the JSON body and status code it should return. Your app calls the generated URL and gets that response. No server, no code, no deployment.

Can I test how my frontend handles errors and slow responses?

Yes. You can set any status code, add latency to simulate a slow network so you can see your loading states, and use chaos injection to make an endpoint fail randomly at a chosen rate.

Does it support dynamic responses based on the request?

Yes. You can return different responses based on query parameters, headers, or the request body, use templates to echo request data back, and enable a stateful CRUD mode where a resource behaves as if it has real state.

Can I import an existing OpenAPI or Swagger spec?

Yes. Paste an OpenAPI 3.x document in JSON or YAML and MockBase generates the routes for you, and you can export any mock back to an OpenAPI document.

You can try it without signing in, and every feature is free during the beta. There is a Pro tier for custom subdomains, API token protection, chaos testing, and a higher request quota, which is unlocked for free while the beta is running.

Blog

You're Probably Using "Mock" Wrong

September 4, 2026Xerat02

You're probably using "mock" wrong. It doesn't matter — but knowing why is useful.

The taxonomy nobody agrees on

In 2007, Martin Fowler wrote "Mocks Aren't Stubs", pulling together a vocabulary Gerard Meszaros had proposed for the different flavors of test double. The distinctions he draws are precise:

A stub gives canned answers to calls made during a test, and usually ignores anything it wasn't explicitly programmed to expect.
A fake has a real working implementation, but takes a shortcut that rules it out for production — an in-memory database standing in for a real one is the classic example.
A mock is pre-programmed with expectations, and the test fails if those expectations aren't met — it verifies that specific calls happened, not just that the final state looks right.

That last point is the one people skip: a mock, in Fowler's sense, is about verifying behavior (did you call this method, with these arguments, this many times), not about returning data. Stubs and fakes are checked by looking at the state they leave behind. Mocks are checked by watching what happens during the test.

So what is MockBase actually?

By that taxonomy, a tool like MockBase — or Postman's mock servers, or WireMock, or Prism — isn't really a "mock" at all. It's a fake. It has a real, working HTTP implementation. It returns real JSON over a real connection. It just takes a shortcut: the data isn't backed by a real database, a real auth system, or real business logic.

Nobody's going to rename these tools. "Mock server" won the naming war over a decade ago, the same way "stub" gets used loosely for things that are technically fakes in half the codebases you'll ever read. Words drift. But it explains something that's otherwise a little confusing: why a "mock" server can hold state, respond differently to different inputs, and behave like a small real API — because functionally, it's closer to Fowler's fake than his mock. It's not verifying that you called the right method. It's standing in for a service that doesn't exist yet.

Where contract testing fits

This is the piece that trips people up next: mocking (or faking, properly speaking) and contract testing solve different problems, and one doesn't replace the other.

Pact's documentation defines contract testing as checking each application in isolation to make sure the messages it sends or receives conform to a shared, documented agreement — the contract. Concretely: your frontend team writes tests against what they expect the API to look like, those expectations get recorded as a contract, and the backend team's CI runs that same contract against their real implementation. If either side drifts from the agreement, the pipeline fails — not a human noticing in staging three weeks later.

That's a fundamentally different job than a fake server does:

A fake (what you'd build in MockBase) lets you build and test a UI against a plausible API before the real one exists. It's about velocity — nobody's blocked waiting on someone else's sprint.
Contract testing (what a tool like Pact does) verifies that the real frontend and the real backend still agree with each other after both exist. It's about catching drift, not enabling parallel work.

You can — and probably should — use both. The fake gets your frontend team unblocked on day one. The contract test is what stops the backend team from quietly renaming a field six weeks later and finding out in production.

Why this matters more than it sounds like it should

Get the vocabulary right and the tool choice gets obvious. If a team reaches for "mocking" when what they actually need is drift detection between two already-built services, they'll be frustrated that hand-written fixtures don't catch a renamed field — because that was never what a fake was for. And a team that reaches for contract testing before either side of the integration exists yet is solving a problem they don't have yet, at the cost of the one they do: nobody can start building.

The short version, if you want it without the history lesson: reach for a fake (a mock server) when something doesn't exist yet and you need to keep moving. Reach for contract testing when both sides exist and you need proof they still agree. Different tools, different jobs, and — despite what the industry calls all of them — not actually the same thing.