Make webhook 300 requests per 10 seconds: Sume bulk callbacks

If a Make custom webhook gets more than 300 requests in a 10-second window, Make answers 429. When Sume is the sender, that 429 is just a non-2xx response: the attempt counts as failed and Sume tries again, up to 10 attempts. Job webhooks use a fixed 30-second delay by default; Format run webhooks, which a bulk run's items use, back off exponentially. Dedupe on job_id so a retried delivery never runs your scenario twice.

Make's limit is from its Webhooks help page; Sume's retry rules are from the webhooks docs, both read 2026-10-01.

What does Make say about the limit?

The page says Make can process up to 300 incoming webhook requests per 10 second interval, and returns status 429 beyond that. It also lists 400 "Webhook queue full" when the queue has no room, which is a separate case covered in Make webhook queue full 400.

How does a Sume bulk run create callbacks?

A bulk run takes 1-100 items and a required concurrency of 1-16, which is how many child Format runs stay in flight at once. The queue itself has no webhook: communication.webhook_url is set per item, so each finishing item posts its own callback. Details are in Format bulk runs.

Sume docs give no callbacks-per-second figure, so measure your own burst before assuming it stays under 300 per 10 seconds.

What happens when Make answers 429?

How do the bulk-run limits set the burst size?

The ceiling on simultaneous work is concurrency, at most 16, and the ceiling on total work is 100 items per queue. A queue of 100 items at concurrency 16 therefore has at most 16 child runs in flight at any one moment, and the rest start only as slots free up. completed on the queue means every item is terminal, not that all succeeded, so branch on counts.failed.

How do I keep the scenario safe?

Use job_id as your idempotency key inside Make, for example by storing seen ids in a data store before doing work. Lower concurrency if refusals are frequent, since fewer in-flight runs means fewer terminal events at once. If a delivery is exhausted, POST /v1/jobs/{job_id}/webhook/redeliver re-posts the real terminal event for jobs. Bulk-run items are Format runs, which have their own run webhooks with the same 10-attempt cap but exponential backoff (honoring Retry-After on 429 and 503) instead of a fixed delay.