What to send
A webhook should carry the minimum useful outcome, not a noisy transcript dump by default.
- Caller, intent, urgency, and language
- Summary, tags, and next action
- Destination status and failed-write reason
Preparing the Havio workflow view
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
X-Havio-Event: call.completed
X-Havio-Signature: sha256=...
Idempotency-Key: call_01JLC8W9Q4P2N7A6K3_completed
{
"callId": "call_01JLC8W9Q4P2N7A6K3",
"event": "call.completed",
"outcome": "booked",
"destination": "google_calendar",
"retryCount": 0,
"destinationStatus": "delivered"
}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.
Webhook buyers need to know if a call outcome landed in the right place.
Treat webhook destinations as production systems that may receive customer or caller data.
Webhook delivery should be explicit enough that operations can audit the result after every handled call.
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.