Expressions and filters

Ingestly templates pull data from earlier nodes into the configuration of later ones. Wherever you see a field that accepts {{ ... }} (callback URL, HTTP body, email subject, transform output, validation rule), you can reference an upstream value, index into arrays, transform it with filters, or insert a built-in helper.

Basic syntax

A template expression has three parts: a path, optional filters, and the surrounding {{ }} markers.

{{ path | filter | filter }}

The path locates the value. Filters transform it left to right. The result replaces the whole {{ ... }} token.

Path

A path is a dotted identifier, optionally with array indices.

Form	What it resolves to
`{{nodeName}}`	The full output of the named upstream node, as JSON
`{{nodeName.payload.field}}`	A field inside that node’s output
`{{nodeName.payload.items[0].sku}}`	The first element of an array, then a field inside it
`{{nodeName.payload.items[-1]}}`	The last element of an array (negative index counts from the end)
`{{nodeName.payload.items.sku}}`	Every `sku` across the array: a pluck, which resolves to a list

The first segment of every path must be the name of an upstream node (or a built-in placeholder or helper, see below). Subsequent segments index into that node’s output, which has the shape { success, payload, metadata, error }. Paths are case sensitive and may use letters, digits, and underscores.

Reading across an array

Naming a property on an array plucks it: the path resolves to the list of that property’s values, not to one of them.

{{extract.payload.lines.total}}     one list of every line's total
{{extract.payload.lines[0].total}}  the first line's total, a single number
{{extract.payload.lines[-1].total}} the last line's total

A pluck is an array even when each value in it is a number or a string. Binding {{extract.payload.lines.total}} to a field that expects a single value is a type mismatch, and the editor flags it. Add an index to pick one, or use an array filter such as sum to fold the list into one value.

Every part of Ingestly that resolves a reference (templates, edge conditions, validation rules, field mappings, connector write-back) uses this one grammar, so a path that works in one place works in all of them. The [] notation you see in the data picker marks “this crosses an array” for display, and is not something you type: write a real index like [0], or leave the segment out to pluck.

Each node in the editor has a Name field. Default names are auto-assigned (extract, extract2, vars, etc.) but you can rename a node to anything that’s unique within the workflow. Whatever name you pick is the identifier used at the head of every template expression.

Built-in placeholders

These resolve from the run context:

Placeholder	Value
`{{documentId}}`	The current document’s ID
`{{organizationId}}`	The owning organization’s ID
`{{workflowId}}`	The current workflow’s ID
`{{nodeId}}`	The current node’s ID

Source document file

The $document head resolves from the run’s source document: the original file that triggered the run, whether it was uploaded or emailed. It is a global head, valid in any template field, because a workflow can have several triggers but only one fires per run.

Path	Value
`{{$document.file.name}}`	The original file name (falls back to `document` plus the extension)
`{{$document.file.contentType}}`	The MIME content type, for example `application/pdf`
`{{$document.file.size}}`	The file size in bytes
`{{$document.file.extension}}`	The file extension, including the leading dot, for example `.pdf`
`{{$document.file.base64}}`	The raw file bytes, Base64-encoded

The metadata paths (name, contentType, size, extension) are always cheap to resolve. base64 is different: the file bytes are fetched and encoded lazily, only when a template actually references {{$document.file.base64}}, and they are never persisted. The encoded value never enters run output, step history, or the live preview. Anywhere it would otherwise appear, Ingestly shows a [binary N bytes, type] placeholder instead. Use {{$document.file.base64}} to send the source file as a binary body on a callback or HTTP node, or to attach it to a record.

A node name can never start with $, so a reserved head like $document, $input, $writeback, $item or $index never collides with a node you have named document, input, writeback, item or index. Nothing is reserved without the $ prefix, so a node may legitimately be named input, writeback, inputJson, item or index.

The live input

The $input head resolves to the node that actually delivered this node’s input: the single wired predecessor whose connection fired on this run. It exists so a template never has to name a branch. Consider a Reconcile that routes matched rows straight on and mismatched rows through a Review:

reconcile --matched--> businessCentral
review  --approved--> businessCentral

Only one of those two connections fires on any given run. Writing {{reconcile.payload.lines}} in the Business Central node would be wrong on a mismatch run, and {{review.payload.lines}} would be wrong on a matched one. {{$input.payload.lines}} is right on both:

Path	Resolves to
`{{$input}}`	The whole output envelope of the branch that fired
`{{$input.payload}}`	That node’s payload
`{{$input.payload.lines}}`	Any path inside it, exactly as if you had named the node

Before $input, an either-or join like this needed a Merge node to pick a source. It no longer does. Merge still earns its place when several inputs genuinely arrive together, which is what its Key Match, Zip and Concat modes are for.

$input answers “the previous node”, so it needs exactly one answer. When two connections into the same node can both fire on the same run, Ingestly refuses to activate the workflow and names both branches, so you find out at save time rather than part-way through a document. A run that reaches the same ambiguity fails with the same error rather than silently picking one. Name the node you want, or route the branches through a Merge.

Inside a Loop container, $input follows the same rule against the container’s own nodes: it resolves to the previous node in the body, for the item being processed. The first node in a body has no previous node (its input is the loop item itself, read as {{<loop node name>.payload.item}}), so $input has no answer there. The builder warns you when a node uses $input where nothing can ever deliver it, and inside a loop body it names the loop item path to use instead. That warning does not block you from saving. Autocomplete offers the fields beneath $input, not only the head itself. Because the shape depends on which branch fires, it suggests the paths that every branch which could deliver has in common, so a field only one branch declares is not suggested even though it resolves on that branch. You can still type such a path: a path is accepted when any branch that could deliver has it, and only a path no branch has at all is flagged. A field whose type differs between branches is offered without a type, so type-aware filtering does not narrow it. The head is offered only where it has exactly one possible answer. On a node where two connections can both deliver, $input does not appear in autocomplete at all, which is the same rule the save-time check enforces. A related gap affects $each: looping with $each over {{$input.payload.lines}} gets no {{$item.*}} column autocomplete and no item-column validation. It degrades safely - item paths stay unchecked rather than falsely flagged - and it is still the only correct choice when the branch’s shape isn’t known up front, but an author switching an $each from a named node to $input will notice the loss and should expect it.

Built-in helpers

These produce a value at the time the template is evaluated.

Helper	Returns
`{{now}}`	Current UTC datetime as ISO 8601 (`yyyy-MM-ddTHH:mm:ssZ`)
`{{today}}`	Current UTC date (`yyyy-MM-dd`)
`{{nowUnix}}`	Current Unix epoch seconds
`{{uuid}}`	A new UUID v7 (time-ordered)

You can chain filters onto helpers: {{now | formatDate: 'yyyy-MM-dd'}}.

Filters

Add a filter with the pipe character: {{ value | filter }}. Filters with arguments use a colon: {{ value | filter: 'arg1', 'arg2' }}. You can chain as many filters as you need, applied left to right.

Filter arguments

Each argument is one of:

Form	Example	Notes
Number literal	`{{count \| add: 5}}`	`-3.14`, `1e6`, etc.
Quoted string	`{{name \| concat: '!'}}`	Single or double quotes
`true`, `false`, `null`	`{{value \| default: null}}`	Bare keywords
Path reference	`{{payload.terms \| div: payload.divisor}}`	Resolved against the same upstream context as the head expression

Path references must satisfy the same shape as the head path (identifier(.identifier|[N])*). The runtime resolves them at filter-application time, so they can reference upstream node fields (extract.payload.divisor), built-in helpers ({{end | dateDiff: 'days', start}}), or array elements ({{items[0] | concat: items[1]}}). If the path resolves to a type that doesn’t match what the filter expects (e.g., div argument resolves to a string), the editor flags it before the run starts.

String filters

Filter	Example	Result
`upper`	`{{name \| upper}}`	`ALICE`
`lower`	`{{name \| lower}}`	`alice`
`trim`	`{{ ' alice ' \| trim}}`	`alice`
`replace: 'from', 'to'`	`{{name \| replace: 'a', '@'}}`	`@lice`
`substring: start, length?`	`{{name \| substring: 0, 3}}`	`Ali`
`truncate: maxLength, postfix?`	`{{title \| truncate: 8, '...'}}`	`Invoi...`
`split: separator`	`{{tags \| split: ','}}`	`["a","b","c"]`
`concat: 'suffix'`	`{{name \| concat: '!'}}`	`Alice!`
`contains: 'needle'`	`{{name \| contains: 'lic'}}`	`true`
`startsWith: 'prefix'`	`{{name \| startsWith: 'Al'}}`	`true`
`endsWith: 'suffix'`	`{{name \| endsWith: 'ce'}}`	`true`
`padStart: length, pad?`	`{{code \| padStart: 5, '0'}}`	`00042`
`padEnd: length, pad?`	`{{code \| padEnd: 5, '0'}}`	`42000`
`capitalize`	`{{name \| capitalize}}`	`Alice`
`camelCase`	`{{'order id' \| camelCase}}`	`orderId`
`kebabCase`	`{{'Order Id' \| kebabCase}}`	`order-id`
`snakeCase`	`{{'Order Id' \| snakeCase}}`	`order_id`

truncate counts the postfix toward the limit; padStart and padEnd pad with a space when no pad string is given.

Number filters

Filter	Example	Result
`round: digits?`	`{{3.14159 \| round: 2}}`	`3.14`
`ceil`	`{{3.2 \| ceil}}`	`4`
`floor`	`{{3.8 \| floor}}`	`3`
`abs`	`{{-5 \| abs}}`	`5`
`add: n`	`{{5 \| add: 3}}`	`8`
`sub: n`	`{{5 \| sub: 3}}`	`2`
`mul: n`	`{{5 \| mul: 3}}`	`15`
`div: n`	`{{6 \| div: 3}}`	`2`

Format filters

Turn a raw number into a display string.

Filter	Example	Result
`formatNumber: decimals, culture?`	`{{amount \| formatNumber: 2}}`	`1,234.50`
`formatCurrency: 'code', decimals?, culture?`	`{{amount \| formatCurrency: 'USD'}}`	`$1,234.50`

formatCurrency takes an ISO 4217 currency code (for example USD, EUR, GBP) and pins the currency symbol from that code.

Array filters

Filter	Example
`length`	`{{items \| length}}`
`first`	`{{items \| first}}`
`last`	`{{items \| last}}`
`join: separator`	`{{tags \| join: ', '}}`
`sum`	`{{prices \| sum}}`
`avg`	`{{prices \| avg}}`
`min`	`{{prices \| min}}`
`max`	`{{prices \| max}}`
`unique`	`{{tags \| unique}}`
`sort`	`{{prices \| sort}}`
`reverse`	`{{items \| reverse}}`
`slice: start, end?`	`{{items \| slice: 0, 3}}`
`groupBy: 'key'`	`{{lineItems \| groupBy: 'category'}}`

slice uses Python-style bounds (negative indices count from the end). groupBy groups an array of objects by the string value at key, returning an array of { key, items } groups. reverse also reverses a string’s characters.

Date filters

Operate on ISO 8601 strings (or anything that can be parsed as one). The add/subtract and start/end filters return an ISO 8601 UTC string.

Filter	Example	Result
`formatDate: '...'`	`{{now \| formatDate: 'yyyy-MM-dd'}}`	`2026-04-28`
`addDays: n`	`{{today \| addDays: 7}}`	`2026-05-05T00:00:00Z`
`subDays: n`	`{{today \| subDays: 1}}`	`2026-04-27T00:00:00Z`
`addHours: n`	`{{now \| addHours: 6}}`	shifted ISO datetime
`addMinutes: n`	`{{now \| addMinutes: 90}}`	shifted ISO datetime
`addMonths: n`	`{{today \| addMonths: 1}}`	shifted ISO datetime
`addYears: n`	`{{today \| addYears: 1}}`	shifted ISO datetime
`startOfDay`	`{{now \| startOfDay}}`	`2026-04-28T00:00:00Z`
`endOfDay`	`{{now \| endOfDay}}`	`2026-04-28T23:59:59Z`
`startOfMonth`	`{{now \| startOfMonth}}`	first day of the month
`endOfMonth`	`{{now \| endOfMonth}}`	last day of the month
`dayOfWeek`	`{{now \| dayOfWeek}}`	`Tuesday`
`toUnix`	`{{now \| toUnix}}`	epoch seconds
`fromUnix`	`{{ts \| fromUnix}}`	ISO datetime
`toIso`	`{{rawDate \| toIso}}`	canonical ISO 8601 UTC
`dateDiff: unit, otherDate`	`{{end \| dateDiff: 'days', '{{start}}'}}`	`5`

formatDate uses .NET-style format strings. Common patterns: yyyy-MM-dd, yyyy-MM-ddTHH:mm:ssZ, MM/dd/yyyy, HH:mm. Negative arguments to the add* filters subtract.

Encoding filters

Filter	Example	Notes
`base64Encode`	`{{value \| base64Encode}}`	Base64-encode UTF-8 text
`base64Decode`	`{{value \| base64Decode}}`	Decode Base64 back to text
`urlEncode`	`{{value \| urlEncode}}`	Percent-encode for use in a URL
`urlDecode`	`{{value \| urlDecode}}`	Reverse percent-encoding

General filters

Filter	Example	Notes
`default: 'fallback'`	`{{maybeMissing \| default: 'n/a'}}`	Substitutes when the value is null or empty
`coalesce: fallback, ...`	`{{primary \| coalesce: secondary, 'n/a'}}`	Returns the first argument (starting with the input) that is not null or empty. Takes any number of fallbacks
`json`	`{{payload \| json}}`	Stringify the value as JSON
`escape`	`{{name \| escape}}`	HTML-escape a string

Array constructs

Beyond the filters above, four constructs transform arrays and pick branches. They use the same | syntax but are written by name.

Construct	Syntax	What it does
`map`	`{{items \| map: field=value, ...}}`	Project each array element into a new object. Use `$` for the current element and `$.field` for a field of it
`filter`	`{{items \| filter: $.qty > 0}}`	Keep only the elements matching a condition. `$` is the current element
`select`	`{{items \| select: $.sku}}`	Pull one field from every element into a flat array
`if`	`{{value \| if: "$ > 100", 'high', 'low'}}`	Inline conditional. The condition is a quoted string; the else branch is optional and passes the input through when omitted

{{extract.payload.lines | map: sku=$.sku, qty=$.quantity}}
{{extract.payload.lines | filter: $.amount > 0 | select: $.sku}}

These predicates use the same condition language as $when, so they accept &&, || and ( ) too: {{lines | filter: $.qty > 0 && $.kind == 'FEE'}}.

Live preview

When you edit a template field in a node editor, Ingestly shows a live preview of the resolved value. Select a document from the run toolbar so the preview evaluates against that document’s most recent run data. This lets you confirm a path and its filter chain produce the value you expect before you run the workflow. Without a selected document, the editor still validates the path and filter names but cannot show a resolved value.

Type-aware autocomplete

When you type inside a {{ ... }} field in a node editor, Ingestly suggests:

Upstream node fields at the start of the expression (after {{)
Built-in helpers (now, today, uuid, nowUnix) alongside fields
Filters after a |, scoped to the type of the preceding value (an array path shows length, first, join; a string path shows upper, lower, trim)
Filter arguments as snippet placeholders you can tab through

Unknown filter names render with a red squiggle and surface as a validation error on the node.

Inside JSON bodies

When you write a template inside a JSON value position, like "qty": "{{payload.qty}}", Ingestly emits the resolved value as raw JSON so types are preserved. A number stays unquoted, an object stays structured, an array stays an array.

{
  "amount": "{{payload.amount | round: 2}}",
  "lines": "{{payload.lineItems}}"
}

After substitution the request body becomes:

{
  "amount": 3.14,
  "lines": [{ "sku": "A1", "qty": 2 }]
}

This applies to the HTTP action and callback output body fields when they parse as JSON. Outside JSON value positions (URLs, email subjects, plain-text fields), templates substitute as plain strings.

Filter arguments inside a JSON-position template should use single quotes ('a') rather than double quotes, to avoid clashing with the surrounding JSON string.

Row expansion in JSON bodies ( $each and$ when)

A JSON body can fan out over a runtime array. Inside any JSON array, an object that carries a $each key is a row template: it is repeated once per element of the referenced array, and the $each key itself is removed from the output.

{
  "orderNumber": "{{transform1.payload.po_number}}",
  "salesOrderLines": [
    {
      "$each": "{{payload.lines}}",
      "lineObjectNumber": "{{$item.mark}}",
      "quantity": "{{$item.quantity}}"
    }
  ]
}

Inside a row template:

{{$item}} is the current array element, and {{$item.field}} reads a field from it
{{$index}} is the zero-based position
Values that are exactly one {{$item...}} or {{$index}} token keep their type (a number stays a number, an object stays structured)
Tokens that mix text and bindings, like "row {{$index}}: {{$item.mark}}", substitute as text
Other {{node.path}} tokens are left for normal substitution

Add a $when key to filter rows. The condition supports the comparison operators ==, !=, <, <=, >, and >=, the text operators contains, starts with, and ends with, a bare truthiness test, and a leading ! that negates the value or group after it:

"salesOrderLines": [
  {
    "$each": "{{payload.lines}}",
    "$when": "!{{$item.__label}}",
    "lineObjectNumber": "{{$item.mark}}",
    "quantity": "{{$item.quantity}}"
  },
  {
    "$each": "{{payload.lines}}",
    "$when": "{{$item.__label}} == 'surcharge'",
    "description": "{{$item.description}}",
    "unitPrice": "{{$item.total}}"
  }
]

contains, starts with, and ends with compare case-insensitively, so 'Fuel Surcharge' matches contains 'SURCHARGE'. == and != stay case-sensitive, since equality usually checks a code or identifier where case carries meaning.

Several row templates in one array concatenate in order: every row of the first template is emitted before any row of the second. That routes rows to different shapes, but it does not preserve the order of the source array, and the two conditions have to stay exact opposites of each other. When both templates loop over the same array, use $case instead. Two loops over different arrays, like {{$writeback.updates}} and {{$writeback.adds}}, are the intended use of this pattern. A reconcile node stamps classified extra rows with __label, so this pairs naturally with Expected extras. An object with only $when (no $each) is included or dropped as a whole. Row templates nest: a field inside a row can hold another array with its own $each over {{$item.subArray}}, and the inner template’s item refers to the inner element.

Combining conditions

Join conditions with && (both must hold) and || (either may hold). && binds tighter than ||, and ( ) overrides that.

{
  "lines": [
    {
      "$each": "{{review.payload.lines}}",
      "$when": "{{$item.quantity}} > 0 && {{$item.description}} contains 'SURCHARGE'",
      "description": "{{$item.description}}"
    }
  ]
}

Without brackets, A && B || C reads as (A && B) || C. Add brackets when you mean the other grouping:

"$when": "{{$item.quantity}} > 0 && ({{$item.kind}} == 'FEE' || {{$item.kind}} == 'TAX')"

! negates the value or group directly after it, so !{{$item.taxable}} and !({{$item.qty}} > 0 && {{$item.kind}} == 'FEE') both read the way you would expect. To negate a single comparison, use != or put the comparison in brackets. An older condition written as !{{$item.qty}} >= 5 still runs, but the builder now asks you to rewrite it as {{$item.qty}} < 5 or !({{$item.qty}} >= 5).

Picking a shape per row ($case)

When rows of one array need different shapes, add a $case key holding an ordered list of shapes. The first shape whose $when passes is merged into the row, and a shape with no $when always matches, so the last entry is the catch-all. The array is iterated once, so the output keeps the source order.

"purchaseInvoiceLines": [
  {
    "$each": "{{review.payload.lines}}",
    "lineType": "Item",
    "quantity": "{{$item.quantity}}",
    "$case": [
      {
        "$when": "{{$item.description}} contains 'SURCHARGE'",
        "description": "{{$item.description}}",
        "unitCost": "{{$item.total}}"
      },
      {
        "description": "C: {{$item.composition}}",
        "description2": "M: {{$item.mark}}",
        "unitCost": "{{$item.price}}"
      }
    ]
  }
]

Keys outside $case, like lineType and quantity above, are shared by every row.
The winning shape’s keys are merged over the shared keys, so a shape can override a shared value.
A key that only one shape sets, like description2, is absent from rows that pick another shape.
The outer $when still filters which rows exist at all, and runs before the shape is picked.
A shape cannot contain its own $each or $case. The builder rejects a $case where a shape tries to nest another row template.

The last shape must have no $when. Without a catch-all, a row that matches no shape is dropped from the output, so the builder rejects a $case whose last shape is conditional.

$case also works on an object that is not a row template, where it picks one shape once:

"header": {
  "$case": [
    { "$when": "{{extract.payload.total}} > 10000", "approval": "required" },
    { "approval": "none" }
  ]
}

In this value position, a $case that matches no shape resolves to null instead of dropping anything. Row expansion applies to the HTTP action, callback, Business Central, and QuickBooks body fields when they parse as JSON. A $each reference that does not resolve to an array contributes no rows.

Inside a Loop body, an HTTP, callback, Business Central, or QuickBooks body field is the one place a bare {{$item}} / {{$index}} still work: inside a $each row template they keep meaning the $each row, exactly as above. Everywhere else in that same body (the URL, headers, or a field outside a $each row), reference the loop item with the qualified {{<loop node name>.payload.item}} / .payload.index instead; a bare {{$item}} or {{$index}} there resolves to nothing.

Common recipes

Last item from an extracted line items array, with a fallback:

{{extract.payload.lineItems[-1].sku | default: 'no-sku'}}

Total of a numeric array, rounded:

{{extract.payload.amounts | sum | round: 2}}

Today’s date plus 30 days as a yyyy-MM-dd string:

{{today | addDays: 30 | formatDate: 'yyyy-MM-dd'}}

Stringified JSON of a structured value, for a plain-text field:

{{extract.metadata | json}}

Comma-joined tags, uppercased:

{{extract.payload.tags | join: ', ' | upper}}

When a template doesn’t resolve

A path can fail to resolve for several reasons: the field is missing, the upstream node didn’t run, the index is out of bounds, or the path is malformed. What happens next depends on the workflow’s Strict references setting.

Strict references

Every workflow carries a Strict references setting, in Workflow settings in the editor. It decides what an unresolved reference costs.

Setting	What an unresolved reference does
On (strict)	The step fails, naming the token, the node, and the field it appeared in
Off (lenient)	The reference renders as an empty string and the run carries on. The step records which references came up empty

Workflows you create now, including ones started from a template, are strict by default. Workflows that existed before the setting was introduced are lenient, so nothing about their behavior changed. Copying a workflow, or copying it to another environment, carries the setting across.

Lenient is the riskier default, because an empty value looks like a value: a body field silently goes blank, and the receiving system either rejects it or stores the blank. Strict turns that into a failed step you can see. Turn it on once you know which references are genuinely optional, and mark those with a default filter.

Under strict references, two things rescue a path that would otherwise fail:

{{maybe.payload.note | default: ''}} resolves to an empty string on purpose.
{{a.payload.x | coalesce: b.payload.x}} falls back to another path.

A strict failure reads like this, and the step’s error output fires so you can route it:

Node 'Deliver': {{extract.payload.poNumber}} did not resolve (body).
Add "| default: ''" to allow an empty value, or turn off strict resolution in workflow settings.

Test runs stay lenient. A test step or a dry run never fails on an unresolved reference, so you can build against partial data. Strict references only bite on live runs.

Before you turn it on

Open Workflow settings and look under the switch. Ingestly scans this workflow’s recent runs and reports how many of them rendered a reference empty, listing each token, the node it is on, how often it missed, and when it was last seen. Turning strict on would fail every one of those, so fix or default them first. If the panel reports no unresolved references in the window, the switch is safe to flip.

Finding them after the fact

A step that rendered references empty carries an amber badge in the run detail reading “N references rendered empty on this step”, listing the exact tokens. That badge is how you find a hole in a lenient workflow before a downstream system does. If the filter name is unknown or a filter call is malformed (wrong arg count, bad argument type), the substitution yields an empty string and the node surfaces a validation error. The node you named is on a branch that did not run. A node is readable by name only when the connection from it to the node reading it actually fired - Ingestly used to let any node that ran be read by name, and no longer does. If a Reconcile node routes out its mismatch port, its matched connection did not fire on that run, so a node downstream of matched cannot read Reconcile by name, even though Reconcile itself ran. This is what stops a template resolving against a branch nobody took. Reference the branch that did run, or use {{$input.*}} to resolve to whichever branch fired.

Getting started

Learn

Guides

Reference

Administration

Expressions and filters

Basic syntax

Path

Reading across an array

Built-in placeholders

Source document file

The live input

Built-in helpers

Filters

Filter arguments

String filters

Number filters

Format filters

Array filters

Date filters

Encoding filters

General filters

Array constructs

Live preview

Type-aware autocomplete

Inside JSON bodies

Row expansion in JSON bodies ( $each and$ when)

Combining conditions

Picking a shape per row ($case)

Common recipes

When a template doesn’t resolve

Strict references

Before you turn it on

Finding them after the fact

​Basic syntax

​Path

​Reading across an array

​Built-in placeholders

​Source document file

​The live input

​Built-in helpers

​Filters

​Filter arguments

​String filters

​Number filters

​Format filters

​Array filters

​Date filters

​Encoding filters

​General filters

​Array constructs

​Live preview

​Type-aware autocomplete

​Inside JSON bodies

​Row expansion in JSON bodies (eachandeach and eachandwhen)

​Combining conditions

​Picking a shape per row ($case)

​Common recipes

​When a template doesn’t resolve

​Strict references

​Before you turn it on

​Finding them after the fact

Basic syntax

Path

Reading across an array

Built-in placeholders

Source document file

The live input

Built-in helpers

Filters

Filter arguments

String filters

Number filters

Format filters

Array filters

Date filters

Encoding filters

General filters

Array constructs

Live preview

Type-aware autocomplete

Inside JSON bodies

Row expansion in JSON bodies ( $each and$ when)

Combining conditions

Picking a shape per row ($case)

Common recipes

When a template doesn’t resolve

Strict references

Before you turn it on

Finding them after the fact