Looping by Zapier: send one API request per item in a list
Looping by Zapier runs every later action once per list value, all in parallel, up to 500 times. Pace and key paid API calls to match.

Looping by Zapier is a Zap step that splits a list (text, line items, or a number range) into iterations, and every action after it runs once per iteration. Put a Webhooks by Zapier request after the loop and you get one API request per item. Zapier runs all iterations in parallel, so a paid API sees the whole list at once.
The Zapier facts come from Zapier's help pages Loop your Zap actions, Understanding Looping by Zapier and Send webhooks in Zap workflows. The Sume facts come from Authentication, Generation admission and Create a run. All were read on 2026-09-29. Zapier marks Looping as an open beta that may change. Sume has no official Zapier app.
How do I use looping in Zapier?
Zapier's steps, in order:
- Add an action step, search for Looping by Zapier, and pick an Event: Create Loop From Text, Create Loop From Line Items, or Create Loop From Numbers.
- In Values to Loop, name the value on the left and map the list on the right. For text, the default delimiter is a comma.
- Add the API call after the loop. Map the loop's named field, never
preview_loop_values, which exists only in tests. - A test creates only the first loop. The live Zap runs them all, and each iteration shows as a separate Zap run in Zap history.
- To run a step once at the end, add a filter that continues only when
loop_iteration_is_lastis true.
What are the limits?
Zapier's limits are on the loop. The API's limits are on how many requests arrive together, and with parallel iterations that is the loop length.
| Limit | Value |
|---|---|
| Zapier: iterations per loop | Up to 500 |
| Zapier: how iterations run | In parallel, even inside a sequential Path |
| Zapier: nested loops | Not supported; one Looping step per Zap |
| Zapier: tasks | The loop step is free; each action after it uses 1 task per iteration |
| Zapier: webhook action payload | 5MB maximum |
| Sume: writes per minute per key | 120 Free, 300 Pro, 600 Startup, 1200 Scale |
| Sume: paid jobs accepted at once | 6 Free, 24 Pro, 48 Startup, 120 Scale |
Will a long loop trip the API's limits?
It can, because Zapier runs every iteration in parallel. On Sume, a direct generation job submit (such as POST /v1/videos) past the plan's processing concurrency waits as queued, and once the queue is also full a new submit fails with 429 queue_full. On Free, a 20-value loop of job submits would have its seventh request refused while the first six are still queued or running.
A Format run create, like the example below, still counts against the workspace's generation concurrency; the error Sume's Format docs list for too many requests is 429 rate_limited.
- Keep each loop within the accepted capacity your plan allows, and split longer lists across Zap runs.
- Or send one request for the whole list: a Sume Format bulk run takes 1–100 items with a
concurrencyof 1–16 and keeps that many in flight on the server. Format bulk runs covers it. - Read the response code on each iteration. A
429names its budget inerror.details.scope.
How do I stop a rerun from paying twice?
Give each iteration its own Idempotency-Key built from the item, such as an order id plus the line's SKU and a version. Sume's docs say the same key with the same body returns the original, with no second run and no second charge; a random key per request makes the header decorative. Use a Custom Request if you need exact headers and raw JSON; Zapier sends that body exactly as typed.
Don't wait for results inside the loop. Set each item's communication.webhook_url to a second Zap's catch hook and let Sume post there when each run completes or fails, as Zapier AI video automation shows.
POST https://api.sume.com/v1/formats/acme/product-promo/runs
Authorization: Bearer $SUME_API_KEY
Content-Type: application/json
Idempotency-Key: order-123-sku-4410-v1
{ "instruction": "15-second vertical promo", "input": { "sku": "4410" },
"communication": { "webhook_url": "https://hooks.example.com/catch/sume" } }Sources
Related posts
More in Integrations
- Make.com error handling: retry a paid API call without duplicates
Make.com has five error handlers; Retry stores the failed bundle and reruns it. Send a fixed Idempotency-Key so a rerun can't bill twice.
- n8n error workflow: make it fire when an API job fails
An n8n error workflow runs only when an execution fails. A remote job that ends failed is a normal 200 read, so check its status and throw with Stop And Error.
- n8n HTTP Request timeout: what to do when a job takes minutes
The n8n HTTP Request node's Timeout option aborts slow responses. For jobs that take minutes, submit async, then poll with a Wait node.
- n8n Loop Over Items: batch paid API calls under a rate limit
n8n's Loop Over Items node sends items through in batches of Batch Size, then emits all results on done. Pair it with Wait to pace a paid API.
Written by Sume