Test API errors before your users find them

A successful response is only one case

A client can work perfectly against a 200 response and still break when a request is slow or fails. A small mock API makes those cases repeatable while your real backend is changing.

Start with the states your interface actually displays: loading, usable data, an empty result, a validation problem, and an unavailable service. Keep fixtures small enough that another developer can understand them at a glance.

Create explicit routes for each state

Open Mock REST API, name the resource, and configure a method, exact path, status, body, and optional delay for each route. The Response builder, HTTP status simulator, and Delay & timeout simulator use the same mock service with different starting points.

Use separate paths for deterministic test cases. This mock service returns static configured responses; it does not run application code, maintain a CRUD database, or change state automatically between calls.

• GET /orders returns 200 with a small JSON array.
• GET /empty returns 200 with an empty array.
• POST /invalid returns 422 with a validation message.
• GET /unavailable returns 503 with a safe error body.

Assert the behavior, not just the status

Point a test build at the returned mock base URL. Private mocks require X-Access-Token or authorized workspace access. Explicitly choose public access only when that is appropriate for your test.

For a validation error, check that the form keeps the entered values and shows the right message. For a server failure, check that loading ends and retry is possible. An empty array should show a helpful empty state rather than a spinner forever.

Make loading and timeout behavior visible

Add a delay to one route and verify that the loading state appears, repeated submissions are prevented where needed, and focus remains usable. socket.help supports configured delays up to two seconds.

A delay is a response-time simulation, not a complete network failure simulator. For a timeout test, your client timeout must be shorter than the configured delay. Test connection loss with a tool designed to control the network.

Keep the mock disposable

Mock APIs support up to 20 routes and 80 KiB of configuration. They start with a one-hour lifetime, and renewal stays within plan limits. Save important fixtures in your project before the resource expires.

Delete the mock when the test ends. If you need response templating, proxying, recording, or richer reusable mock environments, a dedicated platform such as Mockoon may be a better fit.