HTTP Status Codes Every Frontend Developer Should Test

200 OK: The Happy Path

A 200 response means the request succeeded and the server returned data. This is the baseline for normal response rendering—but it is not enough to stop testing there.

Even on 200 responses, test empty arrays, partial data, and missing optional fields. Backends often return valid 200 payloads with unexpected shapes.

{
  "id": 123,
  "name": "Alex Carter",
  "status": "active"
}

201 Created: Successful Creation

Use 201 when a resource is created—form submissions, new records, or signup flows. Test that your app handles redirect behavior, success toast messages, and optional response bodies (some APIs return the created object, others return only a Location header).

204 No Content: Success Without a Body

A 204 means success with no response body. Common for delete actions, update operations, and logout requests. The frontend should not call response.json() on a 204.

This is one of the most common frontend bugs: code assumes every successful response includes JSON. Test 204 explicitly in your API response testing workflow.

400 Bad Request: Validation Errors

A 400 indicates the request was malformed or failed basic validation—invalid form fields, missing required fields, or bad payload structure. Map field-level errors to your form UI instead of showing a generic failure message.

{
  "error": "Email is required"
}

401 Unauthorized: Login Required

401 means authentication is missing or invalid—expired sessions, missing tokens, or wrong credentials. Your app should redirect to login, refresh tokens when supported, and clear stale auth state without leaving infinite loaders.

403 Forbidden: Logged In, But Not Allowed

The 400 vs 401 vs 403 distinction matters for frontend error handling:

• 401 Unauthorized: authentication is missing or invalid—the user needs to sign in or refresh credentials.
• 403 Forbidden: the user is authenticated but lacks permission for this action or resource.

Treating 401 and 403 the same leads to wrong UX—redirecting logged-in users to login when they actually need a permission-denied message.

404 Not Found: Missing Resources

404 responses appear when records are deleted, IDs are wrong, or links are broken. Test empty states, recovery actions, and navigation away from dead-end screens.

409 Conflict: State Conflicts

A 409 indicates a conflict with the current state—duplicate records, version conflicts, or concurrent edits. Show clear messaging and let users resolve the conflict instead of failing silently.

422 Unprocessable Entity: Semantic Validation Errors

Unlike 400, a 422 often means the JSON was valid but failed business rules—duplicate emails, invalid date ranges, or cross-field validation. Display API validation messages at the form level so users can fix input without guessing.

429 Too Many Requests: Rate Limits

Rate-limited APIs return 429 when clients send too many requests. Test retry UI, cooldown messages, disabled submit buttons, and logic that prevents duplicate submissions during throttling.

500 Internal Server Error: Backend Failure

A 500 means something went wrong on the server. Use fallback UI, user-friendly messaging, and structured logging for debugging—never expose raw stack traces to end users.

{
  "error": "Internal server error"
}

503 Service Unavailable: Temporary Downtime

503 signals temporary unavailability—maintenance windows or overloaded services. Show retry-later messaging and consider exponential backoff for automatic retries.

How to Test These Status Codes with Mock APIs

You do not need a failing staging server to test HTTP error codes. With MockFlow, you can create response profiles and switch between 200, 400, 401, 403, 404, 429, and 500 responses to validate frontend UI states before production.

• Define multiple response profiles per endpoint.
• Simulate delayed responses alongside error status codes.
• Test loading, error, and empty states without backend changes.
• Start in guest mode without signup for quick experiments.
• Use account mode when you need public endpoints for shared environments.

Guest mode stores data locally in your browser and does not create public API URLs. Use account mode when teammates or CI need hosted, shareable mock endpoints.

For related workflows, read how to mock API responses without a backend, mock APIs for React and Next.js, and simulating slow API responses.

HTTP Status Code Testing Checklist

Use this checklist during frontend API testing before each release:

• Test success responses (200, 201) including empty and partial payloads.
• Test validation errors (400, 422) with field-level messages.
• Test auth expiration (401) and login redirect flows.
• Test permission failures (403) for role-restricted actions.
• Test deleted or missing resources (404).
• Test rate limits (429) and retry cooldown UI.
• Test server errors (500, 503) with fallback and retry options.
• Test empty responses (204) without expecting JSON bodies.
• Test slow error responses to catch loader and race-condition bugs.

Common Frontend Mistakes

• Assuming every response has a JSON body (breaks on 204).
• Treating 401 and 403 the same way.
• Ignoring 204 No Content in delete and update flows.
• Showing raw backend error strings to users.
• Not disabling submit buttons during in-flight requests.
• Missing retry behavior for 429, 500, and 503 responses.
• Not testing mobile latency and slow network conditions.

Teams building without a ready backend should also review frontend development without a backend for workflow patterns that pair mock APIs with realistic status-code testing.