/webhooks: list,
create, change, delete, test, deliveries, redeliver).
Every delivery
X-FireTone-EventX-FireTone-DeliveryX-FireTone-Signature: t=<unix>,v1=<hex>- any headers you configured on the webhook
- Saved before it’s sent. A restart or an outage at your end doesn’t lose an event.
- Retries until your receiver answers
2xx: after 30 s, 5 min, 30 min, 2 h and 12 h. - Switched off after three days of failures. The webhook shows why, and your admins are emailed.
- Send again re-queues a delivery with the same body and the same id.
The events
A call placed by a test in the IVR designer carries
"test": true.
Checking the signature
v1 is the hex HMAC-SHA256 of "<t>.<raw body>", keyed with the webhook’s
secret. Check it against the raw bytes before parsing, and reject a t more
than about five minutes old.
Webhooks or callbacks?
Both use the same format, retries and delivery log.
Receiving them in order
Events go out in the order they happened, but a retried one can arrive after later ones. If order matters, useoccurred_at. Your receiver should also
ignore a delivery id it has already processed.