Master n8n Expression Syntax for Dynamic Workflows
n8n expression syntax guide: correct {{ }} usage, core variables, and the webhook-data-is-under-.body gotcha.
Why it matters
Become an expert in n8n's expression syntax to dynamically reference data from various nodes, including JSON payloads, webhook bodies, and environment variables. This skill ensures your n8n workflows correctly parse and utilize data for seamless automation.
Outcomes
What it gets done
Write and debug n8n expressions using `{{...}}` syntax.
Access and manipulate data from `$json`, `$node`, and `$env` variables.
Correctly parse webhook payloads, especially nested `body` data.
Dynamically insert values into n8n node parameters and build complex data structures.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-n8n-expression-syntax | bash Overview
n8n Expression Syntax
An n8n expression syntax reference covering core variables, the webhook .body data gotcha, validation rules, data-type handling, and where expressions cannot be used, such as Code nodes. Use when writing or debugging n8n node expressions, especially after a webhook integration returns undefined values or an expression renders as literal text.
What it does
n8n Expression Syntax is an expert reference for writing and debugging n8n workflow expressions, which use double-curly-brace {{ ... }} syntax to insert dynamic values into node parameters.
When to use - and when NOT to
Use this when writing or debugging n8n expressions, working with $json, $node, webhook payloads, or expression-related workflow errors, and needing syntax-correct dynamic values inside n8n nodes and parameters. It flags specific places expressions should NOT be used: Code nodes use direct JavaScript access instead ($json.email, not '={{$json.email}}'), webhook paths must be static strings, and credential fields should go through n8n's credential system rather than an expression.
Inputs and outputs
Core variables: $json for the current node's output ({{$json.fieldName}}, bracket notation for spaces, array/nested access), $node["Node Name"].json... to reference any previous node by its exact, case-sensitive, quoted name, $now for the current timestamp with Luxon formatting such as .toFormat('yyyy-MM-dd') and .plus({days: 7}), and $env for environment variables. The single most common mistake it calls out: webhook data is not at the root of $json - the Webhook node wraps incoming form/body data under a .body property alongside headers, params, and query, so {{$json.name}} is wrong and {{$json.body.name}} is correct. Four core validation rules: always wrap expressions in {{ }}, use bracket notation for field or node names containing spaces ({{$json['field name']}}, {{$node["HTTP Request"].json}}), match node names exactly including case, and never nest braces - {{{$json.field}}} is invalid. It also documents data-type handling for arrays (.length, index access), objects (dot vs bracket notation), strings (concatenation, .toLowerCase()), and numbers (inline math), plus advanced patterns like ternary conditionals, default values with ||, and Luxon date manipulation via .plus(), .minus(), and DateTime.fromISO(). A dedicated helper-method reference groups the available methods by type: string methods like .toLowerCase(), .trim(), .replace(), .substring(), and .split(); array methods like .length, .map(), .filter(), .find(), and .join(); DateTime (Luxon) methods like .toFormat(), .toISO(), .plus(), and .minus(); and number methods like .toFixed() plus standard math operators.
Integrations
Debugging goes through n8n's built-in expression editor (the "fx" icon), which live-previews the evaluated result and highlights errors; common error messages covered include "Cannot read property 'X' of undefined" (a missing parent object - check the data path) and an expression rendering as literal text (missing {{ }}). It cross-references two companion docs, COMMON_MISTAKES.md and EXAMPLES.md, and names three related skills: n8n MCP Tools Expert for validating expressions via MCP tools, n8n Workflow Patterns for expressions in real workflows, and n8n Node Configuration for when expressions are actually needed.
Who it's for
n8n workflow builders who need exact expression syntax - especially anyone debugging a webhook integration where data silently lives under .body, or moving logic between expression-based nodes and Code nodes, which use plain JavaScript instead of {{ }} syntax.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.