HTTP(S) Request node

The HTTP(S) Request node performs HTTP requests to external APIs from a workflow: calling REST APIs, retrieving data from external services, sending data to third-party services and integrating systems.

Parameters

Parameter	Type	Required	Default	Description
App	App	❌	—	Application associated with the node.
URL	String	✅	—	HTTP endpoint to call. Supports Handlebars variables: https://api.example.com/users/{{userId}}. Can include query parameters.
HTTP method	GET / POST / PUT / PATCH / DELETE	✅	—	Request method. GET: retrieve; POST: create or send; PUT: update; PATCH: partially modify; DELETE: delete.
Request mode	JSON / GraphQL / Form URL Encoded / Form Data	✅	—	Payload format sent.
Headers	Key-value	❌	—	Custom HTTP headers (auth, content-type, etc.). Support Handlebars variables.
Body	JSON	❌	—	Request body (often required for POST, PUT, PATCH). Supports Handlebars variables, automatic JSON validation.
Authentication	Authentication method	❌	—	Ecosystem authentication method applied to the request: None, Basic Auth, OAuth 2, API Key or Custom.
Timeout	Number (seconds)	❌	30	Maximum delay before request failure (minimum 1, maximum 300).
Error management	Boolean	❌	true	Stop the workflow execution on failure; if disabled, the workflow continues and the error stays in lastResponse.
Anonymize the response	Boolean	❌	—	Anonymizes the response.
Retry automatically	Boolean	❌	—	If the request fails, a retry automatically re-launches the request; if disabled, the workflow goes into error.

Request modes

• JSON: classic JSON body sending.
• GraphQL: sending a GraphQL query + a dynamic variables object — the payload is made of query (structure, requested fields) and variables (values injected at execution time). Most often used with the POST method.
• Form URL Encoded (application/x-www-form-urlencoded): form key-value pairs configured directly in the node.
• Form Data (multipart/form-data): forms, including file fields.

Example of GraphQL query:

query Post($postId: ID!, $lang: String) {
  post(id: $postId) {
    id
    name
    description(lang: $lang)
  }
}

{
  "query": "query Post($postId: ID!, $lang: String) { post(id: $postId) { id name description(lang: $lang) } }",
  "variables": {
    "postId": "{{data.postId}}",
    "lang": "{{context.lang}}"
  }
}

Use variables for all the values that change at each execution (identifier, filters, language, etc.) to keep a stable and maintainable query.

Form URL Encoded and Form Data

The Form URL Encoded and Form Data modes are configurable directly in the node:

1. Select the mode in Request mode.
2. Fill in the key / value pairs in the dedicated editor (values support Handlebars).
3. For Form Data, you can add file fields in addition to text fields.

The Content-Type header is set automatically (application/x-www-form-urlencoded or multipart/form-data).

Example in Form URL Encoded:

Key	Value
grant_type	client_credentials
client_id	{{dictionaries.auth.clientId}}

Example in Form Data (file upload):

Key	Type	Value
document	File	{{data.fileContent}}
metadata	Text	{{data.fileName}}

For a file already present in the context, the field value can start with file:: followed by the reference, for example file::document New.

Request body on GET and DELETE

You can include a request body on the GET and DELETE methods when the target API requires it. The default tab for these methods is Query params; switch to Body if necessary.

Import from a cURL command

You can paste a cURL command in the node to prefill URL, method, headers and body. The application/x-www-form-urlencoded and multipart/form-data formats are supported.

Authentication

The request can use an Ecosystem authentication method:

• None: no authentication.
• Basic Auth: username and password; Ecosystem automatically adds the Authorization: Basic xxx header.
• OAuth 2: Ecosystem obtains the token and refreshes it automatically on expiry.
• API Key: API key in a header or a query parameter; for a Bearer token, set the value as Bearer {{accessToken}}.
• Custom: JavaScript code that builds the authentication to apply.

See also: Use authentication methods in workflows and Authentication method types.

Input

The node receives the workflow context data (trigger or previous nodes) and injects it into the request via Handlebars variables:

{
  "name": "{{data.name}}",
  "email": "{{data.email}}"
}

Output

The HTTP node injects its response into context.lastResponse:

{
  "lastResponse": {
    "status": 201,
    "success": true,
    "headers": {
      "content-type": "application/json",
      "ratelimit-remaining": "49"
    },
    "data": {
      "id": "12345",
      "status": "created"
    }
  },
  "orderId": "12345"
}

• status: HTTP status code;
• success: true if the request succeeded (2xx status);
• headers: response headers;
• data: parsed response body (JSON object, text…).

In the example above, context.orderId was injected by a JSONPath extractor $.data.id.

Extractors

An extractor copies a value from the response to a context variable. If the value is absent (JSONPath not found), the node fails — this is the recommended behavior to avoid propagating incomplete data to the following nodes.

Extractor (JSONPath)	Context variable	Content
$.data.id	orderId	"12345"
$.data.items	orderItems	[...]
$.headers['ratelimit-remaining']	rateLimitRemaining	"49"

Use in the following nodes

• {{lastResponse.status}}: HTTP status code;
• {{lastResponse.success}}: request success;
• {{lastResponse.data}}: response body;
• {{lastResponse.headers}}: response headers;
• {{orderId}}: value copied in the context by an extractor.

Errors

• Timeout — the request exceeds the configured delay. Increase the timeout or check the API reachability and performance.
• 401 error (Unauthorized) — check the authentication method, the token expiration and the format used.
• 404 error (Not Found) — check the URL, the endpoint existence and the URL parameters.
• HTTP failure — with the Stop the workflow execution on failure option (default true), the workflow stops. To handle the failure cleanly, add an On Error node to the workflow. An HTTP 2xx status does not guarantee a valid business content: check {{lastResponse.success}} with a Condition node.

See also: Best practices — Error management.

Limits

• Timeout between 1 and 300 seconds (default 30).
• Increase the timeout for long requests, reduce it to fail quickly.

Example

Retrieve an order and send it to an ERP:

1. A trigger receives the order identifier (webhook or Trigger node).
2. The HTTP(S) Request node calls GET https://api.example.com/orders/{{data.orderId}} — the URL field supports variables, nothing else to configure for the URL.
3. Add an extractor $.data.id with the orderId context variable: the node copies the received value into context.orderId.
4. The next node (e.g. a Send an email node or a Send AWS SQS node) uses {{orderId}} and {{lastResponse.data.status}} in its fields.

See also

• HTTP Response node
• Condition node
• Error management
• Use authentication methods in workflows