n8n Loop Over Items: batch paid API calls under a rate limit

n8n's Loop Over Items node (formerly Split in Batches) keeps the incoming items, returns Batch Size of them through its loop output on each pass, and, when every item is processed, returns all the processed data through its done output. Put the API call on the loop branch and a Wait node before the loop closes, and you control how many requests go out and how fast.

The n8n facts come from n8n's Loop Over Items, Looping and Handle rate limits pages. The Sume limits come from Authentication and Generation admission. All were read on 2026-09-29. Sume has no official n8n node; each call is a plain HTTP Request.

Do I need Loop Over Items at all?

Often not. n8n's docs say nodes are designed to process a list of input items by default, so an HTTP Request node after a list already sends one request per item. The node earns its place in three cases the docs name: looping until all items are processed under your control, nodes that run only once (the docs list, for example, RSS Read and a Code node in Run Once for All Items mode), and avoiding rate limits.

For pacing alone, the HTTP Request node has a Batching option (Items per Batch, Batch Interval in milliseconds). n8n calls it the equivalent of Loop Over Items plus Wait. Use the loop instead when each batch needs more than one step, such as submit and then check.

How do I wire the loop and the done branch?

The node has two outputs. The loop output carries the current batch; the done output fires once, at the end. A typical paced call looks like this:

• Loop Over Items, Batch Size set to how many requests one pass may send. Batch Size 1 processes items one at a time.
• On the loop output: HTTP Request (POST) with an Idempotency-Key built from the item, then any bookkeeping.
• A Wait node after the API call, connected back to Loop Over Items. This is the pattern n8n's rate-limit page shows.
• On the done output: the step that runs once, after every batch, with all processed items combined.
• You don't need an If node to end it: n8n says the node stops once all items have been divided into batches and passed on. That changes if you turn on Reset, which needs a termination condition you write, or the loop never ends.

Idempotency-Key: {{ $json.sku }}-video-v1
Authorization: Bearer (from an n8n credential)
POST https://api.sume.com/v1/videos

Which n8n setting paces what?

Every pacing control in n8n is a count or a clock. None of them waits for a job on the API's side to finish.

How big should each batch be for a paid API?

Size it to two limits: the request rate and how much paid work the API holds at once. For Sume they are separate. Each key gets a per-minute write budget by plan, with reads in a separate bucket. Paid generation jobs are admitted queue-first, and a submit past processing plus queue capacity fails with 429 queue_full. Video job concurrency and queueing lists both limits per plan.

For video, the job cap can bind long before the rate does. On Free, the write budget is 120 a minute, but only 6 jobs can be accepted at a time. A batch of 10 would get queue_full on the seventh submit while the first six are still queued or processing, and a timed Wait doesn't help.

How do I keep the loop inside those limits?

Make each pass wait for work to finish, not for a fixed time. n8n Google Sheets AI avatar video shows how to size a batch from Sume's in-flight budget and how to poll one job without an endless loop.

• Set Batch Size at or under that budget, for example the plan's processing concurrency.
• Inside the pass, submit the batch, then poll the jobs until they are terminal before looping back.
• Read ratelimit-remaining and back off on retry-after; a 429 names the budget in error.details.scope.
• Key every item from its own data. Sume's video docs say a replay with the same Idempotency-Key returns the original job; a new key per run turns a rerun of the loop into new paid jobs.
• Don't count on a same-key retry after queue_full. Keeping batches inside capacity is what prevents it.