400 vs 401 vs 403 vs 422: A Practical API Error Triage Workflow

If the server cannot reliably interpret the request structure, your first stop should be 400 Bad Request, not token rotation or role debugging. Broken JSON, impossible query combinations, invalid content-type headers, and malformed parameters often fail before any meaningful auth or business-rule logic runs.

This is why 400 should trigger a different mental model from 401 and 403. Before you ask whether the caller is allowed to do something, confirm the request was even shaped in a way the server could parse.

1. Reconstruct the exact request body and headers.
2. Validate the JSON or request payload shape.
3. Check query parameters, content-type, and duplicate values before moving deeper.

That is also the moment to pair an HTTP Status Code Explorer with a JSON Validator instead of treating every client error as an auth problem.

Teams often say the API rejected the token even when the token is perfectly valid. A 401 Unauthorized response usually means the authentication material never became acceptable to the server in the first place. A 403 Forbidden response usually means the token was accepted, but it does not grant enough permission for the requested action.

That distinction changes the next debugging move completely. With 401, inspect token presence, expiry, issuer, audience, signature, and whether a proxy dropped the header. With 403, stop rotating secrets and start checking scopes, roles, tenancy, or ownership rules. If you skip that separation, you will keep solving the wrong class of problem.

A 422 Unprocessable Entity response is where many teams lose the thread. The request usually arrived in a syntactically valid form, so the server got far enough to understand the payload. The failure happened later, when field validation, domain rules, or workflow constraints rejected the content.

That means 422 should send you toward field-level evidence, not parser-level evidence. Compare the exact payload against server validation messages, required field expectations, ranges, enum rules, and cross-field dependencies. The request is not broken in the same sense as 400; it is understandable but unacceptable.

Use this short triage lens:

• 400: the server cannot trust the request structure.
• 401: the caller identity is missing or invalid.
• 403: the caller identity is accepted but not allowed.
• 422: the request is readable but semantically wrong for this operation.