Connectors

JSONata Connector

Run a standalone JSONata expression against a JSON value to filter, reshape, or compute over it — distinct from the {{...}} template expressions used throughout the rest of the platform.

On this page

What this connector is for Transform Configuring it Reading the response Example Step Name Step Reference

What this connector is for

Runs a JSONata expression against a JSON value to filter, reshape, or compute over it — the same query/transformation language used to write {{...}} template expressions elsewhere in the platform, but evaluated differently here. It's worth being precise about the two:

Everywhere else ({{...}} inside any step field), a template expression is evaluated with a rich, platform-built context: trigger, every prior steps/named step, connections, runtimeVariables, and helper functions like stepByName()/connection()/flatten()/safeGet() (see Step Reference).
This connector's Expression field is evaluated with none of that. It's a bare JSONata expression run only against whatever JSON you put in its own Data field — no access to other steps, the trigger, or connections unless you first pull that data in via {{...}} in the Data field itself.

Those two layers still compose: because every step field (including this action's own Expression and Data fields) is first passed through the standard {{...}} template resolver, you can write {{getOrder.response.data}} in the Data field to pull in a prior step's output, and then write a JSONata Expression that transforms it — the Expression itself just never gets direct {{...}}-style access to other steps.

Transform

Executes a JSONata expression against a JSON value and returns the result.

Configuring it

Expression — required, non-empty. The JSONata expression to run, e.g. orders[price > 100].{item: product.name, total: price * quantity}. Evaluated standalone (see above) — no trigger/step/connection access inside the expression itself.
Input Data — required. The JSON to transform. If it's a string, it's parsed as JSON first; if parsing fails, it's used as a literal string value instead. Typically populated via {{...}} from a prior step or the trigger, e.g. {{trigger.body}}.
Pre-Processing Manipulations — optional array, applied to Input Data before the JSONata expression runs (shared with other connectors' manipulation field). Each row has:
- Operation — one of add, append, prepend, insert, merge, update, remove.
- Path — required. Dot-notation target, e.g. user.profile.email or items[0].tags.
- Value — the value to add/update/append/merge/insert; parsed as JSON if it looks like JSON, otherwise used as a literal.
- Index — for the insert operation only: the array index to insert at.
- Create Path if Missing — default true; creates intermediate objects/arrays along Path if they don't exist yet.

Note: the handler also supports an options.timeout/options.strict pair internally (default 5000ms timeout, non-strict), but neither is exposed as a configurable field in the workflow builder today — every run uses those defaults.

Reading the response

{{<stepReference>.response.data}} — the direct result of the JSONata expression, whatever shape it is (object, array, string, number, boolean). If the expression evaluates to an object, drill in further, e.g. {{<stepReference>.response.data.<field>}}.

For example, a step named "Reshape Orders" (reference reshapeOrders) whose expression evaluates to {"item": "Widget", "total": 300} — use {{reshapeOrders.response.data.item}} to get "Widget".

Example

Expression: orders[price > 100].{item: product.name, total: price * quantity}
Data: {{trigger.body}}

Given a trigger body of {"orders": [{"product": {"name": "Widget"}, "price": 150, "quantity": 2}, {"product": {"name": "Gadget"}, "price": 50, "quantity": 1}]}, this returns [{"item": "Widget", "total": 300}] — the $50 Gadget order is filtered out.

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

Must be at least 2 characters, and 50 characters or fewer.
Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
Can't be empty.

Tips

Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
Object values are automatically JSON-stringified when interpolated into a string field.