Build / Variables & data

Variables

Variables are how a call remembers. Capture something once and every later step can use it — in what the agent says, in an API call, or in a branch condition.

Using a variable

Write {{ variable_name }} anywhere text is authored. Unknown names render as empty rather than erroring, so a typo shows up as a gap in the sentence.

interpolation

Thanks {{ customer_name }} — I've got your {{ plan }} account open.

Anything the agent speaks can interpolate a variable:
  say / ask prompts, LLM instructions, transfer briefings,
  tool URLs and bodies, and edge conditions.

Where variables come from

Ask steps

The answer to an Ask lands in the variable you name on that step. This is the most common source.

API results

A Call an API step can save fields out of the response — see Save outputs to variables below.

Set variable steps

Compute or hard-code a value mid-call, including from other variables.

Trigger variables

Values posted with an outbound trigger arrive before the call connects.

Built-ins

Always available, no setup: caller_id, to, call_id, agent_name, channel, now, today.

Project variables

Defaults defined once under Variables, seeded into every call.

Saving API results

On a Call an API step, use Save outputs to variables — one name = path per line. Each path is read from the response and stored under that name, so later steps read {{ customer_name }} directly instead of digging through the raw result.

Save outputs to variables

customer_name = data.name
plan          = data.subscription.plan
open_tickets  = data.tickets.count

Values are saved as text, so numbers and true/false read naturally when spoken. Outputs are saved only when the call succeeds — the Failure port is where you handle the rest. If a path is missing from the response, that variable is skipped and the call detail says so.

Variables from an outbound trigger

A trigger turns an event in your system into a phone call. Whatever you post in variables is available from the first word the agent speaks — so the opening line can be specific instead of generic.

fire a trigger

curl -X POST https://api.vlayers.ai/v1/triggers/<token>/call \
  -H 'content-type: application/json' \
  -d '{
    "to": "+14155550100",
    "variables": { "order_id": "A-4471", "eta": "Thursday" }
  }'

The flow can then open with “Calling about order {{ order_id }} — it’s running late, now arriving {{ eta }}.”

🧪

Check it before you call. Run Dry run in the builder and read the conversation: every capture shows up inline (“Saved customer_name”), and an empty {{ }} in a spoken line is immediately obvious. See Testing.

Naming

Use snake_case letters, digits and underscores, starting with a letter — customer_name, not “Customer Name”. Names are case-sensitive, and a variable set later in the call overwrites the earlier value.