Variables reference
The {{ }} syntax that moves data between nodes: {{message}}, {{node_id.field}}, where variables work, and how to discover what each node exposes.
Variables are how data travels through a flow's configuration: anywhere you can type text, {{ }} interpolates values from earlier in the execution.
The syntax
| Pattern | Resolves to |
|---|---|
{{message}} | The incoming message of a chat input — the most common variable in agent flows. |
{{node_id.field}} | A field from the output of the node whose Node ID is node_id. |
{{node_id}} | The whole output of that node (useful when it's a single value or you want the raw object). |
node_id is the identifier in the node's Edit Node → Node ID — not its display name. Rename IDs to something meaningful (leads_db, classifier) and your variables become self-documenting.
Where variables work
Everywhere configuration accepts text, including:
- LLM Agent — prompt and objective (
Answer using: {{context_db}}) - HTTP Request — URL, headers and body
- Transformer — every field of the JSON you're building
- Conditional Flow / Filter — the values being compared
- Email — subject and body templates
- PDF Generator / HTML View — template placeholders
Discovering a node's fields
The authoritative way to know what a node exposes: run the flow once and open the node's Console — the output panel shows the exact object, with the field names you can reference. For example, if an HTTP Request with ID api_call returns { "data": { "price": 42 } }, then {{api_call.data.price}} resolves to 42.
Debugging variables
- Empty value? Check three things: the source node actually ran (Console), the Node ID matches exactly, and the field path exists in the output.
- Whole object printed? You referenced
{{node}}where you wanted{{node.field}}. - Test cheaply: wire a Transformer that just echoes
{{your_variable}}and run — faster than re-running the full pipeline.