Skip to main content

HTTP And Proxy

What this category is for​

Use these nodes when a workflow needs to receive an HTTP request, call another HTTP API, forward to the configured proxy target, or return an HTTP response to the client.

Node list table​

Node typePurposeKey inputsBranch outputs
http_triggerEntry point for request-driven workflows. Creates the request object used by downstream nodes.method, path, headers, query, bodynone
proxy_nodeRuns gateway proxy logic and forwards to upstream API.method, path, query, headers, bodysuccess, error
http_request_nodeCalls an arbitrary external HTTP endpoint with timeout/retry and optional credential-based auth.url (required), optional method, query_params, headers, body; config timeout_ms, retry_config, credentials_idsuccess, error
response_nodeSends final HTTP response and typically ends the request flow.status_code, headers, body; optional config continue_after_responsenone

For a non-HTTP entry (builder runs only), use Manual Trigger.

Common patterns​

1) API facade with fallback​

  • http_trigger -> proxy_node
  • Route proxy_node.success -> response_node (pass through status/body/headers)
  • Route proxy_node.error -> http_request_node (fallback service) -> response_node

2) Pre-processing before external call​

  • http_trigger -> set_node (build outbound payload) -> http_request_node
  • Use http_request_node.response.status_code and response.body for final mapping in response_node

3) Credentialized partner API call​

  • http_request_node with credentials_id referencing API key, basic auth, OAuth2 client credentials, or mTLS credentials
  • Keep static headers minimal and let credentials inject auth material

4) Error normalization​

  • http_request_node.error branch -> set_node to map raw upstream failures into stable API error shape
  • Return stable error contract from response_node

Common mistakes and how to debug​

  • response_node not reached: workflow does not auto-respond unless response_node or redirect_node is executed. Verify edge wiring from success/error branches.
  • Wrong header format: engine expects header values as arrays (map[string][]string). If values look wrong, inspect upstream output from the previous node.
  • Retried requests still failing: check http_request_node.response.error and timeout/retry config. Timeout too low is common.
  • Non-2xx treated as error branch: both proxy_node and http_request_node route non-2xx to error. Wire that branch explicitly.
  • JSON body confusion: body parsing depends on content type and payload shape. Inspect response.body in node test mode to confirm actual type (object vs string).