Edge Delta HTTP Workflow Input Source

Configure the HTTP Workflow Input source to execute multi-step HTTP request sequences with variable passing, conditional execution, and webhook triggers.

4 minute read

Overview

The HTTP Workflow Input source enables multi-step HTTP request sequences with variable passing between steps, conditional execution, and webhook triggers. This is useful for orchestrating complex API interactions where data from one request informs subsequent requests.

outgoing_data_types: log

Note: This node is currently in beta and is available for Enterprise tier accounts.

This node requires Edge Delta agent version v2.8.0 or higher.

Example Configuration

This configuration executes a two-step workflow: first authenticating with an API, then using the response to fetch data.

nodes:
  - name: api_workflow
    type: http_workflow_input
    workflow_pull_interval: 5m0s
    steps:
      - name: auth
        endpoint: https://api.example.com/auth
        method: POST
        headers:
          Content-Type: application/json
        request_body: '{"api_key": "{{ SECRET api_key }}"}'
      - name: fetch_data
        endpoint: https://api.example.com/data
        method: GET
        header_expressions:
          Authorization: Concat(["Bearer ", steps["auth"]["body"]["token"]], "")
        is_last_step: true

Required Parameters

name

A descriptive name for the node. This is the name that will appear in pipeline builder and you can reference this node in the YAML using the name. It must be unique across all nodes. It is a YAML list element so it begins with a - and a space followed by the string. It is a required parameter for all nodes.

nodes:
  - name: <node name>
    type: <node type>

type: http_workflow_input

The type parameter specifies the type of node being configured. It is specified as a string from a closed list of node types. It is a required parameter.

nodes:
  - name: <node name>
    type: <node type>

steps

A sequence of HTTP request steps to execute. Each step can reference data from previous steps using OTTL expressions.

Field	Description	Required
`name`	Unique name for this step	Yes
`endpoint`	URL to send the HTTP request to	No
`method`	HTTP method (`GET` or `POST`)	Yes
`headers`	Static headers (key-value pairs)	No
`parameters`	Static query parameters (key-value pairs)	No
`request_body`	Static request body content	No
`endpoint_expression`	OTTL expression for dynamic endpoint	No
`header_expressions`	OTTL expressions for dynamic headers	No
`parameter_expressions`	OTTL expressions for dynamic query parameters	No
`request_body_expression`	OTTL expression for dynamic request body	No
`request_timeout`	Timeout for this step’s HTTP request	No
`run_condition`	OTTL expression that must evaluate to true for the step to execute	No
`is_last_step`	Marks this as a terminal step	No

Optional Parameters

workflow_pull_interval

Interval between workflow executions (e.g., 1m, 5m). Cannot be used with webhook or workflow_pull_schedule.

nodes:
  - name: <node name>
    type: http_workflow_input
    workflow_pull_interval: 5m
    steps:
      - ...

workflow_pull_schedule

Cron expression for scheduled workflow execution (e.g., 0 0 3 * * * for daily at 3 AM). Cannot be used with webhook or workflow_pull_interval.

nodes:
  - name: <node name>
    type: http_workflow_input
    workflow_pull_schedule: "0 0 3 * * *"
    steps:
      - ...

global_timeout

Maximum total time for the entire workflow execution.

nodes:
  - name: <node name>
    type: http_workflow_input
    global_timeout: 2m
    steps:
      - ...

emit_intermediate

Whether to emit results from intermediate steps. Default is false.

nodes:
  - name: <node name>
    type: http_workflow_input
    emit_intermediate: true
    steps:
      - ...

emit_transform

OTTL statements to transform the final emitted log. Access workflow context via steps["name"]["body"], variables["key"], webhook_payload["key"].

nodes:
  - name: <node name>
    type: http_workflow_input
    emit_transform: |
      set(body, steps["fetch_data"]["body"]["results"])      
    steps:
      - ...

webhook

Configure a webhook trigger for this workflow instead of using pull-based scheduling.

Field	Description
`path`	URL path for the webhook endpoint (e.g., `/webhooks/my-workflow`)
`method`	HTTP method (default: `POST`)
`port`	Webhook server port (default: `8080`)
`auth_type`	Authentication method (`none`, `bearer`, `api_key`, `hmac`)
`bearer_token`	Token for bearer authentication
`api_key`	Key for API key authentication
`api_key_header`	Header name for API key (default: `X-API-Key`)
`hmac_secret`	Secret for HMAC signature validation
`hmac_header`	Header containing the HMAC signature (default: `X-Webhook-Signature`)

nodes:
  - name: <node name>
    type: http_workflow_input
    webhook:
      path: /webhooks/my-workflow
      auth_type: bearer
      bearer_token: '{{ SECRET webhook_token }}'
    steps:
      - ...

Use Cases

Multi-Step API Orchestration

Chain API calls where each step uses data from previous steps.

nodes:
  - name: user_data_workflow
    type: http_workflow_input
    workflow_pull_interval: 10m
    steps:
      - name: get_users
        endpoint: "https://api.example.com/users"
        method: GET
        headers:
          Authorization: '{{ SECRET api_token }}'
      - name: get_details
        method: GET
        endpoint_expression: 'Concat(["https://api.example.com/users/", steps["get_users"]["body"]["id"], "/details"])'
        is_last_step: true

Webhook-Triggered Workflows

Execute workflows in response to external events.

nodes:
  - name: webhook_workflow
    type: http_workflow_input
    webhook:
      path: /webhooks/alerts
      auth_type: hmac
      hmac_secret: '{{ SECRET hmac_key }}'
    steps:
      - name: process_alert
        endpoint: "https://api.example.com/process"
        method: POST
        request_body_expression: 'webhook_payload'
        is_last_step: true