Make takes 300 webhook requests per 10 seconds: fan in a Sume bulk run

A single Sume bulk run cannot trip Make's limit on its own: it holds at most 100 Format runs and runs at most 16 at once, while Make accepts up to 300 webhook requests per 10 seconds. Trouble comes from several bulk runs finishing together, or from retries stacking on top.

Sume's bulk queue has no webhook of its own, so each child run carries its own communication.webhook_url, and that is where the fan-in happens.

The two limits side by side

Worst case arithmetic

One bulk request of 100 runs sends at most 100 terminal webhooks, which is a third of Make's 300 per 10 seconds. Three full bulk requests landing in the same ten seconds would reach 300, and any retries or other traffic push you over. Because the window is 16 at most, runs complete in waves, so a single bulk request usually spreads its callbacks out over time rather than sending all 100 at once. That spread is my reading of the concurrency window, not a promise.

Design choices

• Send each child to the same Make webhook and carry the row id in the run input, so one scenario handles everything.
• Do not expect one callback for the whole queue. Poll the queue's status_url for overall progress and for counts.failed, because queue completed means every item is terminal, not that all succeeded.
• On a 429 from Make, Sume counts a failed attempt and retries, with backoff that obeys Retry-After, up to 10 attempts. A short burst is absorbed by that schedule. Details are in the run webhooks docs.
• Use a fresh Idempotency-Key per batch. A replayed key returns the original queue.

When 429 still appears

Fall back to polling the queue and reading each child at GET /v1/format-runs/{run_id}. A webhook is an alternative to a poll loop, never the only path. Lower concurrency if you want the callbacks spread out further.