Webhook
Sendly calling your server when something happens, instead of your server asking repeatedly whether it has
A webhook is a reversal of the usual direction: rather than your code polling an API to ask whether anything has happened, you register a URL and Sendly POSTs to it when something does — a message delivered, bounced, opened, clicked, or complained about.
It is how a delivery record in Sendly becomes a state change in your own system: marking a contact, alerting a support queue, or stopping a dunning sequence when the invoice is finally paid.
The three things every webhook consumer needs
- Verify the signature. An endpoint that accepts any POST is an endpoint anybody can forge events into. Sendly signs deliveries; check the signature before you trust the body.
- Be idempotent. Retries mean the same event can arrive twice. Key your handling on the event id so processing it a second time changes nothing.
- Answer quickly. Acknowledge with a 2xx and do the work afterwards. An endpoint that takes ten seconds to reply looks like an endpoint that is down.
Ordering
Do not assume events arrive in the order they happened. Deliveries and retries interleave. Use the timestamp on the event rather than arrival order when the sequence matters.
In Sendly
Webhooks are configured per project, deliveries are signed and retried on failure, and the same events are also queryable through the events API — so a webhook you missed during an outage is not information you have lost.
See the webhooks guide.