1xx
Informational
The request was received and processing continues.
HTTP reference / Status codes
HTTP status codes, explained for API builders and debuggers
Browse the meaning of HTTP status codes from 100 Continue through 511 Network Authentication Required, with links to detailed pages for common API errors.
definitionheadersretrydebug path
Choose by blocked outcome
Six useful doors. Not six hundred landing pages.
01Unblock developmentCreate a dependency before the production API exists.↗02Reproduce a failureKeep the request, response, and first divergence together.↗03Protect behaviorTurn client expectations into inspectable API tests.↗04Review a changeClassify contract impact before clients discover it.↗05Connect an assistantExpose bounded tools through a visible protocol surface.↗06Review API riskSeparate observed security evidence from inference.↗
Search intent
Use the HTTP status code reference when a response number needs to become an engineering decision: retry, redirect, authenticate, fix the request, investigate the server, or update a test expectation.
Why this page exists
A practical answer, not a doorway page.
HTTP status codes are compact by design, but they are not self-explanatory in real systems. A 404 can mean a missing entity, an intentionally hidden resource, a routing error, or a stale client URL. A 503 can mean maintenance, overload, deployment trouble, or a proxy protecting an upstream service.
HTTPStatus treats status codes as the beginning of diagnosis. The reference page groups codes by class, links to detailed explanations for common responses, and connects each code to the workflows where it matters: request inspection, API tests, mocks, redirects, retries, monitoring, and incident debugging.
Reference hub
Start with the class, then inspect the exact code.
The first digit tells you the broad outcome. The exact code tells you what a client, proxy, cache, monitor, retry policy, or API test should do next.
2xx
Success
The request was accepted, processed, or fulfilled.
3xx
Redirection
The client needs another request or cached representation.
4xx
Client error
The request cannot be completed as sent by the client.
5xx
Server error
The server or an upstream dependency failed to complete the request.
Where it earns its keep
Concrete situations this workflow is built for.
Debug an API response
Look up the exact code, then inspect headers, body, timing, and upstream behavior.
Design API errors
Choose precise 4xx and 5xx responses instead of returning one generic failure for every case.
Build client handling
Decide when to retry, redirect, reauthenticate, show validation feedback, or fail fast.
Write tests and mocks
Model expected success, error, redirect, rate-limit, and maintenance responses explicitly.
Working sequence
The shortest honest path from input to evidence.
- 01
Identify the class
Use the first digit to separate informational, success, redirect, client error, and server error responses.
- 02
Read the specific code
Compare the exact status against nearby codes such as 401 vs 403, 404 vs 410, or 502 vs 504.
- 03
Test the behavior
Use the playground, HTTP client, mocks, or API tests to verify how your client handles the response.
Output worth keeping
The result should leave behind evidence, not just a momentary answer.
- 01Status class and exact code
- 02Meaning and common interpretation
- 03Headers that may change behavior
- 04Related codes that are easy to confuse
- 05Next workflow for testing or debugging
Operating principle
The design constraint that keeps this useful.
A status code is a compact signal, not a full diagnosis. HTTPStatus keeps the reference connected to request evidence, headers, payloads, retries, caching, and testing workflows.
Decision guide
How to know this is the right next move.
Start here when
Look up the exact code, then inspect headers, body, timing, and upstream behavior.
Also useful for
Choose precise 4xx and 5xx responses instead of returning one generic failure for every case.
A solid result includes
At minimum: Status class and exact code, Meaning and common interpretation, Headers that may change behavior.
Move next to HTTP client
Send a request and inspect the actual response.
Boundary to remember
Can I test a code from this page? Yes. Use the status playground, HTTP client, or mock server to create and inspect real responses for the code you are studying.
Trust checklist
Before the output becomes part of a team workflow.
- Start with the first digit, then read the exact code.
- Check headers such as Location, WWW-Authenticate, Retry-After, Cache-Control, and Content-Type.
- Do not use 500 when a precise 4xx client error is available.
- Treat 502, 503, and 504 as different operational signals.
- Add tests for client behavior around important non-200 responses.
Questions worth answering
Before you put it into a real workflow.
What are HTTP status codes?
They are three-digit response codes sent by a server to summarize how an HTTP request was handled.
Which codes matter most for APIs?
Common API workflows frequently depend on 200, 201, 204, 301, 302, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503, and 504.
Can I test a code from this page?
Yes. Use the status playground, HTTP client, or mock server to create and inspect real responses for the code you are studying.
Next move
Start with one concrete API problem.
Keep the first step small. Move into a workspace when the result deserves to be saved, repeated, or shared.