Limits

Sizes and rates#

Request body	100 KB	Larger requests are rejected at receive
Receive rate, per endpoint	12,000/min (~200/sec)	Abuse guard, not a traffic cap
retry_max_attempts	10 max	Per destination
Event retention	14 days	Events and delivery attempts alike

Timing#

Config changes reaching the receive path	up to 60 seconds
Config changes reaching the delivery path	up to 60 seconds
An event becoming queryable	around 1 second

Config changes means pausing or resuming an endpoint or destination, rotating a secret, adding or removing a destination. Configuration is cached in front of the database because every single webhook needs it and it almost never changes; 60 seconds is the cost of that.

The one-second figure for queryability is a consequence of batched writes to the event store. It is near-live, not synchronous — an event that was just delivered may not be in a list response yet.

Delivery semantics#

At-least-once. Retries mean the same event can reach a destination more than once. Handlers must be idempotent on catchook-event-id.

Unordered. Jobs are independent and retried independently. A retried event can arrive after one received later. Order by a payload field if order matters.

Best-effort recording. The event record is written after the response goes back to the provider, so an outage in the event store can lose the record of a webhook that was received and delivered correctly. Delivery is never blocked by recording.

What a paused thing does#

Paused endpoint	Returns 200, records nothing, queues nothing. Not a buffer
Paused destination	Events are received and recorded; jobs for this destination are dropped

Pausing an endpoint answers 200 rather than an error on purpose: providers disable subscriptions that keep failing, so a planned pause should not look like a broken endpoint.

To catch up after a pause, replay the window — but only within the 14-day retention, and only for a paused destination. Events not recorded during an endpoint pause cannot be recovered.