Docs / Strand / nodes/http-request

HTTP Request Node

The HTTP Request node makes HTTP requests to external APIs.

Any field here accepts Jinja, so {{ vault.api_token }} in a header keeps the secret out of the node.

Overview#

HTTP Request nodes allow you to call external APIs, webhooks, and HTTP endpoints from your workflows.

Configuration#

URL Configuration#

Direct URL#

https://api.example.com/users/{{ payload.user_id }}

Using Connector#

When using a connector, specify the endpoint instead of full URL:

/users/{{ payload.user_id }}/profile

The connector provides the base URL and authentication.

HTTP Methods#

Headers#

Headers support templating in their values:

{
  "Authorization": "Bearer {{ vault.api_token }}",
  "Content-Type": "application/json",
  "X-User-ID": "{{ payload.user_id }}"
}

Request Body#

JSON Body#

{
  "user_id": "{{ steps.user_lookup.output_payload.id }}",
  "message": "{{ payload.message }}",
  "timestamp": "{{ meta.received_at }}"
}

String Body#

{{ payload | tojson }}

Using Previous Steps (Direct Connection)#

When directly connected, use payload:

{
  "data": {{ payload | tojson }},
  "metadata": {
    "source": "{{ initial.meta.trigger_source }}"
  }
}

Using Non-Direct Steps#

When accessing data from a non-directly connected node:

{
  "data": {{ steps.process.output_payload | tojson }},
  "metadata": {
    "source": "{{ initial.meta.trigger_source }}"
  }
}

Query Parameters#

Add query parameters to the URL:

{
  "page": "{{ payload.page | default(1) }}",
  "limit": "50",
  "filter": "{{ payload.status }}"
}

Results in: ?page=1&limit=50&filter=active

Path Parameters#

Replace placeholders in the URL with dynamic values:

• URL: https://api.example.com/users/{user_id}/orders/{order_id}
• Path Params:

  {
    "user_id": "{{ payload.user_id }}",
    "order_id": "{{ payload.order_id }}"
  }

Body Types#

The body_type field controls how the request body is formatted:

Retry Configuration#

Configure automatic retries for transient failures:

{
  "retry": {
    "enabled": true,
    "max_attempts": 3,
    "backoff_type": "exponential",
    "backoff_delay": 1,
    "backoff_max": 30,
    "retryable_status_codes": [429, 500, 502, 503, 504]
  }
}

Response#

The HTTP Request node outputs:

• output_payload - Response body (parsed JSON if possible, otherwise string)
• output_meta - Response metadata:
• status_code - HTTP status code
• url - Final request URL

Accessing Response#

{{ steps.api_call.output_payload.data }}
{{ steps.api_call.output_meta.status_code }}

Response options#

A response object on the node tunes how the reply is judged and parsed:

{
  "response": {
    "expected_status_codes": [200, 201],
    "error_on_status": [500, 502, 503]
  }
}

Error Handling#

A 4xx or 5xx response is not a node failure. The node returns the same { success, status, data } envelope a connector does (see Connector Output Structure), with success set to false, and downstream edges are traversed normally. Route on the envelope with an If/Else Logic node:

{{ payload.success }}

The if handle handles success; the else handle handles failure. See Conditional Logic.

Examples#

GET Request#

Configuration:

• URL: https://api.example.com/users/{{ payload.user_id }}
• Method: GET

POST Request with Body (Direct Connection)#

Configuration:

• URL: https://api.example.com/send-email
• Method: POST
• Body:

  {
    "to": "{{ payload.email }}",
    "subject": "Welcome!",
    "body": "Hello {{ payload.name }}"
  }

Using Connector#

Configuration:

• Connector: my-api-connector
• Endpoint: /users/{{ payload.user_id }}
• Method: GET

The connector provides base URL and authentication automatically.

Best Practices#

Related#

• Connectors - Using saved HTTP connectors
• Passing Data - Using previous step outputs
• Jinja2 Syntax - Templating in URLs and bodies

← Back to Strand docs