Glossary

What Is API Mocking? Types, Tools and When to Use Each

Definition: API Mocking

API mocking means replacing a real API response with a controlled fake response, so front-end, QA and integration work can continue without the real backend or with conditions the backend cannot easily produce. Mocks can live in a standalone mock server, in test code, or in a runtime interceptor that rewrites live traffic.

Also called: mock API, API stubbing, service virtualization, fake API

Why teams mock APIs

Parallel development: the front end can be built against the agreed contract before the backend ships.
Edge cases on demand: empty lists, 10,000-item lists, null fields, 500 errors and expired tokens are hard to get from a real server.
Stable demos and tests: fixed data means screenshots, demos and automated tests stop flaking.
Cost and rate limits: third-party APIs such as payments, maps or AI may be expensive or rate-limited in development.

Three ways to mock an API

Approach	Examples	Strength	Weakness
Mock server	WireMock, Mockoon, Beeceptor, Prism	Language-agnostic, great for contract tests and CI	You must repoint the app to the mock URL; data is static
In-code mocks	Mock Service Worker (MSW), Jest mocks, Playwright `route`	Versioned with the code; ideal for automated tests	Needs code and a build; not for ad-hoc debugging
Runtime interceptor	ProxyCeptor, Requestly, Charles	Works on the real running app with no code change	Lives outside the test suite unless you export rules

Full mock vs partial (deep merge) mock

A full mock replaces the entire response body. That is fine for small payloads, but for a 3,000-line product response you usually only want to change one field.

A partial mock lets the real request go through and then patches just the keys you care about. ProxyCeptor calls this JSON deep merge: you supply { "user": { "plan": "enterprise" } } and every other field stays live.

Deep-merge mock: only override the plan, keep everything else real

JSON

1{
2  "name": "Pretend user is on Enterprise",
3  "match": { "urlPattern": "*/api/me", "matchType": "wildcard" },
4  "response": {
5    "body": {
6      "enabled": true,
7      "mode": "merge-json",
8      "mergeValue": "{ \"user\": { \"plan\": \"enterprise\", \"seats\": 500 } }"
9    }
10  }
11}

Choosing an approach

Use a mock server when several services or a CI pipeline need a stand-in backend. Use in-code mocks for unit and component tests. Use a runtime interceptor when a human is debugging the real app: reproducing a bug, checking an error state, demoing a feature before the backend is live, or letting QA verify edge cases on a TV. Many teams use all three.

Frequently asked questions

What is the difference between a mock and a stub?

In everyday API work the terms are used interchangeably. Strictly, a stub returns canned data, while a mock also verifies how it was called. For HTTP APIs, "mock API" usually just means a fake response.

Can I mock an API without a mock server?

Yes. A runtime interceptor such as ProxyCeptor returns the fake response inside the browser or app, so there is no server to run and no URL to change. See mock an API without redeploying.

Is API mocking safe to use against production?

Mocking in your own browser only changes what your browser sees; the production server is not modified. Keep mocks out of shipped code, and do not share rules that contain real credentials.

Keep learning

Intercept your first request in under a minute

Create a free ProxyCeptor account to mock, delay, block and rewrite API traffic, then share the same rules with your team.

Create free account Try the live demo ↗