"429 - The service is receiving too many requests from you" means you called an API faster than it allows. The first instinct, adding a random Wait node, often works on ten items and fails on a thousand. A reliable fix starts with one number: the API's actual limit.
In short. Find the API's limit (for example 100 requests per minute), compute the interval (60,000 ms / 100 = 600 ms, plus a margin), then apply it with the HTTP Request node's Batching option (Items per Batch and Batch Interval) and turn on Retry on Fail with a few seconds between tries. For paginated calls, set Interval Between Requests in the pagination settings.
Step 1: find the limit
Look in the API documentation for "rate limit". Limits are expressed per second, per minute, per day, sometimes per endpoint or per account. Many APIs also return headers such as X-RateLimit-Remaining or Retry-After; turn on the "Include Response Headers and Status" response option once to see them.
Step 2: compute the safe pace
| Limit | Interval per request | With 20% margin |
|---|---|---|
| 10 per second | 100 ms | 120 ms |
| 100 per minute | 600 ms | 720 ms |
| 1,000 per hour | 3,600 ms | 4,320 ms |
Our free API Rate Limit Planner does this calculation, including how long a full run of your item count will take.
Fix 1: Batching in the HTTP Request node
The documented option, for workflows that send one request per item:
- 1 HTTP Request node > Add Option > Batching.
- 2 Items per Batch: how many requests to send together, for example 1.
- 3 Batch Interval (ms): the pause between batches, for example 720.
With 1 item per batch and 1,000 ms, n8n sends one request per second.
Fix 2: Retry on Fail
Even with the right pace, a burst from another workflow can push you over. In the node Settings:
- 1 Retry on Fail: on.
- 2 Max Tries: 3 to 5.
- 3 Wait Between Tries (ms): at least the API's reset window, often 5,000 to 60,000.
Retries are safe for reads. For writes, make sure a retried request cannot create a duplicate.
Fix 3: paginated calls
When one HTTP Request node fetches many pages, set Interval Between Requests (ms) in its pagination settings. See HTTP Request pagination.
Fix 4: Loop Over Items with a Wait node
When the rate-limited step involves several nodes (call API A, then API B for each record), batch the whole sequence:
- 1 Loop Over Items with a batch size, for example 10.
- 2 The API nodes.
- 3 A Wait node, for example 10 seconds.
- 4 Back to the loop.
This paces the whole chain, not only one node.
Daily quotas
Per-day limits need a different design: process a fixed number of records per run and schedule several runs, or stop when the quota header reaches a threshold and resume the next day. Store progress (the last processed ID) so the next run continues where the previous one stopped.
Shared limits
Several workflows using the same API key share one limit. If a nightly sync and a live webhook both call the same CRM, schedule the sync outside business hours, or give each its own key if the API allows it.
Worked example: updating 5,000 CRM records overnight
The CRM allows 100 requests per 10 seconds per account, and you need to update 5,000 contacts.
- 1 Pace: 10 seconds / 100 = 100 ms per request; with a 20% margin, 120 ms. Batching: 1 item per batch, 120 ms interval, or 10 items per batch every 1,200 ms if the node sends one request per item.
- 2 Duration: 5,000 x 120 ms = 600 seconds, about 10 minutes.
- 3 Retry on Fail: 3 tries, 10,000 ms between tries (longer than the 10-second window).
- 4 Schedule: run at 2 a.m., when live workflows use the same key least.
- 5 Resume: store the last processed ID in a data table after each batch, so a failure at record 3,200 restarts at 3,201.
Our free API Rate Limit Planner does steps 1 and 2 for you.
Reading rate-limit headers
Many APIs tell you exactly where you stand. Turn on "Include Response Headers and Status" in the HTTP Request response options once, and look for headers like these:
| Header (names vary by API) | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | When the window resets (often a Unix timestamp) |
Retry-After | Seconds to wait before retrying, sent with 429 |
If the API sends Retry-After, your Wait Between Tries should be at least that long.
Rate limits that are not per minute
| Limit type | Design |
|---|---|
| Per second | Batching with a small interval |
| Per minute or hour | Batching, plus retries with a long wait |
| Per day | Fixed number of records per run, several runs, resume from a stored position |
| Concurrent requests | One item per batch, no parallel workflows on the same key |
| Per endpoint | Pace each endpoint separately |
Troubleshooting table
| Symptom | Likely cause | Fix |
|---|---|---|
| 429 after a few seconds | No pacing | Batching with an interval from the calculation |
| 429 despite batching | Other workflows share the key | Schedule apart, or separate keys |
| Retries also get 429 | Wait shorter than the window | Wait at least the window, or Retry-After |
| 429 during pagination | No interval between pages | Interval Between Requests (ms) |
| Daily quota exhausted | Too much work per day | Split across days, resume from stored position |
Production checklist
- The API's limit written next to the node (a sticky note helps the next person).
- Batching or an interval set from the calculation, with margin.
- Retry on Fail with a wait at least as long as the limit window.
- Large backfills run at night or in chunks.
- An error workflow that alerts if 429s continue after retries.
Frequently asked questions
How do I fix a 429 error in n8n?
Slow down requests with the HTTP Request node's Batching option (Items per Batch and Batch Interval), and enable Retry on Fail with a wait between tries.
What delay should I set between n8n requests?
Divide the API's time window by its limit and add about 20%. For 100 requests per minute, about 720 ms per request.
Does Retry on Fail fix rate limits on its own?
It helps with occasional bursts, but if every request is too fast, retries also fail. Combine it with batching.
How do I rate limit a sequence of several nodes?
Use Loop Over Items with a small batch size and a Wait node at the end of each loop.
What does the n8n error "The service is receiving too many requests from you" mean?
The API returned HTTP 429: you exceeded its rate limit. Slow down with batching and retry after a wait.
Does n8n respect Retry-After automatically?
Set Wait Between Tries to at least the API's window or Retry-After value. Read the header with "Include Response Headers and Status" to know it.
Is it better to use Loop Over Items or Batching?
Batching paces a single HTTP Request node. Loop Over Items with a Wait node paces a whole sequence of nodes.
Tags
Steve founded PURIST, a workflow automation studio working with n8n, Make and Claude AI, and is the point of contact on every project. Prices and features in our articles come from vendor documentation and public pricing pages. How we research and score tools.
