HTTP Error Codes 429, 529, and 400 — What They Mean and What to Do

Your API call failed. The question is whether to retry it, fix it, or wait.

Those three paths map almost perfectly onto three error codes you'll see regularly when building with the Claude API.

The jargon

HTTP status code — a three-digit number the server sends back to tell you what happened. 2xx means success; 4xx and 5xx mean something went wrong.
Rate limit — a cap on how many requests (or tokens) you can send in a given time window.
Exponential backoff — retrying after progressively longer pauses: wait 1 second, then 2, then 4, then 8. Avoids hammering a server that's already struggling.
Idempotent — a request you can safely send twice without causing a different outcome.

The lesson

Each error code tells you who caused the problem and what action fixes it.

The 429 vs 529 distinction matters. A 429 means you are going too fast — slow down. A 529 means the API itself is under load — waiting will usually fix it even if your rate is fine. Both warrant retries with backoff. A 400 is different in kind: retrying the same broken request will produce the same broken response every time.

How it works

429 — Too Many Requests. Anthropic enforces limits on requests per minute and tokens per minute, per tier. The response headers often include retry-after, which tells you exactly how long to wait. In practice: implement exponential backoff, cap your retries (five attempts is typical), and log the failure if you exhaust them.

529 — Overloaded. This isn't in the standard HTTP spec — Anthropic uses it specifically to signal their infrastructure is under pressure. Treat it identically to 429 from a retry standpoint: back off, then try again.

400 — Bad Request. The request itself is broken. Common causes: a max_tokens value you forgot to include (it's required), a model name you mistyped, a messages array that doesn't alternate roles correctly, or a prompt that exceeds the context window. Read the error body — it usually tells you exactly what's wrong. Fix the code, not the timing.

A minimal retry pattern in pseudocode:

for attempt in 1..5:
    response = call_api(request)
    if response.status in [429, 529]:
        wait(2 ** attempt)  # 2s, 4s, 8s, 16s, 32s
        continue
    if response.status == 400:
        log(response.body)
        raise error  # do not retry
    return response  # success

When to reach for it / when not to

Use retry logic any time you're calling the API in a loop or pipeline — n8n workflows, batch processing scripts, anything unattended. Don't bother adding backoff to a one-off interactive tool where a human is watching and can just run it again.

Try it

Open the n8n Claude node you use most. Add an error branch: if the HTTP code is 429 or 529, route to a Wait node (start with 5 seconds), then loop back. If it's 400, route to a log node that captures the full response body. You'll thank yourself the first time a batch job runs at midnight.