voice_settings object on the Assistants API controls how an assistant
opens a phone call and what it does when it reaches voicemail. It is accepted
on POST /v3/assistants and PATCH /v3/assistants/{id}. Successful
POST /v3/assistants responses and GET /v3/assistants/{id} return it (the
list endpoint does not include it).
Three concepts, kept distinct
The API deliberately separates three things that are easy to conflate:- Greeting text —
inbound_greeting/outbound_greeting. Context text that feeds the{{greeting}}template variable your prompt can reference. It is not spoken automatically. These remain writable via the top-level body fields; insidevoice_settingsthey appear read-only for convenience. - Opening message — what the assistant literally says first on a call,
per direction (
inbound_opening_message/outbound_opening_message). Only used infixedgreeting mode. - Voicemail behavior —
voicemail_message. When voicemail is detected: an empty ornullvalue means the assistant hangs up; a non-empty value is spoken to the voicemail, after which the assistant stops.
Greeting modes
Rules the API enforces:
fixedmode requires at least one opening message. Switching an existing assistant tofixedkeeps its stored messages, so a mode-only update is valid when messages already exist.- Opening messages are only accepted while the effective mode is
fixed— setgreeting_mode: "fixed"in the same request if needed. - In
fixedmode, sendingnullfor one direction clears it, as long as at least one opening message remains.
Example
Request — put an assistant into fixed mode with per-direction openers and a voicemail message:GET /v3/assistants/{id} then returns:
Notes
enable_voicemail_detectionrecords intent and is returned on read, but voicemail detection is currently platform-managed — the flag does not yet change runtime behavior.- Reverting an assistant to a previous version does not restore
voice_settings; greeting mode, opening messages, and voicemail behavior keep their current values.
