#phone_dynamic_variable on transfer_to_number is working? it's not listed on the docs and it automat

1 messages · Page 1 of 1 (latest)

wise raptorBOT
#
AI-generated Answer for sisco4131

Short answer: yes—dynamic-variable transfer destinations are supported, but “phone_dynamic_variable” is not a documented transfer_to_number argument. The supported way is to configure a transfer rule whose destination is a dynamic variable (API types were added as PhoneNumberDynamicVariableTransferDestination and SIPUriDynamicVariableTransferDestination). That’s why you don’t see it in the older tool docs. See the changelog notes. (elevenlabs.io)

What to check for your SIP trunk calls ending:

  • Missing/invalid dynamic variable: Calls will fail if the required dynamic variable isn’t present/resolves to an empty or invalid value; this shows up in Call History as “Missing dynamic variable after agent transfer.” Verify the variable is provided and resolves to a valid E.164 number at runtime. (help.elevenlabs.io)
  • Transfer method with SIP trunks: If you’re using SIP REFER, your trunk must allow REFER. Otherwise the transfer will fail. Try “Conference” transfer or enable REFER on your trunk. (elevenlabs.io)
  • General support: transfer_to_number works with both Twilio numbers and SIP trunks; ensure the destination format is correct (E.164 for phone; SIP URI when using REFER). (elevenlabs.io)

References:

  • Transfer to human (transfer_to_number) tool overview and SIP/Conference constraints. (elevenlabs.io)
  • Dynamic variables guide (how variables are passed/resolved). (elevenlabs.io)
  • Changelog entry introducing dynamic-variable transfer destinations (API types). (elevenlabs.io)
  • Call History errors (how to see why a call ended). (help.elevenlabs.io)

If you want, share the exact error shown in Call History and the variable name/value you’re using, and I can map it to the documented failure modes above.

Sources:
Changelog | ElevenLabs Documentation
Where can I locate the reason for my call failing? – ElevenLabs
Transfer to human | ElevenLabs Documentation
Transfer to human | ElevenLabs Documentation
Transfer to human | ElevenLabs Documentation
Dynamic variables | ElevenLabs Documentation
Changelog | ElevenLabs Documentation
Where can I locate the reason for my call failing? – ElevenLabs

open egret
#

phone number alone works, but with the dynamic variable all we get is this This conversation failed with the following reason:

Failed to generate a response

wise raptorBOT
#
AI-generated Answer for sisco4131

Short answer: There’s no built‑in variable named phone_dynamic_variable in ElevenLabs. The transfer_to_number tool only accepts a transfer_number that matches one of the numbers you configured for the “Transfer to Human” tool, and it must be a valid E.164 phone number (or a SIP URI when using SIP REFER). If your dynamic variable doesn’t resolve exactly to a configured destination, the transfer will fail. (elevenlabs.io)

What to check

  • Confirm you’re using a real dynamic variable you created (for example {{support_number}}), or a system variable like {{system__caller_id}} / {{system__called_number}} where appropriate. Ensure the variable name matches and is being passed via your chosen personalization method. (elevenlabs.io)
  • In the Transfer to Human tool, make sure the resolved value of your variable is:
    • Exactly one of the phone numbers you configured for transfer_to_number, and
    • Properly formatted (E.164 for phone numbers; SIP URI only if using SIP REFER). (elevenlabs.io)
  • If you’re transferring over a SIP trunk:
    • SIP URI transfers require SIP REFER and your trunk must allow REFER; otherwise use a normal phone number with the default Conference transfer. (elevenlabs.io)
  • If you tested through Twilio’s “register call” (non‑native) flow, note that call transfers aren’t supported there. Use native Twilio integration or SIP trunking instead. (elevenlabs.io)
  • Look up the exact failure reason in Calls History; errors like “Missing required dynamic variables …” or “Missing dynamic variable after agent transfer” will be shown in red. (help.elevenlabs.io)

Minimal working setup

  1. Configure Transfer to Human with a specific allowed destination number in E.164. 2) Set transfer_number in the tool call to a dynamic variable placeholder (e.g., {{support_number}}). 3) Pass support_number at conversation start via personalization so it resolves at runtime. 4) Verify that the resolved value equals the configured number. (elevenlabs.io)

Debug tip

  • Use Realtime Monitoring to send a manual transfer_to_number command with a literal number. If that succeeds but the variable version fails, the issue is variable resolution/format or it not matching the allowed list. (elevenlabs.io)

If you share how you’re populating the variable and the Call History error text, I can point to the exact fix from the docs.

open egret
#

this json came from the transfer to number tool in elevenlabs: {
"type": "system",
"name": "transfer_to_number",
"description": "Transfiere la llamada al colaborador encontrado",
"response_timeout_secs": 20,
"disable_interruptions": false,
"force_pre_tool_speech": false,
"assignments": [],
"tool_call_sound": null,
"tool_call_sound_behavior": "auto",
"params": {
"system_tool_type": "transfer_to_number",
"transfers": [
{
"custom_sip_headers": [],
"transfer_destination": {
"type": "phone_dynamic_variable",
"phone_number": "extension"
},
"phone_number": null,
"condition": "TransferToColaborador",
"transfer_type": "conference"
}
],
"enable_client_message": true
},
"dynamic_variables": {
"dynamic_variable_placeholders": {}
}
}

wise raptorBOT
#
AI-generated Answer for sisco4131

Short answer: ElevenLabs does support dynamic-variable transfer destinations, but the JSON shape you pasted isn’t documented.

What is documented

  • Transfer-to-human destinations: documented types are phone and sip_uri; phone numbers must be E.164 and SIP URIs require SIP REFER for transfers to a SIP URI. (elevenlabs.io)
  • Changelog (Nov 5, 2025): adds dynamic-variable transfer destinations for both phone numbers and SIP URIs (“PhoneNumberDynamicVariableTransferDestination” and “SIPUriDynamicVariableTransferDestination”). The exact JSON fields are not shown on the public page. (elevenlabs.io)
  • SIP trunking notes: general SIP setup/limitations are documented; nothing there specifies a “phone_dynamic_variable” schema. (elevenlabs.io)
  • Failure diagnostics: Call History will show specific errors such as “Missing required dynamic variables …” or “Missing dynamic variable after agent transfer.” (help.elevenlabs.io)
  • You can also test a transfer programmatically (known-good E.164 number) via real-time monitoring; the transfer_to_number tool must already be configured. (elevenlabs.io)

Implications for your JSON

  • The docs confirm dynamic-variable destinations exist but do not document the discriminator/type name or field names. I cannot verify that "type": "phone_dynamic_variable" with "phone_number": "extension" is valid.
  • Documented constraints still apply: if your dynamic variable resolves to a short extension (not E.164) or you’re trying to transfer to a SIP URI without transfer_type = "sip_refer", the transfer will fail. Check the Call History error to confirm. (elevenlabs.io)

If you need a definitive schema for dynamic-variable destinations, it isn’t published on the public docs pages yet; the changelog only states the feature exists. (elevenlabs.io)

Sources:
Transfer to human | ElevenLabs Documentation
November 5, 2025 | ElevenLabs Documentation
SIP trunking | ElevenLabs Documentation
Where can I locate the reason for my call failing? – ElevenLabs
Real-time monitoring | ElevenLabs Documentation
Transfer to human | ElevenLabs Documentation
November 5, 2025 | ElevenLabs Documentation

open egret
#

can you provide me then a json for a variable called extension? or a fixed version of mine?