HTTP Status Code Reference

Server received the request headers, client should proceed to send the body.

💡 Normal — no action needed.

Server agrees to switch protocols (e.g., HTTP to WebSocket).

💡 Expected during WebSocket handshake.

Request succeeded. The response body contains the requested data.

💡 Success — no action needed.

Request succeeded and a new resource was created. Used for POST requests.

💡 Success — resource created.

Request succeeded but there is no content to return. Common for DELETE.

💡 Success — no body expected.

Server is delivering only part of the resource due to a Range header.

💡 Expected for range requests (streaming, downloads).

Resource has permanently moved to a new URL. Update your links.

💡 Update the URL in your code. Google transfers PageRank.

Resource temporarily at a different URL. Use original URL next time.

💡 Use 301 if permanent. Check if you need to preserve POST method.

Resource has not changed since last request. Use cached version.

💡 Normal caching behavior — no action needed.

Server cannot process the request due to malformed syntax or invalid data.

💡 Check request body, headers, and query parameters for syntax errors.

Authentication is required. Missing or invalid credentials.

💡 Add or refresh the Authorization header. Check token expiry.

Server understood the request but refuses to authorize it.

💡 Check permissions and roles. Token may lack required scopes.

Resource does not exist at this URL.

💡 Verify the URL path, check if resource was deleted or renamed.

HTTP method not supported for this endpoint (e.g., GET on a POST-only route).

💡 Check the allowed methods in the response Allow header.

Server timed out waiting for the client to send the request.

💡 Retry with a faster connection or increase client timeout.

Request conflicts with current state of the resource (e.g., duplicate entry).

💡 Check for existing resources before creating. Handle optimistic locking.

Resource was permanently deleted and will not return.

💡 Remove references to this resource. Unlike 404, it will never come back.

Request is well-formed but contains semantic errors (invalid field values).

💡 Validate request body against API schema. Check field types and constraints.

Rate limit exceeded. Client has sent too many requests in a given timeframe.

💡 Implement exponential backoff. Check Retry-After header for wait time.

Unexpected server error. Something went wrong on the server side.

💡 Check server logs immediately. Could be code bug, DB connection, or OOM.

Upstream server returned an invalid response to the gateway/proxy.

💡 Check upstream service health. Common with Nginx proxying to Node/Python.

Server is temporarily unavailable — overloaded or under maintenance.

💡 Check server capacity. Implement retry logic with backoff in clients.

Upstream server did not respond in time to the gateway.

💡 Increase upstream timeout. Check if backend is slow or unresponsive.