The core codes are 200 OK, 400 Bad Request and 500 Internal Server Error. The first digit gives the class: 2xx means success, 4xx a client error and 5xx a server error.
200 OK for a successful GET, PUT or PATCH.
201 Created for a successful POST.
204 No Content for a successful DELETE or PUT with no response body.
400 Bad Request for invalid request syntax.
401 Unauthorized when authentication is required.
403 Forbidden when access is denied.
404 Not Found for a missing resource.
409 Conflict when the request conflicts with the current state.
422 Unprocessable Content when the body parses but fails validation.
500 Internal Server Error for a generic server error.
503 Service Unavailable when the server is temporarily unavailable.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
The status code tells machines whose fault the failure was and whether to retry. The error body tells a developer what to fix, and it is never an apology.
For this question · chapter 1 of 3The shelf at the bottom holds each code in this answer, plus 429 for too many requests, and the walk lights each one. Every code followed one lane. Step back through the walk to see the lane each code took and whether its retry gate was open.
1/3The code routes the failure
The code routes the failure
A request usually gets back one of three kinds of status code: 2xx is done, 4xx is your problem, 5xx is my problem. The first digit tells the caller whose problem this is. The same digit says whether retrying can help.
The server cannot parse this POST body, so the server returns 4xx. Retrying will not help, because 4xx means the same request will fail the same way again. So the client must change the request, not send it again. Code that retries a 400 wastes everyone's time.
A database timeout comes back as a 5xx, and this time a retry can help. A 5xx means the server failed, so the same request may work in a moment. A second call finds the server overloaded, so the server returns a 503, often with a Retry-After header that says how long to wait. Both codes permit a retry.
The 101st call within one minute gets 429, in the 4xx family. But this is the one 4xx where a retry helps, after a wait. The Retry-After header tells the client exactly how long to wait. The client should honour that header.
A request with no token gets 401. The server does not know who is asking, so it asks for a login first. A 401 is a question about identity, and the fix is credentials, not a retry. A retry with no credentials gets the same 401 again.
Now the same request carries user 124's token, and the server returns 403. The server knows exactly who is asking and still refuses. In interviews, 401 and 403 get confused more than any other pair. A 401 means I do not know who you are. A 403 means I know who you are, and the answer is still no. Retrying changes nothing.
Two more POSTs get codes in the 4xx range, the client-error codes. The server cannot read the first body, so the server returns 400 again. The server can read the second body, but that body breaks a rule, for example a qty of minus one. A readable body that breaks a rule gets 422.
Codes 200, 201 and 204 all mean success. Code 404 means the thing is not there, or the API will not confirm that the thing exists. Code 409 means the request conflicts with the current state. Those twelve codes cover almost every API you will design.
Chapter 1 · step 1 of 8
A request usually gets back one of three kinds of status code: 2xx is done, 4xx is your problem, 5xx is my problem. The first digit tells the caller whose problem this is. The same digit says whether retrying can help.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
When do you return 401 and when 403?401 means the caller isn't authenticated or the credentials are bad, so logging in may help. 403 means the server knows who they are and still refuses.
A JSON body parses fine but the email field is invalid. Do you return 400 or 422?400 fits malformed syntax. 422 fits a body that parses but breaks validation rules. Pick one convention and use it across the whole API.
Why not return 200 for every response and put an error flag in the body?Clients, proxies, caches, monitoring and retry logic all read the status code. A 200 that hides a failure breaks each of them.
Which of these status codes should a client retry?503 and 429 can be retried with backoff that respects Retry-After. Most 4xx fail the same way again. Retrying a POST safely needs an idempotency key.
What you can say
Status codes tell the client what happened, and the first digit gives the class: 2xx is success, 4xx means the client got something wrong, 5xx means the server failed.
For success I use 200 for a normal GET, PUT or PATCH, 201 Created when a POST makes a new resource, and 204 No Content when there's no body to send back, like after a DELETE.
For client errors, 400 is a malformed request, 401 means you need to authenticate, 403 means access is denied, and 404 means the resource isn't there.
409 Conflict fits a request that clashes with the resource's current state, and 422 fits a body that parses fine but fails validation.
On the server side, 500 is a generic failure, and 503 says the service is temporarily unavailable, so the client knows trying again later may work.
A code on its own says little, so I pair every 4xx and 5xx with an error body the client can act on, and I never hide a failure behind a 200.
Weak answers to avoid
Mixes up 401 and 403Sending 403 for a missing token, or 401 to a logged-in user who lacks permission, confuses clients. 401 means authenticate. 403 means authenticated but not allowed.
Returns 200 with an error in the bodyClients, caches and alerts treat 200 as success, so nobody sees the failure. Use the matching 4xx or 5xx code and put the details in the body.
Uses 500 for bad client inputBlaming the server for the client's mistake sets off alerts and invites pointless retries. Validation failures are 400 or 422, not 500.
Recites codes with no use caseA list of numbers shows memory, not judgment. Tie each code to when you'd send it, like 201 after a POST creates something or 409 on a state conflict.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
