Skip to main content

​
Inbound calls

Route any number — bought in the marketplace or brought via BYO trunk — to an assistant:
  1. Phone numbers → select number → assign assistant.
  2. Incoming calls are answered by that assistant, using its greeting mode (speak first, or wait for the caller).
  3. Recording (with consent handling if enabled), transcription, and call events happen automatically.
The number → assistant mapping resolves per call, so you can reassign numbers at any time without touching the number itself.

​
Outbound calls

Three ways to place calls:
  • Single call from the UI — on an assistant page, enter a number and call: ideal for testing.
  • API / MCP — make_call with assistant_id and to_number, plus optional lead data the assistant can use in conversation (name, custom fields). See the API Reference.
  • Campaigns — bulk outbound over a lead list with dialer logic; see Campaigns.
Outbound behavior details:
  • The assistant greets only after the callee picks up (no talking into ringing).
  • Unanswered outcomes map to clean statuses: busy, no_answer, failed — campaign retry logic builds on these.
  • With greeting mode: user speaks first, the assistant waits for the callee’s “Hello?” — noticeably more natural for cold calls.
  • Optional answering machine detection (AMD) classifies who picked up (human / voicemail / IVR) and can drop a configured voicemail message; see Dialer & compliance.

​
Failure guidance

POST /api/v1/calls returns the queued call immediately. Poll GET /api/v1/calls/{id}, use get_call, or consume call.completed to receive the final result. Failed outbound calls include a provider-neutral failure object:
Common codes include busy, declined, no_answer, temporarily_unavailable, invalid_destination, authentication_failed, destination_forbidden, trunk_unavailable, and no_outbound_trunk. History shows a short reason together with the recorded SIP code, for example Calling connection blocked · SIP 403. A blocked calling connection (caller_blocked) requires an explicit response; a generic 403 is shown as Call not permitted. Routing conflicts (routing_conflict) and confirmed routing loops (routing_loop) are distinguished, as are unsupported methods (method_not_allowed), call setup timeouts (connection_timeout), ringing without an answer (no_answer), and cancellations (cancelled_before_answer). Other responses cover authentication, destination, call format, routing, security, and phone network failures. Technical details can be expanded when needed. A local timeout without a SIP response has no SIP code. Existing calls use the recorded response when available. The same concise reasons are returned by REST, MCP, and call webhooks. retryable is guidance for your integration. It does not modify campaign retry settings. If a cold or warm transfer fails while the original call remains active, the call’s event log contains call_transfer_failed or warm_transfer_failed. Those events use the same failure shape with operation: cold_transfer or warm_transfer.

​
Web calls

Every assistant can also be called from the browser — used by the built-in test call and the embeddable web widget. Web calls appear in the call history with direction web.
Assistant Test menu with separate Web Call and Call options

In the assistant’s Test menu, Web Call starts a browser voice test. Choose Call instead to enter a destination for an outbound phone test.

​
Call results

Every call — regardless of direction — produces: a transcript, duration and status, provider-neutral failure guidance when applicable, per-turn latency metrics, an event log (tool calls, transfers, consent, node transitions), optional recording, and a call.completed webhook.