Continue
The server has received request headers and the client should proceed to send the body.
Learn API response codes with examples, tester notes, common mistakes, and interview-friendly explanations.
{
"id": 123,
"name": "Ada Lovelace",
"role": "engineer"
}Search by code, name, or keyword. Filter by category to focus on what matters.
The server has received request headers and the client should proceed to send the body.
The server agrees to switch protocols as requested by the client.
The request succeeded and the response contains the requested resource.
The request was successful and a new resource was created.
The request was accepted for processing but has not completed yet.
The request succeeded and there is no content to return.
The resource has been permanently moved to a new URL.
The resource is temporarily located at a different URL.
Cached version is still valid — no body is returned.
The server cannot process the request due to malformed syntax or invalid input.
Authentication is required and has failed or has not been provided.
The user is authenticated but does not have permission to access the resource.
The requested resource does not exist on the server.
The HTTP method is not supported for this resource.
The client did not send a complete request in the time the server was prepared to wait.
The request conflicts with the current state of the resource.
The request payload format is not supported by the server.
The request was well-formed but contains semantic validation errors.
The client has sent too many requests in a given amount of time.
The server encountered an unexpected condition that prevented it from fulfilling the request.
The server does not support the functionality required to fulfill the request.
The server, acting as a gateway or proxy, received an invalid response from upstream.
The server is temporarily unable to handle the request, often due to overload or maintenance.
The gateway did not receive a timely response from the upstream server.
Side-by-side breakdowns of the status codes developers most often mix up.
The request succeeded. Use for successful GET, PUT, PATCH responses with a body.
The request succeeded and a new resource was created. Use for successful POST that creates a resource.
The request lacks valid authentication. Token missing, expired, or invalid.
Authentication worked but the user is not allowed to access this resource.
Malformed request — bad JSON, missing required fields, wrong types.
Well-formed request but semantic validation failed, e.g. invalid email format.
Resource does not exist or never did. Default for missing items.
Resource used to exist but has been intentionally removed and will not return.
Unexpected server-side failure. Indicates a bug or unhandled exception.
Server is temporarily unable to respond — overload, maintenance, or upstream outage.
Real API scenarios mapped to the status codes you should assert against.
Five quick multiple-choice questions. Pick an answer and see instant feedback.
Common interview questions on REST and HTTP — with crisp, interview-ready answers.
200 OK means the request succeeded. 201 Created means the request succeeded AND a new resource was created — typically returned from a POST that creates an entity, often with a Location header pointing to the new resource.
401 Unauthorized means the request lacks valid authentication. 403 Forbidden means the user is authenticated but does not have permission for that action.
When the request is malformed — invalid JSON, missing required fields, wrong types. For semantic validation issues (e.g. invalid email format), 422 Unprocessable Content is often a better choice.
An unhandled exception or unexpected condition on the server prevented the request from completing. It always indicates a server-side bug worth investigating.
200, 201, 204, 400, 401, 403, 404, 409, 422, 429, 500, and 503 cover the vast majority of REST API scenarios.
422 Unprocessable Content is preferred for semantic validation errors. 400 Bad Request is acceptable when the API treats validation generically.
502 Bad Gateway means the upstream returned an invalid response. 504 Gateway Timeout means the upstream did not respond in time.
Everything you need to know about HTTP status codes.
HTTP status codes are three-digit numbers servers return to indicate the result of an HTTP request — success, redirection, client error, or server error.
1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Error, and 5xx Server Error.
200, 201, 204, 301, 302, 304, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503, and 504.
200 OK with the resource representation in the response body.
201 Created when a new resource is created, or 200 OK when the action succeeded without creating a resource.
4xx codes indicate the client made an invalid request. 5xx codes indicate the server failed to fulfill an otherwise valid request.
Status codes are the first signal of whether an API behaves correctly. Tests assert on them to validate happy paths, error handling, authentication, and rate limiting.