API Error 400 | Fix Bad Request Fast

A 400 response can feel rude because it stops you with little detail. Treat it like a clue. The server is saying, “I can’t parse what you sent.” That points to a short list of request parts: the path and query string, headers, authentication fields, and the request body.

This walkthrough gives you a flow you can run in minutes, then turn into a habit. You’ll learn what to check first, what to log, and how to avoid repeat failures after code changes.

What A 400 Bad Request Means In Practice

HTTP status 400 is “Bad Request.” It’s a 4xx status, which usually means the client sent something the server won’t accept. A 400 is common when parsing fails before business logic runs. The server, gateway, or API layer may reject the request while parsing the request line, headers, or body.

If you’re calling an API through a CDN, load balancer, API gateway, reverse proxy, or WAF, the 400 can come from any hop. The fix still starts on your side, but the hop that throws the error changes what evidence you can collect.

• Confirm The Responder — Check response headers for server or gateway identifiers, then match them to your traffic path.
• Capture A Replay — Save the exact request as cURL so you can replay it without your app.
• Diff Against Success — Put a working request beside the failing one and compare URL, headers, and body bytes.

API Error 400 Fix Checklist For Bad Request

When you see api error 400, start with the parts that break parsing most often. These checks catch most cases without server access.

Run the checklist in order. Start with the URL because it’s quick to inspect. Then confirm headers, then confirm body bytes. Many “mystery” 400s turn into one invisible character, one wrong header, or one encoding mismatch.

Check The Request Line And URL First

The request line is the method plus the URL path and query string. A stray space can break it. An unescaped character can change how the server splits parameters. Print the final URL your client sends, not the URL you meant to build.

Trim Whitespace And Control Characters

Whitespace sneaks in through string joins, user input, copied values, and templates. Some clients normalize it, others send it as-is.

• Trim URL Parts — Remove leading and trailing spaces around scheme, host, path, and query values.
• Block Newlines — Reject \r and \n in any URL part when values come from external input.

Encode The Query String Correctly

URLs have reserved characters that must be percent-encoded inside parameter values. If you send raw “&” or “=” inside a value, the server may split it into extra parameters. If you send raw “#”, the part after it may never reach the server.

• Use A Real Encoder — Build query strings with a library function, not manual concatenation.
• Keep Names Exact — Match parameter names and casing to what the API expects.

Watch For Double Encoding

Double encoding happens when a value is encoded once, then encoded again while building the final URL. The server receives different bytes and may reject the request.

• Encode Once At Serialization — Keep values raw in your app, then encode only when you serialize the request.
• Compare With cURL — Match your final URL to a known-good request and fix any differences.

Validate Headers, Auth, And Content Type

Headers are easy to get “almost right.” A server can treat an invalid header as a parsing failure and return 400. Start with content headers, then authentication headers, then custom headers.

Match Content-Type To The Body

If you send JSON, the Content-Type should say JSON. If you send form data, the Content-Type must match the form encoding. Mismatches can trigger an early reject.

• Set JSON Correctly — Use application/json when the body is JSON text.
• Set Forms Correctly — Use application/x-www-form-urlencoded or multipart/form-data as needed.

Make Authorization Headers Exact

Auth failures often return 401 or 403, yet some gateways respond with 400 when the Authorization header format is invalid. Small differences matter: the scheme name, spacing, and extra characters.

• Match The Scheme — Use “Bearer” or the scheme the provider documents, with a single space before the token.
• Strip Hidden Bytes — Remove newline and tab characters from tokens copied from dashboards.

Remove Invalid Header Values

Some clients allow newline characters in header values. Many servers reject them to prevent request smuggling. That rejection can show up as 400 with no other hints.

• Block CRLF In Values — Refuse any header value that contains \r or \n.
• Reduce Headers While Testing — Remove extras during debugging, then add them back one by one.

Validate Body Format And Encoding

If the server gets past URL and header parsing, the next 400 hotspot is the body. Validate the body outside your code, then replay the same bytes until the server accepts them.

JSON Mistakes That Trigger 400

Strict parsers reject small mistakes. Some APIs also reject unknown fields or missing required fields.

• Validate The JSON Text — Run the exact string through a JSON validator and fix syntax errors.
• Send Correct Types — Keep numbers, booleans, and null values aligned to what the API accepts.

Encoding And Compression Mismatches

Encoding bugs hide in logs because the printed text can look fine while the bytes differ. Compression can also confuse servers if headers don’t match what you actually sent.

• Encode UTF-8 Consistently — Encode request bodies as UTF-8 and avoid mixed encodings in one payload.
• Align Content-Encoding — If you gzip the body, set Content-Encoding to gzip and confirm the API accepts it.

Multipart And Form Data Pitfalls

Multipart failures are common when clients set boundaries incorrectly. Form encoding failures show up when values include reserved characters and you skip encoding.

• Let The Client Build Boundaries — Use the HTTP library’s multipart helper instead of building raw parts.
• Percent-Encode Values — Encode values that include “&”, “=”, or spaces when using urlencoded forms.

Debug Faster With Logs, Replays, And Tools

When a 400 won’t budge, improve visibility into what you send over the wire. Capture the exact request bytes and the response headers, then narrow the difference between success and failure.

Log The Outgoing Request Safely

Logging a full request can leak secrets, so mask tokens and sensitive fields. You still can log enough to spot formatting and encoding issues.

• Log URL And Method — Include the final URL after encoding, plus the HTTP method.
• Log Body Length — Record the byte length and a sha-256 hash so you can confirm identical payloads.

Replay With cURL Or A Raw Client

Replays strip away app logic and let you tweak one thing at a time. If a replay works, your bug sits in your request builder, not in the API.

• Export A Minimal Repro — Copy the request as cURL from your client tool, then run it in a terminal.
• Change One Thing — Swap one header or one body field per run, then note the response.

Check Proxies And Redirects

If your client goes through a proxy or a redirect, the request you see in logs may not match the request that reaches the API. Confirm the host, path, and headers on the last hop.

• Disable Auto Redirects — Follow redirects by hand so you can see where the request changes.
• Bypass The Proxy — Send the same request direct to the API to confirm the proxy is not rewriting it.

Use Error Details When They Exist

Some APIs return a JSON error payload with a code and message. Others include a request id header. Save that id, then search gateway logs if you own the API, or share it with the provider if you don’t.

• Capture The Request Id — Store any trace id header value with your client logs.
• Map Errors To Fields — If the API returns a field path, validate that field before sending.

Prevent 400s With Safer Client Patterns

After you fix the immediate failure, lock in a few habits so it stays fixed. A 400 often comes back when someone changes serialization, upgrades a library, or adds a new field without validation.

Centralize Request Building

Build requests in one place so encoding rules stay consistent. Keep URL building, header defaults, and body serialization together, then reuse them across endpoints.

• Create A Request Model — Validate required fields and types before serialization.
• Freeze Header Defaults — Keep a small, stable set of headers and avoid ad-hoc changes.

Add Client-Side Validation

Validation saves round trips. Validate body shape, required fields, and string limits before sending. When validation fails, return a clear error and log the cause.

• Validate With A Schema — Use JSON Schema when the API publishes one.
• Normalize Dates — Send ISO 8601 strings when the API expects them, not localized formats.

Guard Against Library Default Changes

A minor upgrade can change encoding, header formatting, or body serialization. A small test suite catches that early and keeps your client stable.

• Snapshot A Known Request — Save a golden request and compare new builds against it.
• Run Contract Tests — Hit a staging endpoint and fail builds when a request starts returning 400.

If you’re still stuck, replay the smallest failing request you can produce. Each time you shrink the request, the cause gets louder. Many teams find the culprit in one extra character in a header, one unescaped query value, or one field the API rejects.

Once you get a clean response, write down the root cause next to the fix in your code notes. The next time you see api error 400, you’ll move from error to fix quickly.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback