API mocking, explained
A mock server listens like the real API but answers from fixtures, examples in an OpenAPI document, or recorded traffic. Front-end and integration teams use mocks to start work before the backend exists, to test error paths that are hard to trigger for real (timeouts, 500 responses, rate limits), and to keep CI fast and free of third-party outages.
- Static mocks return fixed responses per endpoint.
- Spec-driven mocks generate responses from an API description, as tools such as Prism do.
- Record and replay captures real responses once and serves them later, as WireMock and similar tools support.
- In-process mocks intercept HTTP calls inside the test runner, for example with Mock Service Worker or nock.
The core risk of mocking is drift. A mock encodes what the API did when someone wrote it, so tests keep passing after the real API changes, and the break surfaces in production. Keep mocks generated from the current spec or recordings, and back them with contract testing or traffic replay against the real implementation.
Related terms
- API testing: API testing verifies that an API returns correct responses, status codes, data and performance for given requests, directly at the interface without a UI.
- Contract testing: Contract testing verifies that an API provider and its consumers agree on the requests and responses they exchange, so either side can change without silently breaking the other.
- OpenAPI Specification: The OpenAPI Specification is a standard, language-agnostic format (YAML or JSON) for describing HTTP APIs: their paths, operations, parameters, schemas and authentication.