Search HTTP status codes and quickly understand meanings, categories, common causes, and typical API usage.
Search by code, reason phrase, category, cause, header, or debugging keyword.
22 matching status codes grouped by response class.
Interim responses sent before the final response.
The request was received, understood, and accepted.
The client needs to use another resource or cached representation.
The request cannot be completed because of client-side input, auth, or state.
The server or upstream dependency failed while handling a valid-looking request.
The request succeeded and the response body contains the requested representation or action result.
HTTP/1.1 200 OK
HTTP response codes tell clients whether a request is still in progress, succeeded, redirected, failed because of the request, or failed because of the server path.
1xx codes are interim signals, 2xx codes confirm success, 3xx codes redirect or reuse cache, 4xx codes point to request-side problems, and 5xx codes point to server or upstream failures.
Use 200 OK for a successful response with a body, 201 Created after creating a resource, 202 Accepted for queued async work, and 204 No Content when there is nothing to return.
401 Unauthorized usually means the request needs valid authentication. 403 Forbidden usually means the caller is known but does not have permission for the action or resource.
404 Not Found is the general response for a missing current resource. 410 Gone is more explicit: the resource was intentionally removed and is not expected to come back.
429 Too Many Requests is useful for API quotas, burst limits, and abuse controls. A Retry-After header or rate-limit headers help clients back off without guessing.
500 is a general application failure. 502 points to a bad upstream response, 503 to temporary unavailability, and 504 to an upstream timeout.
No. The status-code data is a static local dataset owned by DevCoreTools and searched in your browser.
The lookup covers the common codes developers debug most often across informational, success, redirection, client error, and server error classes.
Both patterns exist. Use 400 for malformed or broadly invalid requests. Use 422 only when your API contract deliberately separates syntactically valid input from semantic validation failures.
Use 401 when authentication is missing, invalid, or expired. Use 403 when the caller is authenticated or identified but not allowed to perform the action.
429 Too Many Requests is the usual response. Include retry timing or rate-limit metadata when clients can safely retry later.