Webhook rate limits: Zapier, Airtable, Pipedream vs a bulk of 100

A 100-item Sume bulk queue can produce up to 100 run webhooks, which is well under Zapier's published 1,000 per 5 minutes per Zap, but Airtable's five requests per second and Pipedream's 10 per second average are per-second figures that a burst of finishes can approach. Each item carries its own communication.webhook_url; the queue has none.

Sume facts are from the Bulk runs docs; every vendor figure was read 2026-09-30.

What does each receiver publish?

Zapier lists 20,000 requests per 5 minutes per user and 1,000 per Zap on legacy routes, answering 429 when exceeded. Airtable lists five requests per second and a 100kb payload. Pipedream lists an average of 10 requests per second and a 512KB body by default.

Does the concurrency setting spread deliveries out?

It limits how many child runs are in flight at once, from 1 to 16, so finishes trickle in as items complete rather than all at one instant. The docs do not promise a delivery rate, so measure a small batch before sizing a large one.

What should I do if the receiver pushes back?

For run webhooks, Sume retries up to 10 attempts with exponential backoff and honors Retry-After on 429 and 503. Poll GET /v1/format-run-queues/{queue_id} as the source of truth, and remember that completed means every item is terminal, not that all succeeded.

Which receiver should I pick?

Choose on your payload and rate, not the vendor name. If a receiver cannot verify signatures, as Airtable states, verify in a small relay first and forward a slim object with request_id.