younifyd
Menu

Crypto Connector

Hash strings (optionally as HMAC) and encrypt/decrypt data with AES-CBC using Node's built-in crypto module. Covers key derivation, IV handling, and failure behaviour.

Browse 3 Crypto actions security
On this page

What this connector is for

Hashes strings (one-way, optionally as HMAC) and encrypts or decrypts data (two-way, symmetric AES-CBC) using Node's built-in crypto module. No connection is needed. Secrets are supplied per step, ideally from a workflow variable such as {{variables.tokenEncryptionKey}} rather than typed into the step.

Results are returned at {{<stepReference>.response.data...}} (see Step Reference). Every action's own result fields are listed in the action reference.

Hash String

A hash can't be reversed to the original input. If a Secret Key (HMAC) is supplied and non-blank, the result is an HMAC keyed with that secret instead of a plain hash, and isHmac is true. Use HMAC when the receiver must verify the hash came from someone who knows the secret. md5 and sha1 are offered for compatibility with systems that require them, not where collision resistance matters.

Encrypt Data

  • The Secret Key is not used directly as the AES key. It is hashed once with SHA-256 and truncated to the algorithm's key length. That is a fast hash with no salt or iteration count, so a short or guessable secret is comparatively easy to brute-force offline. Use a long random secret.
  • A random IV is generated per call and returned as iv, encoded like the ciphertext. It isn't secret, but it is required to decrypt, so store it alongside the ciphertext.
  • An object passed as data is stringified first.

Decrypt Data

Needs the same Secret Key, algorithm, and encoding used to encrypt, plus the iv. A wrong key, IV, or algorithm, or altered ciphertext, fails the step with an error rather than returning a structured "invalid" result. Use Continue On Error or an error-handling path if that is an expected case. decrypted is always a string. isJson is true when it parses as JSON, and only then is the parsed object present at data.

Your first call

  1. Add an Encrypt Data step named "Encrypt Card Token" with Data to Encrypt {"cardToken": "tok_1234"} and Secret Key {{variables.tokenEncryptionKey}}.
  2. Read {{encryptCardToken.response.data.encrypted}} and {{encryptCardToken.response.data.iv}} and store both.
  3. Add a Decrypt Data step named "Decrypt Card Token" that takes those two values and the same secret, then read {{decryptCardToken.response.data.data.cardToken}}.

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.
Was this page helpful?

Last updated 9 October 2026