HTTP Status Code Lookup

HTTP statuses split by the first digit. 1xx Informational signals interim states like Continue or Switching Protocols. 2xx Success means the request worked (200 OK, 201 Created, 204 No Content). 3xx Redirection points the client elsewhere (301, 302, 304, 307, 308). 4xx Client Error blames the request (400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests). 5xx Server Error blames the server (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout). RFC 9110 is the current canonical reference for the core set.

Both mean success, but they differ on the body. 200 OK returns a response body that describes the result, typical for GET requests and most API calls. 204 No Content says the request succeeded and there is deliberately nothing to send back. A 204 response must not include a body. Use 204 for successful DELETEs, idempotent PUT updates where the client already has the new state, and tracking pixels or analytics endpoints. As a bonus, browsers will not navigate away on a 204, which is occasionally useful for fire-and-forget form posts.

301 Moved Permanently and 308 Permanent Redirect both mean the move is permanent and search engines should update their index. 302 Found and 307 Temporary Redirect mean the move is temporary and the original URL should be kept. The other axis is method preservation: 301 and 302 were historically allowed to rewrite POST to GET (most clients do), while 307 and 308 must preserve the original method. Use 308 for permanent moves of POST endpoints (webhooks, API versions). Use 307 for temporary redirects of non-GET requests. Use 301 for canonical URL changes and SEO-safe permanent redirects of GET. Use 302 only when you specifically want the legacy POST-to-GET rewrite.

Yes, in a manner of speaking. RFC 2324 defined the Hyper Text Coffee Pot Control Protocol as an April Fools' joke in 1998, and RFC 7168 extended it for teapots in 2014. It is a formally registered code but it is not part of mainstream HTTP. In practice, some sites and frameworks return 418 deliberately as a non-standard signal to misbehaving bots or scrapers, since real clients should never see it. If your application is hitting 418 from an API, it almost always means the server is rejecting your client on a bot heuristic, not that you actually asked for coffee from a teapot.

429 means the client has sent too many requests in a given amount of time and the server is rate-limiting you. RFC 6585 defines it, and virtually every public API uses it. The server should include a Retry-After header telling you when it is safe to try again, either as a number of seconds or as an HTTP date. The correct client behaviour is to read Retry-After, wait that long, then retry. Add exponential backoff with jitter so a fleet of clients does not all hammer the endpoint at the same instant when the window opens. Long term, cache responses, batch requests, or ask the provider for a higher rate limit.