i want to pass dynamic variable for my agent in the backend side (like that the client of my SaaS d

[neon phoenix]

AI-generated Answer for pnl_maker

Short answer: Yes—use Dynamic Variables and initiate the conversation from your backend. Keep the agent private (signed URL or WebRTC token), and if a value must never go into the LLM prompt, use Secret Dynamic Variables.

How to do it (backend-safe):

• Template your agent prompt with variables
  • In the agent’s System prompt and/or First message, insert placeholders like {{customer_name}} or {{plan_tier}}. (elevenlabs.io)
• Pass dynamic_variables from your server at session start
  • Send conversation_initiation_client_data that includes dynamic_variables when the session is initiated. This can be done:
    • Via the WebSocket “conversation_initiation_client_data” message (contains dynamic_variables and optional conversation_config_override). (elevenlabs.io)
    • Or via the SDK server-side (e.g., ConversationInitiationData in Python). (elevenlabs.io)
• Keep the client from seeing your values
  • Make the agent private and require auth; from your backend, issue a Signed URL (WebSocket) or a WebRTC conversation token, then let the browser connect with that token/URL. Do not expose your API key. (elevenlabs.io)
  • If you must include truly sensitive values (e.g., auth tokens for tools), prefix them as secret__... so they are only available for tool headers and are never sent to the LLM as part of the prompt or first message. (elevenlabs.io)
• If you need to change the prompt per user
  • You can optionally enable “Overrides” (in the agent’s Security settings) and send a conversation_config_override from your backend; if overrides aren’t enabled, the platform will reject prompt overrides. Prefer Dynamic Variables for most personalization. (elevenlabs.io)

Notes and pitfalls:

• Don’t pass sensitive variables via the public Talk-to URL (vars= or var_ parameters); use backend injection instead. (elevenlabs.io)
• For phone calls, you can fetch dynamic variables (and overrides) just-in-time from your backend via the Twilio personalization webhook flow, keeping everything server-side. (elevenlabs.io)

Key docs:

• Dynamic Variables (including secret__ variables) and runtime passing. (elevenlabs.io)
• Conversation initiation payload over WebSocket (dynamic_variables and overrides). (elevenlabs.io)
• Authentication (Signed URLs, allowlists) and SDK examples for private agents. (elevenlabs.io)
• Overrides (when you need to fully replace the prompt/first message). (elevenlabs.io)
• Twilio personalization (server webhook supplies dynamic_variables).

[vivid citrus]

ty but for all this variable i need to sens the information to the client, do you have a alternatif where te var don't go in the client side ?

[neon phoenix]

AI-generated Answer for pnl_maker

Yes. You can keep runtime variables off the client entirely. Supported options in ElevenLabs:

• Use signed URLs so the client never sees your API key. Your backend calls GET /v1/convai/conversation/get-signed-url (with your agent_id) and returns only the signed WebSocket URL to the browser. The signed URL expires after 15 minutes.

• Provide conversation init data from your server, not the browser:

  • Phone/Twilio: enable “fetch conversation initiation data” and have ElevenLabs call your webhook at call start. Your webhook returns conversation_initiation_client_data with dynamic_variables and/or overrides; nothing sensitive is ever sent from the client. You can attach secrets via headers using the platform’s webhook settings.
  • Web apps: start the Agents WebSocket from your backend and send the first message as type=conversation_initiation_client_data (includes dynamic_variables and overrides). Your frontend connects only to your backend; it never sees those values. See the Agent WebSocket message schema.

• If you must pass sensitive tokens for tool calls, mark them as secret dynamic variables by prefixing with secret__. These are available to tools (e.g., in request headers) but are not sent to the LLM in prompts. Tools can also update dynamic variables at runtime so you can fetch server-side data only when needed.

• Optional hardening: combine signed URLs with domain allowlists to restrict which origins can start sessions.

These patterns let you personalize each session while keeping prompts/vars on the server side and out of your customers’ browsers.

[vivid citrus]

i did this:

    const response = await fetch(
      `https://api.elevenlabs.io/v1/convai/conversation/get-signed-url?agent_id=${agentId}`,
      {
        method: "GET",
        headers: {
          "xi-api-key": env.ELEVENLABS_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          dynamic_variables: {
            test_variable: "TEST",
          },
        }),
      },
    );
    const data = await response.json();

but i have a erreur 500