Field notes · 19 October 2026 · 7 min read

The 429 is not where you think it is

Almost every "my enrichment flow dies halfway" ticket has the same suspect: a rate limit on the AI provider. We checked the provider's own documentation and then did the arithmetic on our own batch settings — and the numbers say the AI node is the least likely place for a 429 to come from. Here is what each limit really is, what the batch interval buys you, and which error codes are worth retrying at all.

What DeepSeek actually limits: connections, not requests per minute

Read the live docs rather than a blog post from last year. As of October 2026, DeepSeek publishes a concurrency limit per account, not a requests-per-minute quota:

Two details matter more than the big numbers. First, a request occupies one slot from the moment it is sent until the response is complete — so a slow completion holds its slot, and "requests per second" is not the unit being counted. Second, the limit is computed at account level, regardless of which API key you use: your five workflows share one ceiling, and so does any other app on that account. Exceed it and you get 429, exactly as if you had sent too many requests per minute.

The kit's arithmetic: 4 in flight against a ceiling of 2,500

Node 05 in the workflow uses n8n's batching options with two values that matter: a batch size of 4 and a batch interval of 1,200 ms. Batching means one HTTP request carries four leads, and n8n waits 1.2 s before opening the next one. Consequences, in plain numbers:

So the interval is not there to keep a rate limiter happy in the ordinary case — at 0.16 % of the ceiling it could not. It is there for three cheaper reasons: it keeps a run's duration predictable, it stops a runaway loop from becoming a runaway bill, and it gives you headroom for the day you run ten flows at once on the same account. That last one is the case where the account-level limit really bites.

Which errors deserve a retry, and which are a waste of time

This is the part that turns a bad afternoon into a five-minute fix. DeepSeek's error table lists six codes you will actually meet, and only some of them get better by retrying:

A rejected request comes back without a usage block, so it is not billed: a 429 costs you time, not tokens. What it does cost, if you handle it badly, is duplicated work — which is why the retry belongs in the HTTP node's own options and not in a loop you wrote yourself.

The three settings that fix it in n8n, in order

1. Retry on fail, with a wait. On node 05, enable Retry On Fail, set Max Tries to 3 and Wait Between Tries to 2000 ms. Three attempts with two seconds between them survives a transient 503 without touching the rest of the flow.
2. Raise the batch interval before you shrink the batch. If you see sustained 429s, take the interval from 1200 to 3000. Same work, same tokens, four times slower — and still under one request every three seconds.
3. Then, and only then, reduce the batch size. Dropping from 4 to 2 does not reduce concurrency (there was only ever one request in flight); it doubles the number of requests. It helps only when a single request is too large for the model, which is a different problem — the one where the response comes back empty, covered in our empty-response article.

Where the 429 really comes from in this pipeline

In our runs, the AI node is not the usual suspect. Ranked by how often it explains the failure:

Diagnose it in sixty seconds

Open the failed execution and read three things in order: which node is red (that alone separates a Google problem from an AI problem), the HTTP status, and whether it failed on the first batch or after N. Failing on the first batch is almost never a rate limit — it is credentials, parameters or balance. Failing after N batches, only on busy days, is a rate limit, and the interval is the right dial. Failing on one specific lead, every time, is a prompt or payload problem that no amount of waiting fixes.

What we did not test

Honesty about the evidence: we have not induced a 429 on purpose, and we have not run this pipeline against a live Google key in production. The concurrency figures above come from DeepSeek's documentation read on 19 October 2026; the timing figures come from our own runs (15 batched requests for 60 leads, about 20 seconds end to end). If DeepSeek changes its limits tomorrow, the arithmetic changes with it — which is why the document that ships inside the kit lists the source and the date next to every number.