younifyd
Menu

Code Executor Connector

Run custom JavaScript or TypeScript in an isolated sandbox with access to workflow context and a whitelisted set of libraries — no filesystem, no environment variables, and no real outbound network access.

Browse 1 Code Executor actions logic
On this page

What this connector is for

Runs custom JavaScript or TypeScript in an isolated sandbox: a separate JS engine instance from the workflow server's own process, not a restricted eval. Use it for logic that doesn't map cleanly to another connector or JSONata expression, such as custom transforms, branching too complex for one expression, or building up a payload shape. No connection is needed.

The sandbox has no filesystem access, no environment variables, and no real network access. Every action, with its fields, is listed in the action reference.

Execute Code

Define a main() function (sync or async) as the entry point, or use a top-level return. Whatever comes back is the step's output, read as {{<stepReference>.response.data.<field>}}. If you return { total: 42 }, use {{computeTotal.response.data.total}} for a step with reference computeTotal.

javascript
function main() {
  const items = context.getOrderDetails.body.items;
  return { total: items.reduce((sum, i) => sum + i.price * i.qty, 0) };
}

TypeScript is transpiled before running; a compile error fails the step with the compiler's message.

Limits

  • Timeout defaults to 5000 ms and is silently clamped to 30000 ms, not rejected. It is a wall-clock ceiling on the whole step, including time spent awaiting async work (for example a setTimeout delay).
  • Memory defaults to 128 MB and is clamped to 512 MB. Code exceeding its isolate's memory limit is terminated.

Whitelisted libraries

You may import from lodash, date-fns, uuid, zod, validator, jsonpath, jsonata, slugify, axios and jsonwebtoken. Anything else fails with Library "<name>" is not allowed before your code runs. Only a curated subset of each library's functions is exposed (for example lodash's map, filter, groupBy, merge, not the whole surface).

The context object

Read-only workflow data:

  • context.workflowId, stepId, executionId, timestamp, environment.
  • context.steps: array of prior steps ({ id, name, reference, index, body }). Each step is also exposed by its reference, for example context.getUser.body (mirrors {{getUser.body}}). context.getStep(reference) looks one up by string.
  • context.trigger: the normalized trigger data (.body, .headers, .query, .params), or null if the workflow wasn't triggered by a request.
  • context.variables: workflow variables by name; context.getVariable(key) is equivalent. context.variableConfigs and context.getVariableConfig(key) return the full config.
  • context.connections, context.connectionsById, context.connectionList: connection contexts attached to this workflow.
  • context.utils: parseJSON, stringifyJSON, now() (ISO string), timestamp() (epoch ms), trim, toLowerCase, toUpperCase.

Console output and results

The returned value is serialized before leaving the sandbox: functions are stripped, circular references become "[Circular]", and Dates become ISO strings.

Examples

Group by a field with lodash:

javascript
import { groupBy } from 'lodash';

function main() {
  return groupBy(context.getOrders.body.data, 'status');
}

Validate the trigger payload with zod:

javascript
import { object, string, number, safeParse } from 'zod';

function main() {
  const schema = object({ email: string(), quantity: number() });
  const result = safeParse(schema, context.trigger.body);
  if (!result.success) {
    throw new Error('Invalid payload');
  }
  return result.data;
}

Sign a short-lived token, using a workflow variable as the secret:

javascript
import jwt from 'jsonwebtoken';

function main() {
  return {
    token: jwt.sign(
      { userId: context.trigger.body.userId },
      context.variables.jwtSecret,
      { expiresIn: '1h' }
    ),
  };
}

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}}:

text
{{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:

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

Referencing trigger data

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

Referencing workflow variables

text
{{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:

text
{{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.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.

Was this page helpful?

Last updated 9 October 2026