Slack incoming webhook 1/sec: when 100 Sume jobs finish together
Slack incoming webhooks allow about 1 message per second. When 100 Sume jobs finish at once, store each webhook, then post to Slack from a paced queue.

Slack documents incoming webhooks at 1 message per second, with short bursts above that allowed. A Sume bulk run of 100 items can finish within a short window, so do not post to Slack from each Sume webhook handler. Store the event, return a 2xx, and let a paced queue do the Slack posts.
Slack numbers are from its rate-limits page, read 2026-10-01. Sume behavior is from Bulk runs, Webhooks and Run webhooks.
What does Slack say happens when you exceed it?
The page lists incoming webhooks at "1 per second" and says short bursts above one are allowed. Exceeding the limit returns HTTP 429 Too Many Requests with a Retry-After header giving the number of seconds until you can retry. Honour it.
Why do 100 Sume jobs hit that limit?
A bulk run takes 1-100 items and a required concurrency from 1 to 16, so up to 16 child runs complete in parallel and finishes cluster. Each child run can register its own terminal webhook, since the queue itself has no webhook. If every handler posts to Slack inline, 100 near-simultaneous finishes means far more than one message per second.
| Piece | Fact | What to do |
|---|---|---|
| Bulk run size | 1-100 items | Expect up to 100 events |
| Bulk concurrency | Required integer 1-16 | Finishes arrive in clusters |
| Sume delivery | Up to 10 attempts total | Return 2xx fast after storing |
| Duplicates | Dedupe run webhooks on request_id (equals run_id); job webhooks on job_id | Skip an id you already posted |
| Slack | 1 per second, bursts allowed | Post from a paced queue |
How should the handler be split?
Two stages. Stage one is the Sume webhook handler: verify, write the event keyed by its id (request_id for a run webhook, job_id for a job webhook), return 2xx. Stage two is a worker that drains stored events at or below one message per second and, on a Slack 429, waits for Retry-After. Sume's run-webhook sender also honours a Retry-After from your endpoint on 429 or 503, but storing the event and returning 2xx quickly is the documented path. A queue product can host stage two; see Cloudflare Workers Queues for video webhooks.
Should I send one summary message instead?
Often, yes. A single message such as "98 of 100 done, 2 failed" needs one Slack request, and you can post it when the bulk run's status_url shows every item is terminal. Note that the docs say completed means every item is terminal, not that all succeeded, so branch on counts.failed. For the run itself, see Format bulk runs: 100 renders.
Sources
Related posts
More in Integrations
- Snapchat Ads MCP and hosted Sume tools in one agent
Snap's Ads MCP server answers campaign questions and is read-only at launch. Add Sume's hosted MCP in the same agent to turn the findings into creative.
- Tavus PAL MCP connectors vs Sume hosted MCP tools and gates
Tavus MCP connectors let a PAL call third-party MCP servers. Here is what Sume's hosted MCP at mcp.sume.com exposes and the gates a paid call needs.
- Telegram Bot API 10.3 ephemeral sendVideo with a Sume clip
Bot API 10.3 adds ephemeral_message_parameters to sendVideo. Send a finished Sume artifact URL from your webhook handler; steps, retries and limits.
- VS Code 1.138 Codex and MCP tools: one Sume server entry
VS Code 1.138 lets Codex use VS Code's built-in, extension and MCP tools. Add Sume as one remote MCP server at mcp.sume.com and verify with tools_list.
Written by Sume