How-to guide

How to Debug an API Request

Debug an API request in order rather than by guessing. Read the status code first — it tells you whose problem it is. Then check the response headers, decode the token if authentication failed, and only then examine the request body. Working outside in stops you rewriting a payload when the real problem was an expired token.

HTTP Header Parser

Turn a raw header block into a readable table.

Open the tool

Most time lost to a failing API call goes on checking things in the wrong order — rewriting the request body when the token had expired, or hunting for a permissions bug when the URL was wrong. The status code narrows it down immediately, and each class of code points at a different part of the request.

The order below is outside in: transport, then authentication, then content. Each step is cheap, and each one eliminates a whole category of cause.

Step by step

  1. Read the status code first

    A 4xx means the request was wrong; a 5xx means the server failed handling it. That single distinction decides whether you are debugging your call or reporting a bug. 401 is unauthenticated, 403 is authenticated but not permitted, 404 may be a wrong path or a resource you cannot see, 422 usually means the body parsed but failed validation.

  2. Check the response headers

    Paste the raw block into a header parser. Look for Retry-After on a 429, WWW-Authenticate on a 401, and Content-Type — a JSON parse error is often an HTML error page arriving where you expected JSON.

  3. Confirm the URL is what you think

    Parse it. A missing trailing path segment, a query parameter that was never encoded, or a request to the wrong environment are all invisible in code and obvious once the URL is split apart. Check for a redirect too: a POST that gets redirected may arrive as a GET with no body.

  4. Decode the token if authentication failed

    For a 401, decode the JWT and check exp first — an expired token is the most common cause by a wide margin. Then check iss and aud match what the API expects. Remember JWT timestamps are seconds, not milliseconds.

  5. Validate the request body

    Only once transport and auth are ruled out. Format the JSON to confirm it is well formed, then validate it against the endpoint's schema if one is published. A 422 with a vague message usually resolves into a single wrong type or missing field.

  6. Diff a working request against the failing one

    When everything looks correct, capture a request that works and compare the two payloads field by field. The difference is usually somewhere you were not looking, and a diff finds it faster than reading both.

Example

Working outside in: three cheap checks before touching the payload.

Symptom

POST /v1/orders
→ 401 Unauthorized

Order to check

1. Status 401 → authentication, not payload
2. Headers → WWW-Authenticate says why
3. Decode token → exp in the past
4. Refresh the token; payload untouched

Frequently asked questions

What is the difference between 401 and 403?
401 means the request was not authenticated — no credentials, or credentials that were not accepted. 403 means it was authenticated and that identity is not allowed to do this. Sending better credentials fixes a 401 and will not touch a 403.
Why does my JSON parser fail on the response?
Usually because the response is not JSON. An error page, a proxy notice or a redirect body arrives as HTML, and the parser fails on the first angle bracket. Check the Content-Type header before assuming the payload is malformed.
My POST is arriving with no body. Why?
Most often a redirect. A 301 or 302 may cause a client to convert a POST into a GET and drop the body. Check whether the URL redirects — 307 and 308 are the method-preserving equivalents, which is why APIs should use those.
The token looks valid but the API rejects it. What now?
Check exp, then aud and iss. A token that is unexpired but issued for a different audience or by a different issuer is correctly rejected. Also confirm you are sending it as Authorization: Bearer <token>, without the word Bearer inside the token itself.
Is it safe to paste a real token into a decoder?
A JWT decoder that runs in your browser transmits nothing, so the token stays on your device. Treat it as a credential regardless — prefer an expired or test token, and never paste a signing key anywhere.

Tools used in this guide

All tools →
All guides →

Last reviewed .