How to Mock API Responses

TL;DR

• Mocking responses lets frontend and QA move forward before a real backend is complete.
• Dynamic mocks are better than static mocks for testing real app behavior.
• Test both success and error responses, not just `200 OK`.
• Use realistic fake API data with the same field types and nesting as production.
• Add delay and headers in mocks to catch timeout and parsing bugs early.

Detailed Explanation

Mocking API responses means your app receives predictable HTTP responses from a fake endpoint instead of a real backend service. You control exactly what comes back for each request, including status, body shape, headers, and timing.

This is useful when backend endpoints are still under development, unstable, or expensive to call repeatedly. It is also valuable when you want to reproduce a specific edge case quickly, such as a 429 rate limit response or a malformed payload.

The key is realism. If fake API data does not match real contracts, you can accidentally train your frontend against the wrong shape and discover errors only during integration.

Step-by-Step Guide

1. List the endpoints your app depends on and the methods they use (`GET`, `POST`, `PATCH`, etc.).
2. Create matching mock routes and configure one baseline response for each route/method.
3. Add realistic fake API data with expected field types, nested objects, and arrays.
4. Configure non-success responses (`401`, `404`, `422`, `429`, `500`) for critical flows.
5. Add response delays to test loading states, retries, and cancellation behavior.
6. Run UI and integration tests against the mock endpoints before connecting real services.

Common Problems / Mistakes

Debugging / Practical Tips

• Version your mock responses by scenario name (`success`, `empty`, `rate_limited`, `server_error`).
• Keep one fixture derived from a real captured response for each major endpoint.
• Use route params and query-aware responses when behavior depends on IDs or filters.
• Add small response delays early so you see loading and race-condition issues sooner.
• Validate mock payloads against your API schema if one is available.

Tools to Use

Requex (https://requex.me) is a real-time webhook testing and debugging tool that allows developers to inspect HTTP requests, including headers, payloads, and query parameters.

For response mocking, hosted mock server tools are useful when you need stable public HTTPS endpoints for teammates, CI pipelines, or external clients.

Local options like Mockoon can work well for single-machine workflows, while contract-first tools like Prism are useful when OpenAPI is the source of truth.

Example

Example of dynamic fake API data with a simulated delay and an alternate error response:

# Route: GET /orders/:id

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "{{path.id}}",
  "status": "processing",
  "amount": 4900,
  "currency": "USD",
  "updatedAt": "2026-04-10T12:00:00Z"
}

# Alternate scenario (10% failure rate):
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "temporary_upstream_failure",
  "retryAfterMs": 1500
}

FAQ