- HTTP connections: your IVR asks your system about a caller mid-call, using the Fetch data step.
- Webhooks: FireTone tells your system when a call starts, is answered and ends.
https:// addresses. FireTone refuses private,
loopback and cloud-internal addresses, even when a hostname resolves to one
or a redirect points there.
HTTP connections
A connection is a base URL and the headers your system needs, usuallyAuthorization: Bearer … or an API-key header. A Fetch-data step picks a
connection and adds its own path, so the key lives in one place, not in every
flow.
- Header values are stored encrypted and never shown again. When you edit a connection, leave a saved header blank to keep it.
- Turn on signing to have every request carry
X-FireTone-Signature, so your system can check it really came from FireTone (see below). - Every request also carries
X-FireTone-Call: <call id>. - Test runs a request and shows the answer.
Telling the phone about a call
Your own system can put a card on the phone while a call is up — the caller’s account, what they owe, what the agent should ask. Two ways, both in Organisation settings under Your systems, during a call and in the API:- Call-info URL. On every answered call FireTone POSTs the call’s facts
(caller, destination, extension, agent, team) to the URL, signed with the
signing secret (
X-FireTone-Signature: sha256=…). Answer a note —{"title": "…", "body": "…", "level": "info" | "warning" | "alert", "ack": true, …any other fields as rows}— and it appears on the FireTone app or the Desk softphone; answer204to show nothing. Five seconds;httpson a public address. - The API:
POST /calls/{uuid}/infoduring a call (about the call), orPOST /extensions/{id}/messageto a person, with or without a call.
ack: true puts an Acknowledge button on the card; when the agent taps it
your webhook receives call.info.acked — the person’s act, not the phone’s
receipt. Every card sent is call.info.sent. Conference rooms use the same
channel to tell everyone in the room who joined. The full format is in
Messages to the phone.
Webhooks
A webhook sends the events you pick to your URL, as a JSONPOST:
- Nothing is lost. Every event is saved before it is sent, so a restart, or your system being down, doesn’t drop it.
- Delivery: a
2xxanswer counts as delivered. Anything else is retried after 30 seconds, 5 minutes, 30 minutes, 2 hours and 12 hours (six tries in about 15 hours), then marked failed. - Deliveries lists every attempt for 14 days: its status, the answer, and the exact body that was sent.
- Send again re-queues a delivery, for example after you’ve fixed your
system. It sends the same body with the same
id. - Switched off after three days. A webhook whose deliveries have all failed for three days is switched off. It shows why, and your organisation’s admins are emailed. Switch it back on once your system is fixed.
- Duplicates: a retry carries the same
id(also sent asX-FireTone-Delivery), so your system can ignore a repeat. - Order: events are sent in the order they happened, but a retry can arrive
after later events. Use
occurred_atif order matters. - Secret: each webhook has its own signing secret, shown once when it is created or rotated.
- Test: Send test posts a
webhook.testevent, signed like a real one.
Checking a signature
The full event reference, with every payload and PHP as well, is in the API documentation. Every signed request carries:v1 is the hex HMAC-SHA256 of "<t>.<raw body>", keyed with your secret.
Check it against the raw bytes of the body, before parsing, and reject a t
more than a few minutes old.