Make webhook queue: 667 items per 10,000 credits and Sume

A Make custom webhook queues incoming calls until the scenario runs, and that queue holds 667 items for every 10,000 licensed credits per month, up to a maximum of 10,000. A plan with 30,000 credits therefore buffers 2,001 items. Sume sends one run webhook per run, so the queue only fills if the scenario is off or runs slower than the arrival rate.

The Make facts are from Webhooks, read 2026-10-10. The Sume facts are from Run webhooks and Webhooks.

What does Make document?

The page says the queue holds 667 items per 10,000 licensed credits per month, with a maximum of 10,000. Webhook logs are kept for 3 days, or 30 days on Enterprise. A webhook accepts 300 incoming requests per 10 seconds. The default response is 200 with the text "Accepted", and a scenario triggers immediately unless you schedule it.

The arithmetic is simple, but check the live page for your plan before you size anything. The figure is per licensed credits, so a plan change changes the queue the same day.

When would Sume fill the queue?

Only when the scenario cannot keep up or is paused. If the scenario is slower than the arrival rate, or you pause it, items wait in the queue and nothing is lost until the queue is full. If a call arrives with the queue full, assume it fails and Sume counts a failed attempt.

Sume then retries. The run webhook backoff is min(max(30 s x 2^(n-1) with jitter, Retry-After), 1 h) for up to 10 attempts, with a 10 second timeout per attempt, and a redirect counts as a failure. If you stay broken for the full schedule, the delivery ends as failed or exhausted, and you replay it with POST /v1/format-runs/{run_id}/webhook/redeliver.

A useful habit is to estimate the burst. If a bulk queue of 100 items ends together, each item with its own webhook, 100 events arrive close together. That is well under 300 requests per 10 seconds, and under the smallest queue of 667 items, so a single burst is not the risk; a long pause is.

How do I keep the scenario honest?

Use the default quick 200 response so Sume does not wait on your scenario's work. Make acknowledges on receipt, and the scenario processes the item afterward. That fits Sume's 10 second timeout easily.

Inside the scenario, dedupe on request_id. The envelope also carries status, outcome, and payload, the run receipt. When the receipt is larger than 1 MiB, payload is null and an error payload_too_large points to a result URL to fetch. Branch on outcome: ok, degraded or error. A degraded run completed and was billed, with real media but without projected output.

What about logs and signatures?

Webhook logs are kept for only 3 days on non-Enterprise plans, so copy the run id and outcome into your own sheet or database. After that, the Sume receipt is your record, and its webhook_delivery field shows the url, status, attempts and signing_secret_fingerprint.

If you need to verify the Sume signature, which is computed over the raw body bytes, check whether your scenario can see those bytes unchanged. If it cannot, put a thin receiver in front, verify there, and forward the event to Make.