Stop guessing what went wrong. An interactive, searchable reference guide for understanding REST API responses and debugging server communication errors.
Continue
The server has received the request headers; the client should proceed.
Switching Protocols
The server is switching protocols as requested (e.g. WebSocket upgrade).
OK
The request succeeded.
Created
The request succeeded and a new resource was created.
Accepted
The request was accepted for processing but processing is not complete.
No Content
The request succeeded but there is no content to return.
Partial Content
The server is returning only part of the resource (range request).
Moved Permanently
The resource has been permanently moved to a new URL.
Found
The resource is temporarily at a different URL.
Not Modified
The cached version is still valid; no body is returned.
Temporary Redirect
Redirect to the new URL using the same HTTP method.
Permanent Redirect
Permanent redirect; method and body must not change.
Bad Request
The server cannot process the request due to a client error.
Unauthorized
Authentication is required and has failed or not been provided.
Forbidden
The server understood the request but refuses to authorize it.
Not Found
The requested resource could not be found on the server.
Method Not Allowed
The HTTP method is not allowed for this resource.
Request Timeout
The server timed out waiting for the request.
Conflict
The request conflicts with the current state of the resource.
Gone
The resource is no longer available and will not be available again.
Content Too Large
The request body is larger than the server is willing to process.
URI Too Long
The URI provided was too long for the server to process.
Unsupported Media Type
The media format of the requested data is not supported.
Unprocessable Content
The request was well-formed but has semantic errors.
Too Many Requests
The client has sent too many requests in a given time (rate limiting).
Internal Server Error
The server encountered an unexpected condition.
Not Implemented
The server does not support the functionality required.
Bad Gateway
The server received an invalid response from an upstream server.
Service Unavailable
The server is temporarily unable to handle the request.
Gateway Timeout
The upstream server did not respond in time.
Understand the precise difference between an authentication failure and a server-side timeout.
Every code listed is pulled directly from the official IETF RFC documentation, ensuring you are adhering to strict, global internet standards.
Don't waste time scrolling through massive Wikipedia articles. Type 'gateway' or 'timeout' into the search bar to instantly isolate the exact error code you are facing.
Clearly differentiate between the confusing 4xx class errors. Learn exactly when to throw a 401 Unauthorized versus a 403 Forbidden in your backend middleware.
An HTTP Status Code is a three-digit integer sent by a web server in response to a client's network request. It serves as a short, standardized message telling the web browser (or API client) exactly what happened. Without status codes, your browser would have no idea if a website loaded successfully or if the server caught on fire.
The first digit of the code dictates the "Class" of the response. Senior engineers use an HTTP Status Code Reference to quickly isolate the system responsible for an outage:
200 OK or 201 Created).301 Moved Permanently).404 Not Found).500 Internal Server Error).Junior backend developers often make the mistake of returning a '200 OK' for everything, even when an error occurs.
Imagine you try to delete a user from a database via an API, but the user doesn't exist. If the server returns a 200 OK with a JSON message saying { error: 'User not found' }, you have broken the REST standard.
Frontend libraries (like Axios or Fetch) rely on the 3-digit status code to trigger their .catch() error-handling blocks. If you return a 200, the frontend assumes the deletion was successful and crashes. You must strictly enforce status codes—in this case, by returning a 404 Not Found.
If you are debugging a broken web application, these are the three most critical codes to investigate:
This means the JSON payload you sent to the API is malformed. The server was expecting an integer for the 'age' field, but you sent a string. The server rejected the data to prevent database corruption.
You hit a Rate Limit. The API provider (like OpenAI or Twitter) detected that your script is sending hundreds of requests per second. They temporarily blocked your IP address to prevent a DDoS attack.
The server is physically alive but cannot handle your request right now. This usually means the server is down for scheduled maintenance, or it is completely overloaded by massive traffic spikes.