Look up status codes, meanings and typical usage.
The server received the request headers and the client should send the body.
Typical use: Rare in JSON APIs. Used with Expect: 100-continue for large uploads.
The server agrees to switch protocols as requested by the client.
Typical use: Response to a WebSocket upgrade handshake.
The server has accepted the request but has not completed it yet.
Typical use: WebDAV. Prevents client timeouts on long operations.
Preliminary headers sent before the final response.
Typical use: Lets browsers preload assets while the server prepares the page.
The request succeeded.
Typical use: Default for successful GET, PUT and PATCH. Return the resource in the body.
The request succeeded and a new resource was created.
Typical use: POST that creates a resource. Include a Location header and the new object.
The request was accepted for processing but is not complete.
Typical use: Async jobs and queues. Return a job ID or status URL to poll.
The response was modified by a proxy from the origin's 200 response.
Typical use: Rare. Transforming proxies.
The request succeeded but there is no body to return.
Typical use: DELETE, or PUT/PATCH when you don't return the updated resource.
The request succeeded; the client should reset the document view.
Typical use: Rare. Clearing a form after submission.
The server is delivering part of the resource due to a Range header.
Typical use: Range requests: video streaming, resumable downloads.
Multiple status codes for multiple independent operations.
Typical use: WebDAV batch operations.
Members of a binding have already been enumerated.
Typical use: WebDAV. Avoids repeating collections in PROPFIND.
The server fulfilled a GET with instance manipulations applied.
Typical use: Delta encoding. Very rare.
The request has more than one possible response.
Typical use: Content negotiation. Rarely used in APIs.
The resource has permanently moved to a new URL.
Typical use: Domain or path migrations. Clients and search engines cache this. May change POST to GET.
The resource temporarily resides at a different URL.
Typical use: Temporary redirects after login or form submission. May change POST to GET.
The response can be found at another URL using GET.
Typical use: POST-redirect-GET pattern to avoid duplicate form submissions.
The cached version is still valid; no body is sent.
Typical use: Conditional GET with ETag / If-None-Match or If-Modified-Since.
The resource must be accessed through a proxy.
Typical use: Deprecated for security reasons. Do not use.
Temporary redirect that preserves the request method and body.
Typical use: Use instead of 302 when POST must stay POST.
Permanent redirect that preserves the request method and body.
Typical use: Use instead of 301 when POST must stay POST, e.g. API endpoint moves.
The server cannot process the request due to a client error.
Typical use: Malformed JSON, missing required fields, invalid parameters. Return field-level errors.
Authentication is required or has failed.
Typical use: Missing, expired or invalid token. Include a WWW-Authenticate header. Means 'unauthenticated'.
Reserved for future use; sometimes used for billing limits.
Typical use: Some APIs use it when a quota or subscription is exhausted.
The client is authenticated but not allowed to do this.
Typical use: Valid token but insufficient permissions or role. Don't downgrade to 401.
The requested resource does not exist.
Typical use: Unknown ID or route. Also used to hide the existence of resources the user can't see.
The HTTP method is not supported for this resource.
Typical use: e.g. DELETE on a read-only endpoint. Include an Allow header.
No representation matches the Accept header.
Typical use: Content negotiation failures. Rare in JSON-only APIs.
The client must authenticate with the proxy first.
Typical use: Corporate proxies. Rare for app developers.
The server timed out waiting for the request.
Typical use: Slow clients or idle connections. Client may retry.
The request conflicts with the current state of the resource.
Typical use: Duplicate unique key (email already exists), version mismatch, optimistic locking failures.
The resource existed but has been permanently removed.
Typical use: Deprecated API versions or deleted content, when you want clients to stop retrying.
The request must include a Content-Length header.
Typical use: Rare. Some upload endpoints.
A precondition header (If-Match etc.) evaluated to false.
Typical use: Optimistic concurrency with ETags: the resource changed since the client read it.
The request body exceeds the server's limit.
Typical use: File uploads or payloads over the configured size limit.
The request URI is longer than the server will interpret.
Typical use: Huge query strings. Move data to a POST body.
The request's Content-Type is not supported.
Typical use: Sending form data to a JSON-only endpoint, or an unsupported file type.
The requested byte range is invalid.
Typical use: Range requests past the end of the file.
The Expect header could not be met.
Typical use: Rare. Expect: 100-continue handling.
The server refuses to brew coffee because it is a teapot.
Typical use: April Fools' joke from RFC 2324. Occasionally used as an easter egg.
The request was sent to a server that cannot produce a response.
Typical use: HTTP/2 connection reuse across hosts.
The request is well-formed but semantically invalid.
Typical use: Validation errors: syntactically fine JSON that fails business rules. Common alternative to 400.
The resource is locked.
Typical use: WebDAV. Also used for locked accounts in some APIs.
The request failed because a previous request failed.
Typical use: WebDAV batch operations.
The server is unwilling to process a request that might be replayed.
Typical use: TLS 1.3 early data. Rare.
The client must switch to a different protocol.
Typical use: Forcing an upgrade to a newer protocol version.
The server requires the request to be conditional.
Typical use: Forcing clients to use If-Match to avoid lost updates.
The client has sent too many requests in a given time.
Typical use: Rate limiting. Include Retry-After and rate limit headers.
Headers are too large for the server to process.
Typical use: Oversized cookies or auth headers.
Access is denied for legal reasons.
Typical use: Geo-blocking or content removed by legal demand.
An unexpected condition prevented the server from fulfilling the request.
Typical use: Unhandled exceptions. Log the details server-side; return a generic message and a request ID.
The server does not support the functionality required.
Typical use: Unrecognised HTTP method or a stubbed endpoint.
A gateway or proxy received an invalid response from the upstream server.
Typical use: Load balancer can't reach or gets garbage from the app server. Often seen during deploys.
The server is temporarily unable to handle the request.
Typical use: Maintenance windows or overload. Include Retry-After. Health checks often return this when not ready.
A gateway or proxy did not get a timely response from upstream.
Typical use: Upstream request exceeded the proxy timeout. Consider async processing.
The server does not support the HTTP version used.
Typical use: Rare.
Internal configuration error in content negotiation.
Typical use: Very rare.
The server cannot store the representation needed to complete the request.
Typical use: WebDAV. Disk-full situations.
The server detected an infinite loop while processing.
Typical use: WebDAV. Circular references.
Further extensions are required to fulfil the request.
Typical use: Obsolete.
The client must authenticate to gain network access.
Typical use: Captive portals on Wi-Fi networks.