n8n is an open-source workflow builder that lets a small business wire APIs, LLMs and databases together without writing a backend, and the new n8n blog guide on throttling versus rate limiting is the piece most teams were missing. The practical rule: when an API returns 429, read the Retry-After header first, then add exponential backoff with jitter so parallel executions do not retry in lockstep and trigger the same wall again.
The article separates two things people confuse. Rate limiting rejects extra requests with a 429 error, so your workflow must back off and retry. Throttling instead delays or queues the request, so the workflow sees a slower response and later steps must tolerate that latency. It also walks through fixed windows, sliding windows, token buckets and leaky buckets - the pacing strategy that works against one API will quietly fail against another.
What this means for small business automation
Any flow that touches OpenAI, Anthropic, Google, a CRM or a bank parser will hit limits as soon as the batch grows past a demo. Without proper backoff, half your invoices, leads or tender pages get dropped and nobody notices for a week. In a tender analysis pipeline I built, 100-page documents go through OCR and an LLM in parallel, and the whole thing only stays reliable because 429s are caught, Retry-After is respected, and jitter spreads retries across workers.
Why it matters: If your automation processes more than a handful of items per run, the 429 handling pattern described in the n8n guide is the difference between a workflow that scales to real volumes and one that silently loses data under load.
Source: n8n Blog