Bad Request
The server cannot process the request due to something that is perceived to be a client error.
Root Cause
Common causes include malformed request syntax, invalid request message framing, or deceptive request routing.
How to Fix
Check your request payload for syntax errors, ensure headers are correctly set, and verify that the endpoint URL is correct.
Quick Summary
400 Bad Request means the server cannot parse the request itself, malformed JSON, wrong Content-Type, or missing required headers. Use 422 instead for semantic validation errors.
Key Takeaways
- 400 = syntactically malformed request (broken JSON, missing required header, wrong Content-Type)
- Use 422 Unprocessable Entity for valid-format but semantically wrong payloads
- Always return a structured error body (RFC 7807 problem+json) so clients can act on the failure
- Log the raw request body server-side so you can reproduce the failure offline
When to use it
- Malformed JSON in the request body
- Missing required header (Content-Type, Idempotency-Key)
- Query string value the server cannot decode
Common Mistakes
- Returning 400 for validation errors that should be 422
- Returning 400 with no body, clients have no signal on how to fix the request
- Logging only the status code without the parsed error, debugging is impossible without the cause
400 Bad Request, Frequently Asked
What's the difference between 400 and 422?
400 = the request is malformed (server can't parse it). 422 = the request parses fine but fails validation rules (missing field, value out of range, business-rule violation).
Should I always include an error body on 400?
Yes. Return application/problem+json (RFC 7807) with `type`, `title`, `detail`, and ideally an `errors` array of field-level issues.
Still having issues?
Check your network logs or use our developer tools to inspect headers, decode tokens, or validate your requests.