The Frontend API Error Testing Checklist: 25 Failure Cases to Test Before Release

1. HTTP status codes

• 500 Internal Server Error: does the UI show a retry option instead of a blank screen?
• 502 / 503 / 504: are gateway errors retried with backoff, and not in a tight loop?
• 404 Not Found on a detail page: is there a proper not-found state?
• 400 / 422 validation errors: are field errors mapped back to the form?
• 409 Conflict: is the "someone else changed this" case handled?

Simulate with HTTP error code rules.

2. Timing and network

• Slow response (3–10 s): loading skeleton visible, no layout jump when data arrives.
• Request timeout: does your client time out at all, and what does the user see?
• Out-of-order responses: a slow earlier search result must not overwrite a newer one.
• Offline or dropped request: is there an offline message and a retry?
• Double submit while a slow POST is pending: is the button disabled?

Simulate with latency rules and slow 3G testing.

3. Payload shape

• Empty list []: is there an empty state, not a broken table?
• Huge list (5,000+ items): does it paginate or virtualise?
• Null or missing field: does user.address.city crash the render?
• Unexpected enum value: an unknown status should not break a switch statement.
• Malformed JSON or HTML error page with status 200: is parsing wrapped in a try/catch?
• Very long strings and emoji: truncation and wrapping behave correctly.

Use deep merge to null one field while keeping the rest real.

4. Authentication and permissions

• 401 on any call: the session expires cleanly and returns to login with a message.
• Token refresh fails: no infinite refresh loop.
• 403 on one resource: a friendly "no access" message, not a generic error.
• Feature-flag or plan change: the UI updates when plan flips from free to pro.

See testing expired JWT tokens and session timeouts.

5. Third parties and rate limits

• 429 Too Many Requests with Retry-After: is the header respected?
• Analytics or ads script blocked: the page still works when trackers are blocked.
• Payment provider slow or down: checkout shows a clear state and does not double-charge.
• CDN asset fails: fonts or images have sensible fallbacks.
• CORS error from a new domain: caught in development, not production.

See blocking third-party requests.

Make it repeatable

Save each case as a named rule in a shared ProxyCeptor workspace, so every tester can toggle "Checkout 503" or "Empty orders" without writing anything. That turns the checklist into a one-click regression pass. See the QA engineers use case.

Frequently asked questions

Read next