API Response Mocker

API Response Mocker

Generate mock API responses with fake JSON data. Create realistic REST API test data. Free mock server response generator for developers

A frontend that needs an API the backend has not built yet is the most common cause of "I am blocked, waiting on the backend team". A mock API server that returns realistic JSON for every endpoint unblocks the frontend immediately. This tool generates mock responses from a JSON Schema or example payload, supports parametric routes (/users/:id), simulates latency and error rates, and exports as a Postman collection, OpenAPI spec, or runnable mock-server config (json-server, MSW, Mockoon).

What makes a mock useful vs. useless

  • Realistic data — names, emails, dates that look like what real responses contain. "John Doe / 2023-01-01" everywhere is a tell-tale sign of unrealistic fixtures that hide layout bugs.
  • Variety — each call returns slightly different data (random names, varying counts, sometimes-null fields). Production data is not uniform; fixtures should not be either.
  • Pagination — if the real API paginates, the mock should too. Frontend code that "works" against an unpaginated mock breaks the moment production responds with offset/limit / cursor structure.
  • Latency — real APIs take 50-500ms. Mocks that return instantly hide loading-state bugs and race conditions.
  • Errors — at least one in 20 calls returning 500 or 503 forces the frontend to handle errors. Mocks that always succeed produce code that does not.
  • Schema validation — generated responses match a JSON Schema or TypeScript type. Hand-written mock JSON drifts from the spec; schema-derived mocks stay aligned.

Working example: a paginated list endpoint

Input

Endpoint: GET /api/users?page=1&pageSize=20
Schema: { id, firstName, lastName, email, createdAt, role }

Output

Sample response (first call):
{
  "items": [
    { "id": "u_8a2c", "firstName": "Maja", "lastName": "Wójcik", "email": "maja.wojcik@example.com", "createdAt": "2024-11-03T08:42:00Z", "role": "user" },
    { "id": "u_b91d", "firstName": "Piotr", "lastName": "Lewandowski", "email": "piotr.l@example.com", "createdAt": "2025-02-14T15:21:00Z", "role": "admin" },
    ... 18 more ...
  ],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "total": 543,
    "hasNext": true
  }
}

Sample headers:
  Content-Type: application/json
  X-RateLimit-Remaining: 99

Latency: 142 ms (randomly between 50-300)

5% of calls instead return:
  Status: 503
  Body: { "error": "Service temporarily unavailable" }

Generated names use the locale you configure (Polish names for pl-PL). Emails use example.com / example.org (RFC 2606 reserved). The 5% error rate forces frontend code to handle failures during dev, not in production.

Mock server libraries and when to use which

  • MSW (Mock Service Worker) — intercepts fetch / XHR in the browser. Same mock works in dev, tests, and Storybook. Best for frontend-heavy projects.
  • json-server — Node.js process that serves a JSON file as REST. Good for quick prototypes; less flexible than MSW for complex routes.
  • Mockoon — desktop GUI. Drag-and-drop route builder, no code. Good for QA folks setting up mocks without writing JS.
  • Postman mock server — paid feature. Cloud-hosted. Good if your team already uses Postman extensively.
  • WireMock (Java) / Mountebank — for backend integration tests against external services.
  • Stoplight / Prism — generates mocks from OpenAPI / Swagger spec automatically. Best for spec-driven development.

When to reach for this tool

  • You are starting a feature where the backend API does not exist yet, and you need realistic responses to develop the frontend.
  • You are writing Storybook stories for components that fetch data, and you want consistent mocked data per story.
  • You are running Cypress / Playwright tests and want stable network responses regardless of backend state.
  • You are demoing a feature and want to show "what it looks like with data" without depending on a real backend.

What this tool will not do

  • It will not test your backend. Mocks replace the backend in the frontend's perspective; for verifying backend behavior, use integration tests against the real API.
  • It will not maintain itself. When the backend API contract changes, you must update the mock. Schema-driven mocks reduce this drift; hand-written mocks compound it.
  • It will not simulate complex business logic. The mock returns deterministic or random responses; if your real API has state machines, conditional logic, or side effects, the mock at most pretends to.

Frequently asked questions

How do I keep my mock in sync with the real API?

Generate the mock from the OpenAPI spec or TypeScript types that the real API also uses. When the spec changes, the mock changes. Tools like Prism, MSW with OpenAPI integration, or json-schema-faker support this workflow.

Should I commit mock data to git?

Yes — for static mocks used in tests. For randomly-generated dev mocks, only the generator config (schema, seeds) needs to be in git; the data regenerates per run.

How realistic should mock data be?

Realistic enough that visual review catches layout bugs. "Lorem ipsum" everywhere shows widths but not text behavior (truncation, line wrapping, internationalization). Use names with diacritics, emails of varying length, dates spanning years — surface the edge cases real data has.

What is the difference between a mock and a stub?

Loose convention: mock = returns a programmed response, may track if called. Stub = returns a programmed response, no tracking. In practice the terms overlap; pick a vocabulary for your team and stick with it.

Can I record real API responses and replay them as mocks?

Yes — VCR (Ruby), nock (Node), polly.js, MSW with recording mode. Useful for capturing exact production response shapes. Watch for: recordings include real user data unless scrubbed; renew them when the real API changes.

Do mocks slow down test suites?

They speed them up. Tests against real APIs depend on network reliability and test data availability; mocks are deterministic, fast, and run offline. The trade-off is integration accuracy — purely-mocked tests miss real API behavior changes.

Related tools

Last updated · E-Utils editorial team