Integrations

Webhooks

Events pushed to your system, signatures, retries, and the portal panel.

The short answer

What: A call ends, your server gets a POST. A message arrives, your server gets a POST. No polling.
Eleven events: Four for calls, three for messages, four for faxes.
Signed: Every delivery carries an X-Vocatech-Signature header you verify with the subscription’s secret.
Where: The Webhooks panel on the company Settings page, or the API. Same list either way.

Subscribing

A subscription has a name, a destination URL, a signing secret, an on-off switch, the events it wants, and optionally the numbers it is limited to. Create it in the API or in the portal: the company's Settings page carries a Webhooks panel behind a Webhooks toggle, visible to a login with the Company Edit permission, and it reads and writes the same list the API does. The secret is shown when the subscription is created and never again, so store it then. Several subscriptions per company are fine: call events to one system, message events to another.

The events

  • call.started, call.answered, call.ended, and call.transcription, which fires when the transcript and summary are ready, usually a minute or two after the call.
  • message.sent, message.received, message.status_updated.
  • fax.sent, fax.received, fax.delivered, fax.failed.

Anything outside that list is refused when the subscription is created, with the allowed list in the error. Subscribe to only what you need.

Verifying a delivery

Every delivery carries two headers. X-Vocatech-Event names the event. X-Vocatech-Signature reads t=<timestamp>,v1=<signature>, where the signature is an HMAC-SHA256, keyed with your secret, over the string made of t=, the timestamp, a period, and the raw request body. Compute the same thing on your side, compare, and reject anything that does not match or whose timestamp is older than you are willing to accept. The exact payloads are in the developer guide.

Responding, and retries

Return a 2xx quickly and do the heavy work afterwards; queue the event and answer, rather than making the delivery wait on a database write. Anything else is treated as a failure and retried with increasing gaps. Failed deliveries are listed on the subscription in the API and the panel, and a test send fires a synthetic event at your endpoint so you can check the signature and the response before going live. Handle the same event arriving twice: when your endpoint comes back after an outage it gets a burst, and the event id is the key to dedupe on.

Message events without the rest

A metered messaging key can manage subscriptions to the three message events only; the call, transcription and fax events need the company's standard key. See texting from your own software and REST API basics.

Checked against the product on 6 September 2026. If something on this page is behind, tell us and we fix the page.

Still stuck?

A real person at Vocatech picks up, usually within minutes during business hours. A message from the contact page opens a ticket with our team.