Webhooks and events
Delivery states, inbound replies and consent changes arrive as signed callbacks. They keep arriving while your consumer catches up, and they stay replayable for a month if it does not.
- 24 hours
- Retry window
- HMAC-SHA256
- Signature
- 30 days
- Replay
Nothing goes missing while your side is down
- Each callback is stamped with a rotating secret and a time bound you can check
- Backoff attempts spread over twenty four hours before the event parks in a queue you can drain
- One message's events arrive in the order they happened, each numbered so a hole is obvious
- Callbacks leave from three regions and cut over between them on their own
- A running feed in the console, so you can watch the odd case happen instead of instrumenting for it
- At-least-once delivery with stable event ids, so idempotent consumption is trivial
Build order
- 1RegisterGive us an HTTPS endpoint, tick the classes you want, and keep the secret we show you.
- 2VerifyCheck the signature over the raw body and reject anything older than five minutes.
- 3AcknowledgeStore it, answer 2xx straight away, do the work afterwards. A slow answer earns a retry.
- 4ReplayLost events to a bad deploy? Ask for the last thirty days again, from any position.
Put webhooks and events to work
Sandbox keys cost nothing and mirror the live gateway, rejections included, so your ops team can watch a message land on a handset before anything is signed.