Skip to main content

​
Inbound

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

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 /calls returns the queued call immediately. Poll GET /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 are busy, declined, no_answer, temporarily_unavailable, invalid_destination, authentication_failed, destination_forbidden, trunk_unavailable, and no_outbound_trunk. The object never contains raw SIP responses, connection credentials, infrastructure identifiers, or SDK error text. 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.

​
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.