Skip to main content

Workflows

A Workflow is a visual, node-based processing pipeline that runs for every request to a specific Proxy. Instead of simple pass-through routing, workflows let you transform requests, call multiple services, apply logic, query databases, send notifications — without changing your backend code.

What can you do with workflows?​

  • Transform request/response: modify headers, body, or path before forwarding
  • Call multiple backends: fan out to multiple services and merge the results
  • Query a database: enrich a response with data from MongoDB, PostgreSQL, or other databases
  • Conditional routing: branch based on request content, user identity, or backend response
  • Mock an API: return a custom response without any backend (great for building APIs without infrastructure)
  • Send notifications: trigger emails (SMTP/SendGrid) or Kafka messages as a side effect of an API call
  • Generate or validate JWTs: add token exchange or validation as a gateway step
  • Run custom code: execute JavaScript for complex transformations

How workflows work​

A workflow is a directed acyclic graph (DAG) of connected nodes:

  1. http_trigger receives the incoming request context.
  2. Branch A calls http_request_node to fetch user data, then normalizes fields in set_node.
  3. Branch B calls another http_request_node to fetch account balance.
  4. merge_node combines both branch outputs.
  5. response_node returns the final payload to the client.

Gateway traffic uses an http_trigger (the incoming request). For runs started only from the workflow builder, you can use a manual_trigger instead (no request body; see Manual Trigger). Request-driven flows typically end with a response_node (the response returned to the client).

Data flow between nodes​

Each node outputs data that is available to all downstream nodes via the expression syntax:

$json['node_id'].field.subfield

For example, if a node with ID get_user returns { "name": "Alice" }, you can reference it downstream as:

{{ $json['get_user'].name }}

→ See Expressions for the full expression syntax.

Enabling a workflow on a proxy​

  1. Open a Proxy
  2. Click Edit Workflow (or Enable Workflow)
  3. Choose your build mode:
    • start from a prebuilt template pattern (recommended for common flows), or
    • build a custom workflow from the default http_trigger → response_node
  4. Configure nodes and connections for your use case
  5. Toggle Workflow Enabled to activate it

When enabled, every request to that proxy executes the workflow instead of simple forwarding.

Prebuilt templates vs custom workflows​

Use prebuilt templates when you want speed and consistency:

  • Orchestration template (multi-backend aggregation)
  • Transform template (request/response mapping)
  • Resiliency template (retry/fallback)

Use custom workflows when your logic is domain-specific:

  • Unique branching rules per tenant/partner
  • Complex enrich/merge behavior
  • Custom response shaping and fallback strategy

Tip: start with a template, then customize nodes/conditions for your business flow.

Performance​

Workflows run in the gateway path — they are not external services or queues. This means:

  • Low added latency (typically < 5ms overhead per node)
  • Full access to request/response context
  • Support for real-time and streaming responses
  • Parallel execution of independent node branches

Use cases by industry​

Use caseWorkflow pattern
Add authentication headershttp_trigger → set_node (add auth header) → proxy_node
Enrich response with DB datahttp_trigger → proxy_node → mongodb_node → merge_node → response_node
Mock an API stubhttp_trigger → response_node (static body)
Fan out to microserviceshttp_trigger → [http_request × 3 in parallel] → merge_node → response_node
Token exchangehttp_trigger → jwt_node (generate) → proxy_node (forward with new token) → response_node
Webhook with notificationhttp_trigger → proxy_node → sendgrid_node → response_node

Next steps​