ZAPIER WEBHOOKS
Zapier webhook rate limits — bursts silently throttled
Zapier throttles inbound webhook bursts. During traffic spikes, some deliveries get 429s — and unless your sender retries with backoff, those events are gone for good.
Why Zapier webhooks fail silently
Burst limits on inbound hooks
High-frequency senders (order spikes, log streams) hit throttle thresholds that normal traffic never approaches.
Senders without retry logic
Many webhook senders treat any non-2xx as "failed once, dropped forever." A 429 with no retry is a silent drop.
Spikes are exactly when you can’t lose data
Black Friday order bursts are when throttling strikes — the worst possible time for silent drops.
The fix
- 1
Confirm the sender retries on 429
Check the sender’s docs — you want exponential backoff honoring Retry-After, not fail-once-drop.
- 2
Smooth the burst at the source
Batch or debounce high-frequency events upstream where the sender allows it.
- 3
Buffer through a proxy
HookShield acknowledges every delivery instantly and forwards in order — the sender sees 200s while you absorb the throttle window.
- 4
Alert on the drop pattern
A burst of 429s is itself a signal — HookShield records per-event forward status so throttling shows up as data, not absence of data.
DEAD-MAN'S SWITCH
Never find out about a dead webhook from a customer again
Point Zapier at a HookShield ingest URL. Every delivery is logged, signed, and forwarded — and if pings stop arriving, you're alerted before the silence becomes an incident.