Fix HTTP 400 Bad Request API Errors
HTTP 400 means the receiving server could not accept the request as sent. Preserve the failing request, identify which layer rejected it, and change one input at a time.
Capture the exact exchange
Record the method, final URL, request headers, content length, and a safely redacted body. Also keep the response headers, request identifier, and complete error object. Do not log passwords, cookies, authorization values, API keys, or private payload fields. A useful API error often names the rejected field or expected representation, while a generic HTML response may indicate that a gateway answered before the application.
Validate request syntax
For JSON, confirm that property names and strings use double quotes, commas are present, trailing commas are absent, and control characters are escaped. Validate the exact bytes sent rather than an object displayed in a debugger. A client may serialize the object twice, send an empty body, or submit form data while labeling it as JSON. Compare the body with the declared Content-Type and character encoding.
Compare the request with the API contract
Check required fields, accepted enum values, date formats, numeric ranges, array limits, and whether unknown properties are allowed. Verify path and query parameter names, including capitalization and repeated parameters. If an OpenAPI document is available, validate both the specification and the request shape against the operation. Remember that a syntactically valid JSON document can still violate the business contract.
Inspect URL and header encoding
Encode query component values individually. Do not encode an entire URL into one component or concatenate untrusted values without a URL builder. Look for invalid percent escapes, unintended plus-to-space conversion, duplicate content-length headers, oversized cookies, and newline characters. When translating a working cURL request into application code, compare the generated request rather than only the source code.
Find the rejecting layer
A CDN, load balancer, reverse proxy, framework, request parser, schema validator, or application can produce a 400. Correlate the response request ID with logs at each hop. Server branding and response shape are clues, not proof. If the application has no matching trace, inspect proxy request-size limits, header rules, protocol parsing, and URL normalization.
Reduce and retest
Start from the smallest documented request that succeeds, then add fields until the error returns. Alternatively remove half of a failing payload at a time. Keep the method, endpoint, credentials, and environment constant. Validate JSON locally with the JSON Validator and inspect the contract with the OpenAPI Validator.
Frequently Asked Questions
Does HTTP 400 always mean invalid JSON?
No. URLs, headers, field validation, and gateway rules can also cause it.
Should validation use 400 or 422?
Both conventions exist; follow the API contract.
Can a proxy return 400 first?
Yes. It may reject the request before the application runs.