Connectors

HTTP Proxy Connector

Forward a request to an external URL or another workflow using method/path routing rules, with optional access-denied rules to block specific requests outright.

On this page

What this connector is for Configuring a request Path matching (Routing Rules and Access Denied Rules)Header handling Routing to another workflow Reading the response Examples Step Name Step Reference Execution Settings Caching Locking

What this connector is for

Forwards ("proxies") a request — typically the one that triggered this workflow — to a target, chosen per-request by method/path rules: either an external URL (like a lightweight reverse proxy / API gateway) or another workflow (running it directly, in-process). Optional access-denied rules can block specific method/path combinations outright with a 403, before anything is forwarded.

Configuring a request

Default Base URL — required. The target used when no Routing Rule matches (e.g. https://api.example.com).
HTTP Method (Optional) — GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS. Defaults to the triggering request's own method if left unset.
Path (Optional) — defaults to the triggering request's own path. Supports {{expressions}}.
Additional Headers — merged with the triggering request's headers; anything you set here overrides a forwarded header of the same name (case-insensitively). Supports {{expressions}}.
Query Parameters — merged the same way with the triggering request's own query string.
Request Body (Optional) — defaults to the triggering request's own body for methods that carry one (POST/PUT/PATCH/DELETE).
Routing Rules — an ordered list; the first enabled rule whose method and path both match wins. Each rule has:
- Match Method — a specific method, or */empty for any.
- Match Path — see "Path matching" below.
- Routing Type — external (default) or workflow.
- Target URL — required when Routing Type is external.
- Workflow Slug — required when Routing Type is workflow.
- Enabled — defaults to true; a disabled rule is skipped entirely.
- No rules at all (the default) means every request goes to the Default Base URL.
Access Denied Rules — evaluated before routing, in the order listed. Each has a Method (or ANY) and a Path pattern (same matching as Routing Rules). Any match returns a 403 immediately — the request is never forwarded and no Routing Rule is even evaluated.
Follow Redirects — default true (follows up to 5); set false to stop at the first redirect response instead.
Validate Status — default false (any status code is returned as-is, letting you branch on it later). Set true to instead throw on any non-2xx response.
Verify SSL Certificate — default true. Set false only against a target with a self-signed/invalid certificate in development — never in production.

Path matching (Routing Rules and Access Denied Rules)

Both use the same three patterns against the request path:

Exact — /api/users matches only /api/users.
Wildcard — /api/users/* matches anything under that prefix.
Named parameters — /v2/carts/:cartId/items matches /v2/carts/abc123/items and captures cartId=abc123. Captured values are only used when Routing Type is workflow (see below) — they aren't substituted into an external Target URL.

Trailing slashes are ignored when comparing.

Header handling

Regardless of what's in the triggering request, these headers are never forwarded: host, connection, content-length, transfer-encoding, origin, referer, x-request-environment-id (environment routing is propagated explicitly through the execution context, not headers), and accept-encoding (so the target doesn't reply using a compression format this connector can't decompress). Additional Headers you set explicitly still override any other forwarded header with the same name.

Routing to another workflow

When a matched Routing Rule's Routing Type is workflow rather than external, nothing is sent over HTTP — the workflow identified by Workflow Slug is executed directly, in the same store and the same environment as this workflow. It receives the method, merged headers, body, merged query parameters, and any path parameters captured from Match Path as its own trigger data.

This changes what the response looks like:

{{<stepReference>.response.status}} is always 200 on success — it does not reflect anything that happened inside the target workflow.
{{<stepReference>.response.data}} is the target workflow's own result object, not an HTTP response body.
{{<stepReference>.response.headers}} is empty.
{{<stepReference>.childExecutionId}} and {{<stepReference>.childExecutionLabel}} (the workflow slug) are also present — useful for tracing the nested execution.

Reading the response

For a Default Base URL or an external Routing Rule match, the response mirrors the HTTP Connector's own shape:

{{<stepReference>.response.status}} / .statusText — the upstream HTTP status.
{{<stepReference>.response.headers.<name>}} — an upstream response header.
{{<stepReference>.response.data.<field>}} — the parsed response body.

A request denied by an Access Denied Rule resolves as {{<stepReference>.response.status}} = 403 with {{<stepReference>.response.data.error}} = "Access Denied".

For example, a step named "Proxy To Backend" (reference proxyToBackend) forwarding to an order service — use {{proxyToBackend.response.status}} and {{proxyToBackend.response.data.orderId}}.

Examples

Forward everything to a default backend

Default Base URL: https://api.example.com

Route by path to different external targets

Default Base URL: https://api.example.com
Routing Rules:
  - Match Path: /v2/carts/*        Routing Type: external   Target URL: https://carts.example.com
  - Match Path: /v2/orders/:orderId Routing Type: external  Target URL: https://orders.example.com

Route a path straight into another workflow

Default Base URL: https://api.example.com
Routing Rules:
  - Match Path: /internal/sync/*   Routing Type: workflow   Workflow Slug: nightly-inventory-sync

Block admin paths outright

Default Base URL: https://api.example.com
Access Denied Rules:
  - Method: ANY   Path: /admin/*

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

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

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

Referencing trigger data

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

Referencing workflow variables

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

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

Caching

What it does

When enabled, a step's result is cached for a configurable TTL (time-to-live, in seconds). If the step runs again with the same effective cache key before the TTL expires, the cached result is returned instead of re-running the step.

Configuring it

Enabled — turn caching on or off for this step.
TTL — how long (in seconds) a cached result stays valid.
Cache key template — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same call". By default this is based on the step's resolved input; a custom template lets you cache more narrowly or broadly than that.

When to use it

Good candidates are steps that call something slow or rate-limited but return the same answer for the same input within a short window — a lookup against a rarely-changing external system, for example. Skip it for steps whose result must always be fresh (anything involving live inventory, pricing, or payment state).

Locking

What it does

When enabled, only one execution of this step (for a given lock key) can run at a time. If a second execution tries to run the same step while a lock is held, it waits until the lock is released or the hold period elapses.

Configuring it

Enabled — turn locking on or off for this step.
Lock key — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same resource". By default the lock is scoped to the step itself; a custom key lets you lock per-customer, per-order, or any other identifier that needs serialized access.
Period — how long (in seconds) the lock is held before it's automatically released, in case an execution doesn't complete normally.

When to use it

Use it whenever concurrent executions could race on the same resource — e.g. two workflow runs both trying to update the same order's status at once. A lock key scoped to the order id ensures only one of them proceeds at a time.