Edge-case tutorial
How to Mock API Authentication, Errors and Latency Locally
Mock authentication, failures, and latency by protecting a local project, configuring fixed delay and 503 injection, and documenting repeatable frontend or QA scenarios. Use statuses produced by real runtime behavior and be explicit about unsupported arbitrary responses.
By Mock API Studio · Published September 17, 2026 · Updated September 17, 2026
Configure authentication scenarios
Choose bearer tokens, an API key, or Basic authentication. Record the valid local credentials and requests for success, missing credentials, incorrect credentials, token expiry, and logout or revocation.
GET /orders
authorization: Bearer <valid-local-token>
GET /orders
authorization: Bearer invalid-tokenUse the statuses the runtime supports
Authentication produces 401 or the configured unauthorized status. Missing records and parents produce 404. Invalid query choices can produce 400, and deleting a referenced parent produces 409. Global injected failures produce 503.
| Status | Supported source | Example |
|---|---|---|
| 400 | Invalid query/configured validation | Disallowed sort field |
| 401 | Authentication | Missing or invalid credential |
| 404 | Resource lookup | Unknown record or parent |
| 409 | Relationship integrity | Delete a referenced parent |
| 503 | Failure injection | Probabilistic service failure |
Handle unsupported status scenarios
Arbitrary route-specific 403, 422, 429, and 500 responses are not currently configurable. If a UI must handle those exact contracts today, use a small request interceptor or test stub alongside Mock API Studio and document the split setup.
Add fixed and variable latency
Mock API Studio provides fixed latency, which is ideal for a reproducible loading check. It does not currently provide a random range. For variable network timing, run several fixed scenarios such as 200 ms, 1200 ms, and the client timeout threshold.
PUT /_mock/config
content-type: application/json
{ "latency": 1200, "errorRate": 0.2 }Verify retry, loading, and error handling
Check that loading indicators appear without layout shift, controls prevent accidental duplicate submissions, retry logic is bounded, errors remain actionable, and a late response does not overwrite newer state.
Write repeatable QA scenarios
For each case, record the seed, record count, auth mode, latency, error rate, setup request, action, and expected UI. Reset the local runtime between cases that mutate shared state.
Scenario: expired session while loading orders
Seed: 42
Latency: 800 ms
Auth: bearer, expired token
Expected: sign-in prompt; no stale order listRelated questions
Can the runtime add random latency?
No. Latency is a fixed value; use several fixed values to create repeatable timing scenarios.
Keep exploring
Last updated September 17, 2026. Product behavior described here is verified against the current Mock API Studio runtime.