Independent API referenceField notes updated 29 Aug 2026

HTTP 400 field note

API 400 Bad Request with a JSON body: a structured checklist

Debug malformed JSON, Content-Type mismatches, double serialization, invalid query encoding, and provider request-shape errors behind HTTP 400.

400 Bad Requestinvalid JSONContent-Type mismatchbody parsed as string

Reviewed Source: MDN — 400 Bad Request

A 400 says the server cannot or will not process the request as sent. Capture the exact bytes first. Many incidents come from a correct in-memory object serialized twice, a JSON body sent with the wrong media type, or an SDK option placed inside the API payload.

Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.

Diagnostic procedure

Work from evidence to recovery.

  1. 01

    Compare wire bytes

    Log the final method, URL, headers, and serialized body after all SDK and middleware transformations.

  2. 02

    Separate syntax from schema

    Validate JSON syntax, then compare field names, nesting, enum values, and mutually exclusive options with the endpoint contract.

  3. 03

    Reduce to one failing field

    Start from the smallest accepted request and add fields until the provider rejects the same shape.

Before
Content-Type: text/plain
"{\"name\":\"Ada\"}"
Target-safe shape
Content-Type: application/json
{"name":"Ada"}

Interactive check

Test the evidence locally.

Use the related workbench to reproduce the decision with your own response, headers, method, or retry policy. Pasted values remain in the active browser tab.

01 / Evidence
02 / TriageUnidentified provider
429HTTP status
Limitsfailure layer
6headers read

Evidence

HTTP 429: A rate, quota, concurrency, or resource lock limit blocked the request.

Retry-After is present; it should take precedence over a guessed delay.

The reported request window has no remaining capacity.

Next checks

01Parse Retry-After as either delta-seconds or an HTTP date before scheduling the next attempt.

No account · no upload · no endpoint calledOpen the full incident decoder and operating notes →

FAQ

Before you ship

Does APITC send this evidence to an API?

No. The matching and calculations in the linked workbench run in the active browser tab.

Should every 400 response be retried?

No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.

Protocol behavior checked against the MDN — 400 Bad Request. Recheck your pinned provider/API version before production deployment.