Template strings allow you to dynamically inject data from previous nodes, variables, or the environment into any configuration field. They are evaluated at runtime by the Automation Engine before the node executes.

Syntax

Template strings use double curly braces: {{path.to.value}}

Reference Types

1. Trigger Data

Access data produced by the trigger node:

{{trigger.data.fieldName}}
{{trigger.fieldName}}

Examples:

{{trigger.data.message.content}}    → The text of a Discord message
{{trigger.data.author.username}}    → The username of the message author

2. Node Outputs (Recommended)

Access outputs from any previously executed upstream node by its node ID:

{{outputs.nodeId.path}}
{{output.nodeId.path}}

Both outputs and output are supported for convenience.

Examples:

{{outputs.ai_node_1.response}}         → The AI's generated response
{{output.http_request_1.body.email}}   → A field from an API response body

3. Variables

Access variables stored by a Set Variable node during the current execution:

{{vars.variableName}}
{{variables.variableName}}

Example:

{{vars.userEmail}}
{{vars.orderTotal}}

4. Environment Variables

Access environment variables injected into the bot's deployment:

{{env.VARIABLE_NAME}}

Example:

{{env.API_BASE_URL}}

5. Legacy Syntax (Backward Compatible)

Older node output syntax is still supported:

{{nodes.nodeId.output.path}}

The @nodeId shorthand ({{@trigger-mute.interaction.id}}) is deprecated. The engine resolves it as an alias for outputs, but Studio and docs use {{outputs.nodeId.path}} only — always author that form in new graphs and agent-generated configs.

Practical Example

In a Discord bot that responds to messages with an AI-generated reply:

{
  "nodeId": "send_message",
  "config": {
    "channelId": "{{outputs.trigger.message.channelId}}",
    "content": "{{outputs.openrouter_ai.response}}"
  }
}

Error Handling

If a template string cannot be resolved at runtime, the original literal string is returned (no crash occurs).
Enable LOG_LEVEL=debug in your bot's deployment environment variables to see detailed template resolution logs.
The engine provides helpful suggestions in the log stream when templates fail to resolve.

Best Practices

Prefer {{outputs.nodeId.field}} over the legacy {{nodes.nodeId.output.field}} syntax — it is shorter and easier to read.
Use {{trigger.data.field}} when referencing the initial trigger payload.
Use Set Variable nodes to store computed values that multiple downstream nodes need — then reference them with {{vars.name}} instead of chaining long output paths.
Check the Node Config Sidebar's output schema preview to see exactly what fields a node produces before writing template strings.

Supported: field paths such as {{outputs.parse-cmd.result}} and {{outputs.trigger-mute.interaction.id}}.

Array elements (database read data arrays, etc.):

{{outputs.read-user-xp.data.0.xp}}
{{outputs.read-user-xp.data.[0].xp}}

Both data.0.xp and data.[0].xp resolve to the first row. Prefer {{outputs.read-user-xp.count}} for “does a row exist?” checks in If Condition (e.g. count gt 0).

If Condition and zero: 0 is a valid left/right value (e.g. count eq 0). Only blank strings and null/undefined count as “missing”.

Not supported (do not use in node config):

JavaScript-style method calls: .replaceFirst(), .split(), .match()
Expressions inside templates: Math.floor(...), ||, + between two references (use math_numbers nodes instead)
Building JSON arrays in template strings with #each over ticket blobs

For string trim/split/replace, add a string_operations node. For ticket lists and persistence, use narakim_database (operation: create | read | update | delete | count, model: table name).

Was this helpful?

historyLast updated: May 10, 2026

Template Strings