Events before endpoints
Start by deciding which business events matter after a call, then map the API contract.
- call.started
- intent.detected
- booking.requested
- transfer.attempted
- call.completed
Preparing the Havio workflow view
Preparing the Havio workflow view
API planning
Use the API surface when a call outcome needs to create structured work in a custom product, internal system, or reporting pipeline.
Technical example
{
"event": "call.completed",
"callId": "call_01JLC8W9Q4P2N7A6K3",
"agentId": "agent_booking",
"occurredAt": "2026-06-30T14:22:11Z",
"caller": {
"phone": "caller_phone_e164",
"timezone": "America/New_York",
"language": "en"
},
"intent": "lead_qualification",
"outcome": "qualified",
"summary": "Caller requested a Friday quote window.",
"consent": {
"aiDisclosed": true,
"recordingEnabled": false
},
"fields": {
"service": "hvac_install",
"urgency": "routine",
"preferredWindow": "Friday morning"
},
"destinationStatus": "crm_task_created"
}Best buyer
Teams with internal systems or custom workflow software
Primary risk
Treating a voice agent like a generic data pipe
Havio advantage
Business outcomes first, API payload second
Start by deciding which business events matter after a call, then map the API contract.
API consumers need predictable names, status values, and missing-data behavior.
A production API path needs idempotency, retry logic, and a human-readable failed-write state.
Custom API access is scoped during onboarding so the integration contract matches the workflow being launched.
Treat API events as operational records that may contain caller data, consent state, and business-sensitive context.
Related developer paths
Technical pages work best when they point back to the operational buyer questions: source of truth, fallback, billing, security, and review.