n8n Loop Over Items: Batching and Automatic Looping

n8n usually processes multiple records entirely on its own: a node takes in a list of items, runs its logic for each individual item, and returns the results again as a list. For most workflows, you therefore do not need an explicit loop at all. But as soon as an external service only allows a few requests per second, a node only processes the first item, or a paginated API without a known number of pages needs to be queried, automatic processing is no longer enough. This is exactly what the Loop Over Items node in n8n is for, formerly known as Split in Batches.

In this article, we show you how automatic looping works in n8n, how the Loop Over Items node works in detail, and what you should watch out for regarding batch size and performance so that your workflows run stably and without rate limit errors.

How n8n Loops Through Items Automatically

According to the n8n documentation on looping n8n nodes generally accept any number of items, process them, and return the results again. For example, if you connect a data store node with five customer records to a Slack node, n8n automatically sends five individual messages, one per record. You do not need to build your own loop for this, the engine handles it in the background.

If you instead want to process only the first item of an incoming record, you activate the Execute Once option in the node settings under the Settings tab. This makes the node ignore all further items and only process the first record, which is useful, for example, for one-off notifications.

The Loop Over Items Node in Detail

For all cases where automatic processing is not enough, n8n provides the Loop Over Items node . The node stores the original input data and returns a fixed number of items on each run through the loop output. Once all batches have been processed, it combines the processed data and returns it through the done output.

Two settings are central here:

• Batch Size: determines how many items the node returns per run. If you set the value to 1, n8n processes each item individually, one after another.
• Reset: reinitializes the node with fresh input data on each run. This is helpful for paginated API queries where you do not know the total number of pages in advance. Important according to the documentation: if Reset is enabled, you must include a valid stop condition, otherwise the loop will run indefinitely.

In practice, you use expressions such as `{{$("Loop Over Items").context["noItemsLeft"]}}` to check whether items remain, or `{{$("Loop Over Items").context["currentRunIndex"]}}` to read out the current run index and use it as a stop condition in an IF node.

When You Need to Loop Manually

According to the documentation, some nodes fundamentally only process the first item or all items at once, instead of iterating cleanly. These include, among others, CrateDB, Microsoft SQL, MongoDB, and TimescaleDB for insert and update operations, the Code node, and the Execute Workflow node in "Run Once for All Items" mode, the HTTP Request node for manual pagination, the Redis Info operation, and the RSS Read node. For these exceptions, you build the loop manually: you connect the output of a node back to a previous node and add an IF node that checks a clear stop condition.

Batch Size and Performance in Practice

Batch size directly determines how stable and how fast a workflow runs. A small batch size, for example 1 to 5 items per run, is easy on external APIs with strict rate limits but increases the overall runtime, because n8n has to process more individual runs. A large batch size speeds up the workflow but increases the risk that a service responds with a 429 error or that the workflow is harder to trace if an error occurs in the middle of a large batch. In practice, it is best to test with a moderate batch size and observe the execution times as well as any error responses from the target service before increasing the value further.

Especially for production workflows with many external calls, it is worth combining Loop Over Items specifically with wait times between batches so that APIs are not overloaded and you retain control over execution. If you want to not only build your n8n workflows but also operate them reliably over the long term, we support you at NordFlux as part of our n8n automation with exactly these performance and rate limit questions, so that your digital workers run reliably.

Frequently Asked Questions

What Is the Difference Between Automatic Looping and the Loop Over Items Node?

Automatic looping happens on its own for almost every n8n node: the node processes each incoming item individually and passes on the result list without you having to configure anything for it. The Loop Over Items node only comes into play when you want to explicitly split processing into controlled chunks, for example to comply with rate limits or to serve nodes that can only process one item at a time.

How Do I Prevent an Infinite Loop with the Loop Over Items Node?

An infinite loop usually occurs when the Reset option is enabled but no stop condition is checked. In this case, build in an IF node that evaluates, for example, the expression `{{$("Loop Over Items").context["noItemsLeft"]}}`, and route the workflow into the done branch instead of back into the loop once the end is reached.

Which Batch Size Should I Choose for API Requests?

There is no blanket number, because every service has its own rate limits. As a starting point, small values between 1 and 10 items per batch are suitable, which you then gradually adjust based on the actual response times and any error messages from the target service.

Do I Have to Build a Loop Myself for Every Node?

No, most n8n nodes process multiple items automatically without additional configuration. Only for a limited number of exception nodes, for example certain database nodes or the HTTP Request node for manual pagination, do you need to build the loop yourself with the Loop Over Items node or a back-connected IF node.

Can I Access Data from Previous Runs Within a Loop?

Yes, using the context properties of the Loop Over Items node, such as currentRunIndex, you can identify the current run, and references to earlier nodes in the workflow also allow you to incorporate data from previous steps. For more complex intermediate storage across multiple runs, an additional Set or Code node that collects intermediate results is recommended.