400 Bad Request

400 Bad Request means the server refused to process the request because the request itself is defective — malformed syntax, invalid framing, or contents that fail basic validation. It's the generic client-error code: when nothing more specific (401, 404, 413, 422…) fits, servers reach for 400.

Common causes

• Malformed JSON body — trailing commas, single quotes, unescaped characters. Validate payloads with a JSON formatter before blaming the API.
• Wrong Content-Type — sending JSON with application/x-www-form-urlencoded (or vice versa); many frameworks then parse an empty body and reject the request.
• Oversized or corrupt headers — a cookie that grew past the server's header-size limit is a classic: the site 400s for one user and works for everyone else. Clearing cookies "fixes" it.
• Invalid URL encoding — unencoded spaces, % sequences, or characters in the path/query that the server refuses.
• Missing required parameters — APIs that validate early often 400 before more specific errors get a chance.
• Protocol violations — bad chunked encoding, conflicting Content-Length, HTTP/2 framing errors introduced by a buggy proxy.

Who's at fault?

By definition the client — but "the client" includes every layer that touched the request: your SDK, a proxy rewriting headers, a load balancer with a lower header limit than the app. A request that works with curl but 400s from your application means the difference is in what your application adds.

Debugging

1. Reproduce the exact request with the free API tester — same method, headers and body — and vary one thing at a time.
2. Read the response body; well-behaved APIs say what was bad.
3. Compare limits along the path: application server, reverse proxy and CDN each have their own max header/body sizes, and the smallest one wins.

For APIs you own, an API monitor sends a known-good request on schedule — if that starts returning 400, a deploy changed validation, not the clients.