Zapier Delay After Queue: space out Sume submits

Use Zapier's Delay After Queue step before the Sume request to release one held task after another instead of all at once. A burst of new rows then reaches Sume as a trickle, and you are less likely to meet 429 queue_full. Delay is not available on the Free plan, and the queue holds a limited number of tasks, so size it for your burst.

The Zapier facts are from Add delays to Zaps, read 2026-10-10. The Sume facts are from Generation admission and Errors and rate limits.

What does the delay step give you?

The Zapier page lists Delay For, Delay Until and Delay After Queue. The minimum delay is 1 minute and the maximum hold is 30 days. Queue capacity depends on the delay length; the page gives the example that a 1-day delay holds 30 tasks. Delays do not count toward task usage, and the feature is not on the Free plan. A search snippet for the same page mentions a 100-step limit per Zap; confirm it on the live page before depending on it.

Check the live page for your plan before you build. The facts here were read on 2026-10-10, and Zapier changes plan limits more often than API rules.

Why pace the submits at all?

Sume accepts valid jobs as queued while queue capacity remains. The per-plan figures in the admission docs give processing concurrency of 1, 4, 8, 20 and queue capacity of 5, 20, 40, 100 for Free, Pro, Startup and Scale. A spreadsheet import that triggers 60 Zaps in a minute is far past a Pro queue of 20, and the surplus returns 429 queue_full.

The error page tells you to honor retry-after on any 429. A paced Zap rarely needs that, because the gap you set is the spacing.

A plain-text rule helps: the gap should be longer than a typical render divided by your concurrency. The admission docs do not publish a render time, so measure your own Format over a week before you set it.

How do I set the spacing?

Choose the gap from your plan, not from a guess. If you run Pro with concurrency 4, and a typical render takes minutes, a gap measured in minutes keeps the queue short. Read the render duration of your own Format first; the admission docs deliberately avoid promising one.

Place the delay as the step before the webhook or Code step that calls POST /v1/formats/{handle}/{slug}/runs. Add the Idempotency-Key header built from the row id, so a Zap replay returns the original run instead of a second one.

Where does the result come back?

Do not keep the Zap open waiting. Give the run a communication.webhook_url that points at a Catch Hook Zap, and Sume calls it once when the run is terminal. The delayed Zap submits; the second Zap handles the result. Dedupe on request_id, because the run webhook envelope is delivered at least once.

Cap the spend per run with generation_spend_cap_usd, since a spreadsheet can grow faster than anyone watches it.

One more habit helps with a delayed Zap: put the item and version in the idempotency key, not the Zap run id. If someone replays the Zap from history in a month, the same item returns the original Sume run instead of billing another render. The replay is then harmless, which is what you want from a tool people click on.