Developer English guide
HTTP Status Codes Every Developer Should Know
July 27, 2026
Understanding HTTP status codes is essential for debugging APIs, writing clear error responses, and communicating with teammates. This guide covers the most common codes with plain-English definitions and real developer scenarios.
2xx: Success
The server received the request, understood it, and processed it successfully. These are the codes you want to see.
OK
The request succeeded. The server returns the requested resource in the response body. This is the default success status for GET, PUT, and PATCH requests.
Developer scenario
GET /api/users/42 returns 200 with the user object in the body.
Created
A new resource was successfully created. The server typically includes a Location header pointing to the new resource. Use this for POST requests that create records.
Developer scenario
POST /api/users with a valid body returns 201 and a Location: /api/users/43 header.
No Content
The request succeeded but there is nothing to return in the body. Common for DELETE operations and PUT requests where the client already knows the new state.
Developer scenario
DELETE /api/users/42 returns 204 with an empty body — the record is gone.
3xx: Redirection
The resource has moved or the client needs to take an additional step to complete the request. The browser or HTTP client usually handles these automatically.
Moved Permanently
The resource has a new permanent URL. Search engines update their index to the new URL. Use this when you rename an endpoint or migrate a website and need SEO value to transfer.
Developer scenario
GET /api/v1/customers redirects 301 to /api/v2/customers after an API version bump.
Found
The resource is temporarily at a different URL. Unlike 301, the original URL remains valid. Clients should keep using the original URL for future requests. Common in OAuth login flows.
Developer scenario
GET /auth/google redirects 302 to Google's OAuth consent screen.
Not Modified
The resource has not changed since the version the client already has cached. The server sends no body — the client uses its cached copy. This reduces bandwidth and speeds up repeat requests.
Developer scenario
GET /api/config with an If-None-Match header returns 304 when the config has not changed.
4xx: Client Errors
Something is wrong with the request itself. The server understood it, but will not fulfill it because of a problem on the client side: bad data, missing auth, or a resource that does not exist.
Bad Request
The server cannot process the request because the syntax is malformed or a required field is missing. Always include an error message in the response body explaining what is wrong.
Developer scenario
POST /api/orders with a missing "quantity" field returns 400: { "error": "quantity is required" }.
Unauthorized
The client is not authenticated. The name is misleading — it really means unauthenticated. The request is missing a valid token or the token has expired. The client should log in and retry.
Developer scenario
GET /api/orders without an Authorization header returns 401 with a WWW-Authenticate hint.
Forbidden
The client is authenticated but does not have permission to access this resource. Unlike 401, sending credentials again will not help. This is an authorization error, not an authentication error.
Developer scenario
GET /api/admin/users by a regular user returns 403 — they are logged in but not an admin.
Not Found
The requested resource does not exist at this URL. It may have been deleted, never existed, or the URL is wrong. Also used to hide the existence of private resources from unauthorized users.
Developer scenario
GET /api/users/9999 returns 404 when no user with ID 9999 exists in the database.
Conflict
The request conflicts with the current state of the server. Typical causes: trying to create a resource that already exists, or an optimistic locking conflict when two clients update the same record.
Developer scenario
POST /api/users with an email that is already registered returns 409: { "error": "email already in use" }.
Unprocessable Entity
The request body is syntactically valid (unlike 400) but semantically wrong. The data cannot be processed because it violates business rules or validation constraints. FastAPI and Rails use this heavily.
Developer scenario
POST /api/transfers with { amount: -50 } returns 422 — JSON is valid, but a negative amount makes no sense.
Too Many Requests
The client has sent too many requests in a given time window. The server is rate limiting the client. The response usually includes a Retry-After header telling the client how long to wait.
Developer scenario
Hitting a public API 100 times in one second returns 429 with Retry-After: 60.
5xx: Server Errors
The server failed to fulfill a valid request. The problem is on the server side — not the client's fault. These always warrant investigation and should trigger alerts in production.
Internal Server Error
Something unexpected went wrong on the server. This is the generic catch-all for unhandled exceptions. If you see this in production, there is a bug. Check your logs immediately.
Developer scenario
An unhandled NullPointerException in the order service causes every POST /api/orders to return 500.
Bad Gateway
A server acting as a gateway received an invalid response from an upstream server. Common when your load balancer or reverse proxy cannot reach the backend, or when the backend crashes mid-response.
Developer scenario
Your Nginx proxy returns 502 when the Node.js process behind it crashes during a deploy.
Service Unavailable
The server is temporarily unable to handle requests. Typical causes: the server is overloaded, is starting up, or is in maintenance mode. Usually temporary. The Retry-After header tells clients when to try again.
Developer scenario
During a database migration, the API returns 503 with Retry-After: 300 to tell clients to wait 5 minutes.
Gateway Timeout
A server acting as a gateway did not receive a response in time from an upstream server. Similar to 502 but the upstream server did not respond at all, instead of responding with an error.
Developer scenario
Your API gateway returns 504 when a slow database query exceeds the 30-second timeout.
Key Takeaways
2xx means success. 201 Created is more precise than 200 OK when you create a new resource.
401 means unauthenticated (no valid credentials). 403 means unauthorized (valid credentials, but no permission). They are not the same.
400 Bad Request means the syntax is wrong. 422 Unprocessable Entity means the syntax is fine but the data violates business rules.
5xx errors are always server-side bugs. If you see them in production, check your logs right away.
429 Too Many Requests means you are being rate limited. Always implement exponential backoff in your HTTP client.
304 Not Modified is your friend for caching. Use ETag and If-None-Match headers to avoid sending data the client already has.
Related articles
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.