Routes

What a route is

A workflow can have multiple routes. Each route is an independent unit made up of one trigger (what starts it) and its own ordered sequence of steps (what runs when it does) — so one workflow can expose several different entry points, each with their own logic.

Route details

• Name — required.
• Slug — required, auto-generated from the name but editable. Must be unique among the workflow's routes, and may only contain lowercase letters, numbers, and hyphens.
• Description — optional.
• Route Type — Public or Private, a categorization for the route.

Authentication

Separate from Route Type, each route also has its own auth toggle:

• No Auth (default) — the route's endpoint accepts requests with no authentication.
• Requires Auth — the route requires either:
  • API Key — a request header (default X-API-Key) whose value is checked against a workflow variable.
  • JWT — a request header (default Authorization) holding a bearer token, verified with the chosen algorithm (HS256/HS384/HS512) against a workflow variable holding the secret. The Bearer prefix is stripped by default before validation, and the decoded payload is available to the route's steps as {{trigger.jwt_payload}}.

Either way, the actual secret value lives in a workflow variable (type string or secure-string) referenced by the route — the real value is set in the Live Workflow settings when the workflow is published, not typed directly into the route.

Steps

A route's steps run in order when its trigger fires. See Step Name for how steps are named and referenced, Step Reference for using one step's output in a later one, and Connections for how a step authenticates with the service it calls.