Receiving deliveries
Retries and replay
Your endpoint won't always be up, and that's fine. Webhooker holds every event and keeps trying, so a deploy or a brief outage never costs you a webhook.
What happens when a delivery fails
If your endpoint doesn't return a 2xx, Webhooker retries with
exponential backoff and
jitter. A per-destination circuit breaker stops hammering an endpoint
that stays down, and deliveries that exhaust their retries land in a
dead-letter queue rather
than disappearing.
Replaying events
From the dashboard you can replay any single event or resend a whole batch once your service recovers. Nothing is lost while you fix the problem — the event sits in the queue until you're ready for it.
Because deliveries retry and can be replayed, your handler should be
idempotent: key on
X-Webhooker-Event-Id so a retried or replayed delivery is
processed at most once. The ID is stable across every attempt for the same
event.
At-least-once delivery
Webhooker aims to deliver each event at least once. In
practice that means the same event can reach you more than once — for
example when your app returns a 2xx but the connection drops
before we record it. The event ID is your defense: dedupe on it and a
duplicate delivery becomes a no-op.