Handling API Rate Limits: Wait, Batching, Retry, Pagination

Anyone building their own workflows against third-party APIs will sooner or later run into the 429 response: "Too Many Requests". Especially in bulk processing, for example when enriching hundreds of CRM contacts or synchronizing large product catalogs, this is not an edge case but the rule. n8n comes with several built-in tools for this that can be combined: the Wait node, the Retry On Fail setting in the HTTP Request node, Batching, and pagination control. As of: July 2026.

The trick is not to find a single feature that "solves" rate limits, but to choose the right combination for the respective use case. A single API call with an occasional failure needs something different than a loop over ten thousand records. Below we go through both scenarios, based on the official n8n documentation.

How to recognize a rate limit problem

According to the n8n documentation on rate limits a service typically reports too many requests with the HTTP status code 429 and an error message stating that the service is receiving "too many requests from you". This message appears in the node output when a request fails, and is the first sign that it is not the credentials or the URL that are wrong, but simply that too many requests are going out in too short a time. Important for troubleshooting: a 429 can also occur in the middle of a workflow that previously ran error-free hundreds of times, for example because a third-party provider temporarily tightens its limit during a campaign or a traffic peak. Anyone who works with the same API more often should know its rate limit documentation before the workflow goes into production.

Retry On Fail: automatically repeating individual requests

For workflows with occasional, non-systematic 429 errors, the built-in retry logic in the HTTP Request node is often enough. In the node Settings you enable Retry On Fail and set two values:

• Max Tries determines how many times n8n retries the request at most after a failure.
• Wait Between Tries (ms) determines the pause between attempts in milliseconds.

According to the documentation on common issues with the HTTP Request node if you use this setting specifically against rate limits, you should set Wait Between Tries (ms) to a value above the service's limit. For example, if an API allows one request per second, set 1000 milliseconds so the second attempt does not run into the same limit again. The advantage of this method: it is done with a few clicks in the same node, without extra nodes on the canvas. The disadvantage: with a large number of items in a loop, the wait time multiplies quickly, and without additional control, n8n still fires off as many requests as possible before the first error even comes back.

Batching in the HTTP Request node: deliberately throttling requests

If you know in advance that an API has strict limits, it makes more sense to control the request rate preventively instead of only reacting to errors. For this, the HTTP Request node offers two settings under Add Option > Batching:

• Items per Batch: how many input items are processed per request round.
• Batch Interval (ms): the pause between batches in milliseconds.

According to the documentation, this batching option is functionally equivalent to the combination of Loop Over Items and Wait node, just built into a single node. For example, if you want to send one request per second to a service, set Batch Interval (ms) to 1000. For APIs with limits per minute instead of per second, you calculate accordingly, for example 60 requests per minute results in an interval of 1000 milliseconds between individual requests, or a larger interval for multiple items per batch. For bulk processing this is the more robust default setting, because it tackles the problem at the root instead of only reacting after a failure.

Loop Over Items and the Wait node: full control over the rhythm

For cases where you still need your own logic between batches, for example logging, a conditional branch, or dynamically adjusting the wait time depending on the response, you combine Loop Over Items with your own Wait node. The setup: place Loop Over Items before the API call, then insert the Wait node and connect its output back to Loop Over Items. This creates a loop that deliberately pauses after each batch or each individual item before the next round starts.

The Wait node itself is, according to the n8n documentation on the Wait node designed to pause a running execution and resume it later at the same point with the same data. For the topic of rate limits, the mode After Time Interval is particularly relevant: you specify a time span in seconds, minutes, hours, or days, and the workflow pauses for exactly that long. Important to know: for wait times under 65 seconds, n8n does not offload the execution data to the database, so the pause runs lightweight in memory. For longer wait times, n8n handles the caching automatically, which makes the workflow reliably resumable even across restarts of the instance. Besides After Time Interval the node also supports At Specified Time, On Webhook Call and On Form Submitted, which are intended for other scenarios such as external approvals or scheduled executions, but are rarely needed for pure rate limiting.

Handling pagination properly instead of loading everything at once

A common cause of rate limit errors is not actually the frequency of requests but their quantity: anyone who tries to paginate through ten thousand records in a single unthrottled run produces a great many requests in quick succession. According to the n8n documentation on pagination the HTTP Request node supports different modes for this:

• Response Contains Next URL: the API returns the URL of the next page directly in its response, which you read out via an expression, for example `{{ $response.body["next-page"] }}`.
• Update a Parameter in Each Request: you increment a query or body parameter yourself between requests, for example with `{{ $pageCount + 1 }}` for a count starting at zero, which must be matched to an API pagination starting at one.

The documentation explicitly points out that every API implements pagination differently. You should therefore check beforehand whether the service works with next URLs, page numbers, or offset parameters, and how many results per page are allowed at most. You usually set the page size via your own query parameter such as `limit` in the node settings. If you combine pagination with batching or a Wait node between page fetches, you prevent an extensive data export from hitting the limit purely through its speed, before the actual processing even begins.

Practical patterns: which combination for which case

In practice it is worth making a rough classification of which tool applies when:

• Occasional 429 errors at low volume: Retry On Fail with a suitable Wait Between Tries is usually enough.
• A known, fixed rate limit at high volume: Batching in the HTTP Request node with an interval matching the service's limit.
• More complex logic between calls, for example dynamic pauses depending on the response header or additional branches: Loop Over Items combined with your own Wait node.
• Large amounts of data across multiple pages: choose a pagination mode matching the API and additionally ease the load with batching or Wait.

In practice, a single tool is rarely enough for a complete workflow. A typical pattern is pagination for fetching data, a moderate batch interval during processing, and additionally Retry On Fail as a safety net for the moments when even the throttled rate still leads to an occasional 429. This way you keep control over the pace and reliability of your workflow, instead of relying on luck that the third-party provider never comes under load.

Frequently asked questions

What is the difference between Retry On Fail and Batching?

Retry On Fail only reacts after a request has already failed, and repeats it after a set wait time. Batching starts earlier and throttles from the outset how many requests go out and at what interval. For known, fixed limits, Batching is the cleaner solution; for occasional, unpredictable failures, Retry On Fail supplements it as a safeguard.

From which wait time does the Wait node store the execution in the database?

According to the n8n documentation, the Wait node only offloads execution data to the database for wait times of 65 seconds or more. Shorter pauses run lightweight without this extra step, which is enough for most rate limit scenarios with pauses of fractions of a second up to a few seconds.

Can I use Batch Interval and a Wait node at the same time in the same workflow?

Yes, that is even a common pattern. Batching in the HTTP Request node covers the ongoing throttling during the actual processing, while an additional Wait node can insert a targeted, longer pause elsewhere in the workflow, for example between individual page fetches during pagination or before a particularly limited follow-up step.

What do I do if I do not know the exact rate limit of an API?

Start conservatively with a larger interval, for example 1000 to 2000 milliseconds between requests, and observe whether 429 errors still occur. Many APIs also state the limit in response headers, which you can evaluate in the HTTP Request node and use for a dynamic adjustment of the wait time. In addition, an enabled Retry On Fail helps as a safety net in case the initial estimate was too tight.

Is Retry On Fail alone enough to avoid rate limits with large amounts of data?

Not reliably. Retry On Fail repeats individual failed requests, but does not prevent n8n from sending many requests in quick succession in a large loop without batching. At high volume, the combination of batching or Loop Over Items with a Wait node is the more robust choice; Retry On Fail remains useful as an additional safeguard.