How do you choose HTTP status codes for successful and failed API operations without making every endpoint behave differently?

Choose HTTP status codes for real API outcomes

Maps creation, updates, asynchronous work, validation, authorization, conflicts, and failures to useful HTTP outcomes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I choose the code from what happened at the HTTP boundary. A normal read or update can return 200, creation commonly returns 201 with a Location header, accepted background work can return 202, and a successful operation with no response body can return 204. Invalid syntax or request shape is usually 400. Missing authentication is 401, insufficient permission is 403, absence is 404, and a current-state conflict can be 409. Unexpected server failures stay in the 5xx range.

Full answer below

Practice focus

200, 201, 202, 204, 400, 401, 403, 404, 409, 412, 422, 429, 5xx responses, Location, and ProblemDetails.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Status codes are part of the contract consumed by browsers, SDKs, gateways, retries, caches, tests, and support tools. A precise outcome makes failures easier to handle without encoding every decision in response text.
I choose the code from what happened at the HTTP boundary. A normal read or update can return 200, creation commonly returns 201 with a Location header, accepted background work can return 202, and a successful operation with no response body can return 204. Invalid syntax or request shape is usually 400. Missing authentication is 401, insufficient permission is 403, absence is 404, and a current-state conflict can be 409. Unexpected server failures stay in the 5xx range.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I define a small outcome matrix for the API instead of choosing codes ad hoc in each controller. Validation may use 400 consistently, or 422 when the organization deliberately distinguishes a well-formed representation that cannot be processed. A failed precondition such as a stale If-Match validator is 412, while rate limiting is 429. A 202 response should identify a status resource or operation ID; otherwise the client has no honest way to follow the work. Error bodies use one ProblemDetails shape with stable machine-readable codes.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning 200 for every response and placing success in a JSON flag.
Using 500 for validation, conflicts, or known dependency outcomes.
Returning 202 without a status URL or operation identifier.
Choosing different error shapes for each status code.

How do you choose HTTP status codes for successful and failed API operations without making every endpoint behave differently?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement