Skip to main content
A webhook posts the events you choose to your URL as signed JSON. Manage them in Developer → Webhooks & callbacks, or through the API (/webhooks: list, create, change, delete, test, deliveries, redeliver).
The response includes the webhook’s signing secret, shown once.

Every delivery

Headers on every request:
  • X-FireTone-Event
  • X-FireTone-Delivery
  • X-FireTone-Signature: t=<unix>,v1=<hex>
  • any headers you configured on the webhook
Delivery:
  • 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, use occurred_at. Your receiver should also ignore a delivery id it has already processed.