Update an assistant
Updates the specified AI assistant’s attributes and returns the updated assistant. The request can also control how the change is promoted across assistant versions.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Unique identifier of the assistant.
Body
ID of the model to use when external_llm is not set. You can use the Get models API to see available models. If external_llm is provided, the assistant uses external_llm instead of this field. If neither model nor external_llm is provided, Telnyx applies the default model.
System instructions for the assistant. These may be templated with dynamic variables
Deprecated for new integrations. Inline tool definitions available to the assistant. Prefer tool_ids to attach shared tools created with the AI Tools endpoints. On update, a sent tools array fully replaces the assistant's inline tools; omit the field to leave the inline tools unchanged. Each tool type except function, webhook, and client_side_tool allows at most one instance per assistant, counted across inline tools and shared tool_ids combined — sending a duplicate of such a type returns HTTP 400 with error code 10015. Responses merge shared tools into tools with shared: true; when updating, omit those tools from the tools array and manage them through tool_ids instead.
- FunctionTool
- WebhookTool
- ClientSideTool
- RetrievalTool
- HandoffTool
- HangupTool
- TransferTool
- InviteTool
- SIPReferTool
- DTMFTool
- SendMessageTool
- SkipTurnTool
- PayTool
- UpdateDynamicVariablesTool
MCP servers attached to the assistant. Create MCP servers with /ai/mcp_servers, then reference them by id here.
A2A agents this assistant can delegate to. Tools are not stored here: at the start of every conversation each agent's card is fetched and one tool is derived per skill the card advertises, named a2a_<name>_<skill_id>. The following limits are not enforced when the assistant is saved, and anything past them is dropped when the conversation starts: 64 agents per assistant, 64 skills per card, 128 derived tools per assistant, and a 6 second budget for all card fetches combined. An agent whose card cannot be fetched costs the assistant that capability for the conversation; it does not fail the call. Omit this field to leave the assistant's agents unchanged; send an empty array to remove them all.
IDs of shared tools to attach to the assistant. New integrations should prefer tool_ids over inline tools. On update, a sent tool_ids array fully replaces the assistant's attached shared tools; omit the field to leave them unchanged. Single-instance tool types are counted across inline tools and tool_ids combined, so attaching a shared tool of such a type when an instance already exists returns HTTP 400 with error code 10015.
Text that the assistant will use to start the conversation. This may be templated with dynamic variables. Use an empty string to have the assistant wait for the user to speak first. Use the special value <assistant-speaks-first-with-model-generated-message> to have the assistant generate the greeting based on the system instructions.
This is only needed when using third-party inference providers selected by model. The identifier for an integration secret /v2/integration_secrets that refers to your LLM provider's API key. For bring-your-own endpoint authentication, use external_llm.llm_api_key_ref instead. Warning: Free plans are unlikely to work with this integration.
If telephony is enabled, the assistant will be able to make and receive calls. If messaging is enabled, the assistant will be able to send and receive messages.
telephony, messaging If dynamic_variables_webhook_url is set, Telnyx sends a POST request to this URL at the start of the conversation to resolve dynamic variables. Gotcha: the webhook response must wrap variables under a top-level dynamic_variables object, e.g. {"dynamic_variables": {"customer_name": "Jane"}}. Returning a flat object will be ignored and variables will fall back to their defaults. See the dynamic variables guide for the full request/response format and timeout behavior.
Timeout in milliseconds for the dynamic variables webhook. Must be between 1 and 10000 ms. If the webhook does not respond within this timeout, the call proceeds with default values. See the dynamic variables guide.
1 <= x <= 10000Map of dynamic variables and their default values
Configuration settings for the assistant's web widget.
Settings for interruptions and how the assistant decides the user has finished speaking. These timings are most relevant when using non turn-taking transcription models. For turn-taking models like deepgram/flux, end-of-turn behavior is controlled by the transcription end-of-turn settings under transcription.settings (eot_threshold, eot_timeout_ms, eager_eot_threshold).
Connected integrations attached to the assistant. The catalog of available integrations is at /ai/integrations; the user's connected integrations are at /ai/integrations/connections. Each item references a catalog integration by integration_id.
Tags associated with the assistant. Tags can also be managed with the assistant tag endpoints.
Human-readable name for the assistant version.
50Configuration for post-conversation processing. When enabled, the assistant receives one additional LLM turn after the conversation ends, allowing it to execute final tool calls such as sending a summary or updating a record via webhook or function tools. Integration and MCP server tools are not available post-conversation; call-control tools (e.g. hangup, transfer) are also unavailable. Beta feature.
Splits the conversation between a frontend model that talks to the caller and a backend model that does the work. On the GPT-Live route the frontend model cannot call tools at all — when it needs something done it raises a delegation and waits. On the chat completion route the frontend keeps a single delegate tool that returns immediately, so the conversation carries on while the backend works. Either way the backend's answer is spoken as commentary or kept as silent context, depending on speak_results. Beta feature.
Streams conversation and telephony events to a WebSocket server you host, and accepts messages injected back into the conversation. Telnyx opens the connection as a client, once per conversation. Delivery is best effort throughout: while the connection is down events are dropped rather than queued, and no socket failure is ever allowed to affect the call. Beta feature.
Conversation flow as supplied by API clients (create / update).
A directed graph of FlowNodeReq connected by FlowEdges. Validation
enforces unique node/edge IDs, that start_node_id references a real
node, and that every edge's endpoints reference real nodes.
Indicates whether the assistant should be promoted to the main version. Defaults to true.
Response
Successful Response
ID of the model to use when external_llm is not set. You can use the Get models API to see available models. If external_llm is provided, the assistant uses external_llm instead of this field. If neither model nor external_llm is provided, Telnyx applies the default model.
System instructions for the assistant. These may be templated with dynamic variables
Identifier for the assistant version returned by version-aware assistant endpoints.
Timestamp when this assistant version was created.
The assistant's tools. Responses merge the assistant's shared Tools Library tools into this array alongside inline tools, each flagged shared: true; inline tools carry shared: false. On update, a sent tools array fully replaces the inline tools only — shared tools stay attached unless tool_ids changes. Each tool type except function, webhook, and client_side_tool allows at most one instance per assistant across both sources.
- FunctionTool
- WebhookTool
- ClientSideTool
- RetrievalTool
- HandoffTool
- HangupTool
- TransferTool
- InviteTool
- SIPReferTool
- DTMFTool
- SendMessageTool
- SkipTurnTool
- PayTool
- UpdateDynamicVariablesTool
MCP servers attached to the assistant. Create MCP servers with /ai/mcp_servers, then reference them by id here.
A2A agents this assistant can delegate to. Tools are not stored here: at the start of every conversation each agent's card is fetched and one tool is derived per skill the card advertises, named a2a_<name>_<skill_id>. The following limits are not enforced when the assistant is saved, and anything past them is dropped when the conversation starts: 64 agents per assistant, 64 skills per card, 128 derived tools per assistant, and a 6 second budget for all card fetches combined. An agent whose card cannot be fetched costs the assistant that capability for the conversation; it does not fail the call.
Text that the assistant will use to start the conversation. This may be templated with dynamic variables. Use an empty string to have the assistant wait for the user to speak first. Use the special value <assistant-speaks-first-with-model-generated-message> to have the assistant generate the greeting based on the system instructions.
This is only needed when using third-party inference providers selected by model. The identifier for an integration secret /v2/integration_secrets that refers to your LLM provider's API key. For bring-your-own endpoint authentication, use external_llm.llm_api_key_ref instead. Warning: Free plans are unlikely to work with this integration.
If telephony is enabled, the assistant will be able to make and receive calls. If messaging is enabled, the assistant will be able to send and receive messages.
telephony, messaging If dynamic_variables_webhook_url is set, Telnyx sends a POST request to this URL at the start of the conversation to resolve dynamic variables. Gotcha: the webhook response must wrap variables under a top-level dynamic_variables object, e.g. {"dynamic_variables": {"customer_name": "Jane"}}. Returning a flat object will be ignored and variables will fall back to their defaults. See the dynamic variables guide for the full request/response format and timeout behavior.
Timeout in milliseconds for the dynamic variables webhook. Must be between 1 and 10000 ms. If the webhook does not respond within this timeout, the call proceeds with default values. See the dynamic variables guide.
1 <= x <= 10000Map of dynamic variables and their values
Configuration settings for the assistant's web widget.
Settings for interruptions and how the assistant decides the user has finished speaking. These timings are most relevant when using non turn-taking transcription models. For turn-taking models like deepgram/flux, end-of-turn behavior is controlled by the transcription end-of-turn settings under transcription.settings (eot_threshold, eot_timeout_ms, eager_eot_threshold).
Connected integrations attached to the assistant. The catalog of available integrations is at /ai/integrations; the user's connected integrations are at /ai/integrations/connections. Each item references a catalog integration by integration_id.
Human-readable name for the assistant version.
50IDs of missions related to this assistant.
Tags associated with the assistant. Tags can also be managed with the assistant tag endpoints.
Configuration for post-conversation processing. When enabled, the assistant receives one additional LLM turn after the conversation ends, allowing it to execute final tool calls such as sending a summary or updating a record via webhook or function tools. Integration and MCP server tools are not available post-conversation; call-control tools (e.g. hangup, transfer) are also unavailable. Beta feature.
Splits the conversation between a frontend model that talks to the caller and a backend model that does the work. On the GPT-Live route the frontend model cannot call tools at all — when it needs something done it raises a delegation and waits. On the chat completion route the frontend keeps a single delegate tool that returns immediately, so the conversation carries on while the backend works. Either way the backend's answer is spoken as commentary or kept as silent context, depending on speak_results. Beta feature.
Streams conversation and telephony events to a WebSocket server you host, and accepts messages injected back into the conversation. Telnyx opens the connection as a client, once per conversation. Delivery is best effort throughout: while the connection is down events are dropped rather than queued, and no socket failure is ever allowed to affect the call. Beta feature.
Conversation flow as returned by the API.