JWT Connector

Sign, decode, and verify HMAC-based JSON Web Tokens (HS256/HS384/HS512) as a workflow step. Covers expiry handling and verification failure behaviour.

Open in Claude

Browse 3 JWT actions security

On this page

What this connector is for Generate JWT Decode JWT Verify JWT Your first call Step Name Step Reference

What this connector is for

Signs, decodes, and verifies JSON Web Tokens as a workflow step, for example to create a token another API expects, or to check one you received. All signing and verification is HMAC-based (HS256, HS384, HS512) with a shared secret. Keep the secret in a workflow variable, not typed into the step.

This is separate from a route's own Requires Auth: JWT option, which verifies an incoming request's bearer token before the workflow starts. That option gates access to a route. This connector's actions are ordinary steps you place anywhere in a route's logic.

Results are returned at {{<stepReference>.response.data...}} (see Step Reference). Every action, with its fields, is listed in the action reference.

Generate JWT

Payload can be given as a JSON string or a native object. Expiration Time (such as 1h or 7d) is optional, and an empty value means the token never expires. It is ignored, with a logged warning and no error, if the Payload already has its own exp claim. The result includes the final encoded payload, and expiresAt only when the token expires.

Decode JWT

Reads the header and payload without verifying the signature, so never use it to authenticate anything. A string that isn't a well-formed JWT makes this step fail rather than return an "invalid" result. With Complete Decode off, header is absent entirely.

Verify JWT

Checks signature and expiration. Unlike Decode, a bad signature, expired token, or algorithm mismatch does not fail the step. It returns valid as false with an error message such as "jwt expired" or "invalid signature", so the workflow can branch on it with a Condition step. payload, header, expiresAt, and issuedAt are only populated when valid is true. Allowed Algorithms defaults to all three HMAC variants. Narrow it to the one you sign with to reject tokens signed with a different strength.

Your first call

Add a Generate JWT step named "Sign Partner Token" with Secret {{variables.partnerJwtSecret}}, Payload {"sub": "{{trigger.body.userId}}", "role": "customer"}, and Expiration Time 1h.
Use {{signPartnerToken.response.data.token}} as a bearer token in a later HTTP step.
To check a token you receive, add a Verify JWT step named "Verify Partner Token" and branch on {{verifyPartnerToken.response.data.valid}} before reading {{verifyPartnerToken.response.data.payload.sub}}.

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