What to send
A webhook should carry the minimum useful outcome, not a noisy transcript dump by default.
- Wired event types: call.completed and transcript.ready
- Caller, intent, urgency, and language
- Summary, tags, and next action
Webhooks
Send structured call outcomes to CRMs, calendars, ticketing tools, sheets, Slack, Teams, or internal systems without turning the project into a custom voice stack.
Technical example
POST /havio/events
havio-webhook-id: 7e825c50-9938-42aa-bfb9-dfe21853afe8
havio-webhook-event: call.completed
havio-webhook-timestamp: 1784377800
havio-webhook-signature: v1=<hex_hmac_sha256>
idempotency-key: 7e825c50-9938-42aa-bfb9-dfe21853afe8
{
"id": "evt_01JLC8W9Q4P2N7A6K3",
"type": "call.completed",
"data": {
"callId": "call_01JLC8W9Q4P2N7A6K3",
"outcome": "booked",
"destination": "google_calendar"
}
}Best buyer
Teams that want automation without a full custom integration
Primary risk
No owner for failed webhook deliveries
Havio advantage
Structured outcomes and clear retry ownership
A webhook should carry the minimum useful outcome, not a noisy transcript dump by default.
Verify the v1 HMAC before processing the raw request body, then record the delivery ID and result.
Treat webhook destinations as production systems that may receive customer or caller data.
Delivery state is durable and explicit enough for operations to audit every attempt.
A webhook is not complete until the team can see what happened when delivery fails.
Related developer paths
Technical pages work best when they point back to the operational buyer questions: source of truth, fallback, billing, security, and review.