Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Last reviewed: February 20, 2026|Editorial standard: source-backed comparison guidance
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
{
"type": "https://api.example.com/problems/malformed-json",
"title": "Bad Request",
"status": 400,
"detail": "Malformed JSON at line 3, column 15."
}HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
{
"type": "https://api.example.com/problems/validation-error",
"title": "Unprocessable Content",
"status": 422,
"detail": "Validation failed for one or more fields.",
"errors": [
{ "field": "status", "message": "Cannot transition from shipped to pending." }
]
}Return 400 because the request cannot be interpreted reliably before semantic validation starts.
Yes. 422 is intended for semantically invalid instructions after syntax and media type are accepted.
Use 415 when the media type itself is unsupported. Use 400 for malformed requests, and 422 for semantic failures after successful parsing.
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Fix upstream errors faster: use 502 when a gateway gets an invalid upstream response, and 504 when the upstream service exceeds your timeout budget.