Limited API Doesn't Mean Workflow Stops: How to Handle Rate Limits in n8n

n8n workflows often appear to work fine when tested with five or ten data points. A problem arises when the number increases to hundreds: the API starts responding with a 429 Too Many Requests status, some data stops being processed, or the workflow fails midway.

This is called rate limit, which is the limit on the number of requests that can be sent to a service within a certain period. Almost all APIs implement such rules to maintain system stability. Therefore, when a workflow hits that limit, the solution is not just to press the "run" button again.

In n8n, handling rate limits should be considered part of the workflow design, not a patch after an error occurs.

Why do n8n workflows easily hit API limits?

By default, a node can process many items from the input. For example, if the previous node generates 500 contact rows, the HTTP Request node sends one request for each item. From n8n's perspective, this flow makes sense. From the API's perspective, 500 requests in a short time can look like a traffic spike.

Each service has different rules. Some APIs limit the number of requests per second, per minute, or based on account type. Others impose different limits for read and write operations. Therefore, safe numbers should not be guessed based solely on experience with other services.

Fact: n8n provides official patterns for handling API limits, including using the Loop Over Items node, Wait node, and retry options on relevant nodes. Analysis: workflows that intentionally run slightly slower are often more reliable than fast workflows that need to be retried multiple times.

Basic pattern: break data, process in stages, then pause

For simple cases, structure the workflow with the following pattern:

1. Fetch or receive data from the initial source.
2. Use Loop Over Items to process data in small groups.
3. Send requests via HTTP Request or the appropriate integration node.
4. Add a Wait before processing the next group.
5. Store successful results and log failed items.

For example, a workflow retrieves 1,000 products from a spreadsheet to send to an inventory system. Instead of sending them all at once, you can process 20 items per group, then pause for a few seconds. This number is not a universal rule; use the API documentation as a basis and adjust after observing test results.

The Loop Over Items node is useful because it makes the processing flow more controlled. This node was previously known as Split in Batches. Meanwhile, the Wait node can delay the continuation of execution based on a specific duration or other conditions available in the workflow.

Don't just add pauses

Pauses are not a cure-all for every situation. If an API limits 60 requests per minute, a two-second pause indeed allows for about 30 requests per minute. However, if the workflow runs in parallel or there are other executions using the same credentials and endpoint, the limit can still be exceeded.

Also, pay attention to batch size. Batches that are too large can diminish the benefits of pauses. While smaller batches are safer, they can make the workflow take much longer. The goal is not to find the fastest process, but rather a point that is fast enough and remains stable.

For APIs that support it, use official batch operations. A single request containing 20 items is usually more efficient than 20 separate requests. However, ensure that the batch format, payload size limits, and behavior when one item in the batch fails are well understood.

Use retries cautiously

Retry means attempting to resend failed requests. This feature is useful for temporary disruptions, including rate limit responses or network issues. However, retrying without a pause can worsen the situation: failed requests are immediately resent, then fail again, and so on.

If the API sends headers like Retry-After, use its value as a guide for when requests can be retried. If that information is not available, use backoff, which is an increasing delay for each attempt. For example:

Attempt 1: wait 2 seconds
Attempt 2: wait 5 seconds
Attempt 3: wait 15 seconds

In n8n, retry settings can be combined with the Wait node or error branches. Do not apply retries to all types of errors. Authentication errors, incorrect URLs, or invalid data typically will not resolve just by retrying.

Separate temporary errors from permanent errors

A healthy workflow does not treat all failures the same way. Errors like timeouts, broken connections, or status 429 may be worth retrying. Conversely, a status 400 due to incorrect data format needs to be corrected or sent to a review list.

You can create branches based on response status codes:

• 2xx: mark as successful and save important IDs or responses.
• 429: wait, then retry with a limit on attempts.
• 5xx: consider as a temporary disruption, but still limit retries.
• 4xx others: check authentication, parameters, and payload format.

If using HTTP Request, enable the option that allows the workflow to continue processing other items when one request fails, then direct the error results to a logging path. The option names may vary depending on the n8n version and node configuration, so check the settings of the node being used.

What does this mean for us?

Rate limits are not just a technical issue. In business workflows, partial data failures can lead to unsynchronized stock, delayed customer notifications, or incomplete daily reports. Therefore, the success of a workflow should not be measured solely by the "Success" status in n8n.

Add a summary of results: how many items were received, how many succeeded, how many were delayed, and how many failed permanently. This way, you do not need to open each execution just to find out if all data has been processed.

What you can do now

1. Check the API documentation and look for request limits, batch sizes, and Retry-After headers.
2. Test the workflow with small data before running it for the entire dataset.
3. Add Loop Over Items with conservative batch sizes.
4. Use Wait between requests or data groups.
5. Limit the number of retries and use increasing delays.
6. Keep a list of failed items for reprocessing without repeating everything.
7. Monitor execution duration and error counts over several days, then adjust parameters.

A good n8n workflow is not always the fastest. For API integrations, workflows that can manage the pace, respect service limits, and clarify what has failed are usually much more useful in the long run.

Sources & further reading

• n8n Docs — Handle rate limits
• n8n Docs — Loop Over Items (Split in Batches)
• n8n Docs — Wait node
• n8n Docs — HTTP Request common issues

– Rio Yotto @rioyotto