Dynamic variables let you personalise a call at runtime. Anywhere you can write text in your agent — a prompt, a welcome message, a transition line, an SMS body, a tool parameter — you can drop a {{ variable_name }} placeholder, and Peachdesk substitutes the value before the text reaches the LLM or the outside world. Dynamic variables are the same data referred to as initial_context: values you pass in when a call starts, plus a set of built-in variables Peachdesk resolves for you. They work identically for single-prompt agents and conversational-flow agents.

​
Syntax

Wrap a variable name in double braces. Surrounding whitespace is trimmed, so {{name}} and {{ name }} are equivalent.

​
Fallback values

If a variable may be missing or empty, provide a default after a pipe (|). When the variable is unset or empty, the fallback is used; otherwise the actual value wins.
When customer_name is not set, the agent says “Hello there”. The syntax is:
A legacy form, {{ variable_name | fallback:default_value }}, is also accepted and behaves the same way. New agents should use the shorter {{ var | default }} form.

​
Nested paths

Variables can be nested objects. Reach into them with dot-paths. If the context is:
then you can write:
Top-level keys you pass are also available without the initial_context. prefix — {{ customer_name }} and {{ initial_context.customer_name }} resolve to the same value. A path that doesn’t exist renders as an empty string (unless a fallback is supplied).

​
Passing dynamic variables via the API

Both call-trigger endpoints accept a flat string map of variables that merge into the run’s initial_context: Use the dynamic_variables field.
The initial_context field on the trigger endpoints accepts the same data and is fully supported. dynamic_variables is a flat string map that merges into the same initial_context, so you can use whichever fits your integration.
The variables you pass are echoed back on the outbound event webhook as call.dynamic_variables, so a receiver can see exactly which values drove a given call.

​
Other sources

Dynamic variables also arrive automatically from:
  • Campaign CSV — every column beyond to_number (the legacy phone_number column is also accepted) becomes a per-contact variable for that contact’s call. See Campaigns.
  • Inbound telephony — the caller and called numbers are seeded as built-in variables.
  • Website embed — values passed by the web widget.

​
Where dynamic variables can be used

Rendering happens everywhere text is produced or sent, for both single-prompt and conversational-flow agents:

​
Built-in variables

These variables are resolved automatically during the session — no configuration and no initial_context needed. They mirror Retell’s default system variables and fall into groups.

​
Time and date

​
Session

​
Call and chat identity

Replace <TZ> with a name such as Asia/Kolkata, America/New_York, or Europe/London.
When you use a timezone suffix on any of current_time, current_weekday, current_hour, or current_calendar, the others without a suffix inherit the same timezone instead of UTC. For example, if a prompt contains both {{ current_time_Asia/Kolkata }} and {{ current_weekday }}, the weekday is also resolved in Asia/Kolkata.

​
Post-conversation and contact variables

Two further Retell-style groups exist but are not live prompt variables — they are not known while the agent is speaking:
  • Post-conversation — call_summary / chat_summary, call_successful / chat_successful, user_sentiment, disconnection_reason, call_status / chat_status. These are produced after the session ends and are available on the call webhooks (in call_analysis) and through post-call extraction, not inside the prompt.
  • Contact — first_name, last_name, do_not_call, plus any custom contact fields. Supply these through initial_context / dynamic_variables or a campaign CSV column to reference them in the prompt.
For inbound calls, from_number / user_number is the customer and to_number / agent_number is your Peachdesk number. For outbound calls it is reversed.

​
Previous-call context (returning callers)

When you enable pre-call context on an agent, a caller you have spoken to before starts their next call with context from their earlier call(s), instead of the agent starting cold — useful for a dropped call, a reschedule, or a callback. When it is on and a match is found, these variables are seeded before the prompt renders, so your prompt and greeting can use them: A value you pass explicitly for the current call always wins — pre-call context never overwrites a variable you supplied. When the feature is off, no match is found, or the lookup cannot run, is_returning_caller is false and the call starts fresh. Enable it on the agent’s configuration:
Matching is on the caller’s phone number by default, or on their saved contact ("match_by": "contact_id"), drawing from this agent’s finished calls within your organization; it applies to single-prompt and conversational-flow agents on both voice and chat. The context reuses the analysis produced by post-call extraction on the earlier calls. Every control, the webhook and LLM-brief options, and how to test it from the editor are on Pre-Call Context.

​
Using dynamic variables for testing

Variables defined in your workflow Settings > Context Variables are included in test calls (both web and phone) made from the workflow editor. This is useful for simulating data that would normally come from telephony or an API trigger. For example, set caller_number and called_number as context variables to test Pre-Call Data Fetch without a real inbound call.
These context variables are only used during test calls from the workflow editor. On production inbound calls and campaign outbound calls, the actual telephony data is used and these values are ignored.