Print the response body. A well-built API puts a tailored explanation of what went wrong there - which parameter, what it expected, sometimes the exact fix - and the status code alone carries none of it. If you are debugging by hand, print the whole body and read it before changing anything.
The reason you have never seen it is your HTTP library, not the API. Each of the common clients hides the body in a different way:
requests,httpxandaiohttpall return normally on a 400, so nothing stops your code and nothing tells you to look.urllibdoes raise, butstr(e)is only "HTTP Error 400: Bad Request" - the body is sitting one.read().raise_for_status()turns the status into an exception that carries the summary line only, so a log built on the exception text loses the explanation. Log the body itself.- For curl, reach for
--fail-with-body- plain-fdiscards the body on failure.
In code, pull the error block out on purpose: in Python that is r.json()["error"], in JavaScript await res.json() and then j.error. Take the whole block rather than one field - different APIs put the tailored line in different places (error.hint on one service, error.message on another), and the block works everywhere.
The cheapest debugging move of all: hand the whole error body to your AI agent along with the API's OpenAPI or docs link. The body was written to be acted on, and an agent that sees only "400" will guess, while one that sees the body usually fixes the call in one step.
Related pages for what the body will tell you once you can see it: reading a 429 refusal, "undefined" in the URL and what a 422 means, and a 404/400 on a URL that looks correct. Full write-up: https://www.tigzig.com/post/tigzig-api-error-hints-read-the-body-sep2026.
Building something like this? How I work covers the rates, the availability and what I take on.