{{name}}. Runtime callers set values (via the API payload, the chat UI, or a schedule). Variables give one place to declare inputs and one place to interpolate them.
Commands
Variable name is a positional argument, e.g.
topic, customer_email.
vars list
--json for structured output.
vars set
Flags
Only the flags you pass update the existing variable — a set is a shallow merge, not a replace. To reset a field, delete and re-create the variable.
Sources explained
form— surfaced in the chat trigger’s form UI. User fills it in.body_path— extracted from the request body at a JSON path (webhook and API triggers). Use--pathto specify.fixed— hard-coded. Same value every run. Useful for constants and feature flags.
vars delete
{{customer_email}} will fail at run time — audit those first.
Common recipes
Declare a required user input
Extract from a webhook body
If your webhook posts{ "customer": { "email": "..." } }:
{{customer_email}} and see the extracted value.
A feature-flag switch
vars set --fixed-value true when you’re ready. No block edits, no republish (settings-scope changes are live immediately).
Bulk snapshot & restore
Becausevars list --json is structured, you can persist vars in git and re-apply on another workspace:
flows snapshot/apply carries variables along.
Where variables show up
- Block content — anywhere a text field accepts
{{name}}interpolation. - Trigger inputs — webhook
input_pathmaps into a variable; API triggers accept them. - Chat form UI —
--source formvariables render as fields at run start. - Schedule triggers —
--source fixedvalues are baked into every scheduled run.
Variable and version scope
Variables belong to the Flow (draft + published together). Renaming a variable is a Draft edit — publish to make it live.--fixed-value changes take effect immediately without republishing.