n8n Loop Over Items batch size vs Sume bulk concurrency 16

In n8n, set the Loop Over Items batch size to the number of items you want in one Sume bulk run (up to 100), and send each batch in a single HTTP request to bulk-runs. Sume runs the batch with the concurrency you choose, from 1 to 16. That replaces one request per item with one request per batch, and moves the pacing from your workflow to the server.

The n8n facts are from Loop Over Items, read 2026-10-10. The Sume facts are from Bulk runs and Generation admission.

What does the node do?

The n8n page describes a batch size setting, a loop output that carries each batch, and a done output that fires when all items are processed. It also describes a reset option. With reset on, the node starts over each time it runs, and the page warns that it can loop forever if the workflow keeps feeding it new items.

For 250 items, a batch size of 100 gives 3 bulk requests with 100, 100 and 50 items. Compare that with one request per item: 250 requests, 250 chances to hit a rate limit and 250 keys to manage. Fewer, larger requests are easier to reason about and to retry.

How do the two limits interact?

Batch size decides how many items you submit at once, and Sume's concurrency decides how many of them run at once. The bulk docs allow 1 to 16 for concurrency and 1 to 100 for items. A batch of 100 with concurrency 8 does not mean 100 jobs at once; the queue hands them out 8 at a time.

Your plan still applies. The admission page lists processing concurrency of 1, 4, 8 and 20 and queue capacity of 5, 20, 40 and 100 for Free, Pro, Startup and Scale. A 429 queue_full means both are full, so the next loop pass should wait.

Choose concurrency from the plan, not from the maximum. The 16 maximum is a request limit; your account may process 4 or 8 at a time, so a higher number only lengthens the queue.

What goes in each pass?

Inside the loop, build the bulk body from the batch, send it with a fresh Idempotency-Key, and keep the queue id from data.id. A replay of the same bulk key returns 202 with the earlier queue, so a key reused from a previous night would submit nothing. Include the batch number and the date in the key.

Do not wait inside the loop for the queue to finish unless the batch is small. Each item can have its own communication.webhook_url, and a webhook trigger in a second workflow can handle results. The queue itself has no webhook.

How do I know the batch worked?

Poll GET /v1/format-run-queues/{id}. A queue with status completed means every item is terminal, not that every item succeeded. Check counts.failed, and fail the workflow when it is above zero so the problem shows in the n8n execution list.

Watch the reset option on the loop node. If a later node feeds new items back into the node with reset on, the loop restarts and submits again. Use a fixed input and a key that includes the batch number, so even that mistake replays rather than bills.