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. Public routes are exposed on the workflow's API URL and callable by external clients (subject to the auth setting below). Private routes are reachable only from inside the platform — another workflow can call one with an Invoke Workflow, Invoke Route, or Proxy step — and are not exposed on the public API URL.

Setup Trigger

One route per workflow can be designated the Setup Trigger (in the builder's Setup Trigger tab). That route then runs automatically — once, fire-and-forget — every time the workflow is deployed to an environment (both the first deploy and every re-deploy). Only a route whose trigger is an API endpoint or webhook with a real path is eligible.

The setup run receives, as its request body, the workflow's own callable URLs for the environment being configured:

• {{trigger.body.url}} — an object mapping each HTTP-reachable route slug to its public API URL.
• {{trigger.body.hooks}} — the same routes mapped to their webhook (hook-signed) URLs.
• {{trigger.body.environmentId}} — the environment being configured.

Typical use: register those URLs as webhooks with a third-party service so the integration is wired up as soon as the workflow goes live in an environment, with no manual step. The setup run uses origin: setup — route authentication is skipped, private routes are allowed, and it shows in the Executions list like any other run. If it fails, the failure is logged but the deploy still succeeds. The flag takes effect from the next Publish (it's read from the published snapshot, not the draft).

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.