#Is ElevenLabs Conversational AI, Widget, Fetch initiation client data from webhook working?I am t
1 messages · Page 1 of 1 (latest)
Short answer: Yes—Inbound Twilio calls can fetch “conversation initiation client data” via a pre-call webhook, and that data is attached to the conversation record. If you don’t see anything in the Client Data tab, it usually means the webhook wasn’t enabled, didn’t return the expected payload, or timed out. The documentation confirms the feature and shows how to verify it.
What the docs confirm
- Inbound Twilio calls can fetch initiation data during the dialing period by calling your webhook, which must return conversation_initiation_client_data. You must also enable this feature in the agent’s Security tab. (elevenlabs.io)
- The webhook receives caller_id, agent_id, called_number, and call_sid, and should respond with a JSON body whose type is conversation_initiation_client_data. The dynamic_variables field must include values for all dynamic variables you defined; overrides are optional. Ensure the webhook responds promptly. (elevenlabs.io)
- You can confirm whether the data was attached by calling Get conversation details; the response includes conversation_initiation_client_data if it was received. (elevenlabs.io)
- As another verification path, enable Post-call (transcription) webhooks; the payload includes conversation_initiation_client_data (and, since Aug 15, 2025, has_audio flags to match the GET Conversation format). (elevenlabs.io)
- For the website widget (separate from Twilio), you can pass the same conversation_initiation_client_data at session start over the WebSocket/SDK, or use dynamic variables/overrides in the Widget config. (elevenlabs.io)
Common reasons the Client Data section is empty (per docs-driven checks)
- Feature not enabled: Ensure “Enable fetching conversation initiation data” is toggled in the agent’s Security tab. (elevenlabs.io)
- Payload shape incorrect: Your webhook must
This is the response from the webhook
{
"type":
"conversation_initiation_client_data",
"dynamic_variables":
{
"caller_phone":
"+44789789789",
"name":
"John",
"possible_pickup_locations":
[
"Manchester, M4 3AJ",
"Manchester, UK, M41 5SL"
],
"possible_destination_locations":
[
"Manchester, M23 9LT",
],
"probable_accounts":
[
{
"name":
"official",
"code":
"123456789"
}
],
"booking_preference":
"Usually ASAP"
},
"conversation_config_override":
{
"agent":
{
"first_message":
"Hi John! How can I help you today?"
}
}
}
Short answer: your payload shape is correct for inbound Twilio “conversation initiation client data,” but it will only be ingested and surfaced if a few required settings are enabled and the JSON is strictly valid.
What the docs say
- Expected payload: type must be conversation_initiation_client_data with optional conversation_config_override and dynamic_variables. Your structure matches the documented schema. (elevenlabs.io)
- Twilio flow: you must 1) configure the webhook URL in Settings, 2) enable “Fetch conversation initiation data” in the agent’s Security tab, and 3) return the JSON from your webhook. If this isn’t enabled, the data won’t be applied. (elevenlabs.io)
- JSON must be valid: “Your webhook must return a JSON response.” Trailing commas or invalid JSON will cause the platform to ignore the payload. (elevenlabs.io)
- Dynamic variables: the dynamic_variables object must provide values for the variables you defined in the agent. If you haven’t defined those variables in prompts/tools, there’s nothing to populate. (elevenlabs.io)
- Overrides: first_message (and other override fields) must be explicitly permitted in the agent’s Security settings; otherwise the platform rejects the override. (elevenlabs.io)
- Verification: the GET Conversation API includes conversation_initiation_client_data when the payload was accepted. If that field is absent/null, the webhook data wasn’t applied. (elevenlabs.io)
Why your “Client Data” view may be empty
- The agent’s Security setting for “fetch initiation data” isn’t enabled, or overrides aren’t permitted. (elevenlabs.io)
- The webhook response isn’t strictly valid JSON (the snippet you pasted has trailing commas). The platform requires valid JSON. (elevenlabs.io)
- The variables in dynamic_variables aren’t defined in the agent, so nothing is populated. (elevenlabs.io)
- The webhook timed out; calls proceed without personalization if the response isn’t returned promptly. (elevenlabs.io)
Next steps to confirm
- In the agent UI: enable “Fetch conversation initiation data” and allow the specific override fields you intend to use (e.g., First message). (elevenlabs.io)
- Fix JSON (no trailing commas) and return Content-Type: application/json. (elevenlabs.io)
- Define the dynamic variables (e.g., name, possible_pickup_locations) in your agent’s prompts/tools. (elevenlabs.io)
- Make a test call, then GET /v1/
I found the issue now..
possible_pickup_locations is an array of strings. Is this a valid format?
Short answer: No. Dynamic variables only support primitive types (string, number, boolean). Arrays (e.g., ["Manchester, M4 3AJ", ...]) are not a valid value type for dynamic_variables. See “Supported Types” in Dynamic variables. (elevenlabs.io)
For Twilio webhook personalization, the example responses likewise show only primitive values in dynamic_variables. (elevenlabs.io)
If you need to work with lists, the docs indicate you must map them to supported primitive values (e.g., via tool logic that extracts a single value into a variable), not store arrays directly in dynamic_variables. (elevenlabs.io)
Sources:
Dynamic variables | ElevenLabs Documentation
Twilio personalization | ElevenLabs Documentation
Dynamic variables | ElevenLabs Documentation
Got it.
What is the maximum number of dynamic variables that can be present in an Agent?
What is the maximum size of the data that can be help within a dynamic variable?