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

Error Handling

HTTP errors (4xx, 5xx) are treated as node failures. A failed node is logged and marked failed, and its downstream edges are not traversed. There is no "on error" route, so that branch simply stops.

To branch on the result instead of halting, call the API through a saved HTTP connector. Connectors return a { success, status, data } envelope (see Connector Output Structure) rather than raising, so you can route on it 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