Skip to main content
Fetch data nodes make HTTP requests to external services during journey execution. Courier merges the response into the journey context, where downstream nodes read it as variables. Use it to pull real-time data from your application: whether a user completed an action, order details, or any internal API.

​
Configuration

The fetch node has two panels: a summary panel (visible when clicking the node on the canvas) and a full HTTP request editor (opened by clicking Setup Request).

Fetch node summary panel showing HTTP Request, Merge Strategy, and Conditions

​
HTTP request editor

Click Setup Request to open the full-screen HTTP request editor. The editor has three columns: setup, input, and output.

HTTP request editor with method, URL, toggleable sections for headers/params/body, a cURL preview, and response output

Setup (left column):
  • Import cURL: Paste an existing cURL command to auto-populate the request configuration.
  • Method: GET, POST, PUT, or DELETE.
  • URL: The endpoint to call. Supports variable interpolation with {{field_name}} syntax (e.g., https://api.example.com/users/{{user_id}}). Only HTTPS URLs are allowed.
  • Headers: Toggle on to add key-value header pairs. Common use: Authorization: Bearer {{api_token}}.
  • Query Parameters: Toggle on to add key-value query parameters appended to the URL.
  • Body: Toggle on to add a JSON request body (available for POST and PUT only, disabled for GET and DELETE).
Input (center column): If your URL or body contains variables like {{user_id}}, this column shows fields for test values. A live cURL preview updates as you fill them in. Output (right column): Click Execute Step to run the request and see the response. On a successful 2xx response, Courier extracts the response schema and saves the available fields. The summary panel then lists those field names and types, so you can confirm what data is available downstream. A “Last tested” timestamp shows when the schema was last captured.

​
Merge strategy

The merge strategy controls how the fetch response is combined with the existing journey context. Choose from the dropdown on the summary panel: Soft Merge is the safest default. Trigger schema fields and profile data are never overwritten by a fetch response.

​
Conditions

Fetch nodes support optional . If they are not met, the node is skipped and the journey continues without making the HTTP request.

​
Response handling

The response body is parsed as JSON and merged into the journey context using the selected merge strategy. If the fetch returns:
These fields become part of the journey’s data context. Downstream nodes reference them the same way they reference trigger schema fields:
  • In : select data.onboarding_complete as the field
  • In : use {{onboarding_complete}} or {{last_login}}
  • In recipient overrides: select the field from the dropdown
A failed fetch does not stop the journey. On a network error or a non-2xx response the run carries on with no data merged, and nothing marks the run as degraded. Branch on the fields you expected so a missing response takes a path you chose.

​
Chaining fetch nodes

Fetch nodes can run in sequence. Each one merges its response into the journey context, and all fields are available downstream. For example:
  1. Fetch order details: merges order_id, total, status into context
  2. Fetch user preferences: merges email_frequency, locale into context
  3. Branch: check email_frequency to decide whether to send