When a request fails and you do not know why
Most “the API is broken” reports are a request that never said who it was. The response usually says so, in the part nobody reads.
API Post/Get covers every HTTP method, organises requests into collections and folders, manages headers and authorisation, and shows the response body with syntax highlighting. Keyboard shortcuts make the repeat cycle fast once you know them.
Read the whole response, not the status
The habit that saves the most time is opening the response body on failure instead of reacting to the red status. APIs written by people put the reason in there, and it is usually one sentence that ends the investigation.
Then check the headers on both sides. A request sent without Content-Type: application/json is the single most common cause of a 400 that looks unexplainable — the server received your JSON as plain text and could not parse it.
The four that mean something specific
- 401 — you did not authenticate. The token is missing, malformed, or in the wrong header.
- 403 — you authenticated and are not allowed. Different problem, different fix; stop re-sending the token.
- 404 — on an endpoint you know exists, this usually means a path variable resolved to empty. Check whether
{{user_id}}actually has a value in the selected environment. - 422 — the request was understood and the data was rejected. The body almost always names the field.
A 500 is the only one that is genuinely the other side's problem, and even then it is worth sending the same request without the optional fields before you report it.
Auth, where most of the time goes
Set authorisation at the folder level rather than per request. Repeating a bearer token across nineteen requests means updating nineteen requests when it rotates, and the one you miss is the one you will debug for twenty minutes.
And keep the token in an environment variable rather than typed into the header. That way switching environment switches identity too, which is what you wanted when you switched.
Questions people actually ask
I get a 400 and the request looks correct. What now?
Check that you are sending Content-Type: application/json. A JSON body received as plain text produces exactly this: a request that looks right and a server that cannot parse it.
What is the difference between 401 and 403?
401 means you did not authenticate — missing or malformed token. 403 means you did and are not permitted. Re-sending the token fixes the first and does nothing for the second.
Where should the auth token live?
In an environment variable, applied at folder level. Typing it into each request means updating every one of them when it rotates, and the one you miss becomes twenty minutes of debugging.
