Call any REST API endpoint. Use this node to integrate with external services, fetch data, or trigger actions in other systems. The node editor separates query params, headers, body, and auth into dedicated tabs so complex requests are easier to manage.
Status: Alpha.
Request configuration
The node body has a method selector fused with the URL field, plus four tabs.
| Setting | Description | Default |
|---|---|---|
| Method | HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) | GET |
| URL |
The endpoint to call; must start with http:// or https:// |
— |
| Params | Query-string key/value rows; toggle individual rows on or off | — |
| Headers | Header key/value rows with common presets; toggle rows on or off | — |
| Auth | Auth strategy (None, Basic, Bearer, API Key) | None |
| Body | None, JSON, Form, or Text | None |
Query params are appended to the URL and merged with any query string already on it.
Node settings
The settings sidebar adds request options:
- Follow Redirects — follow HTTP redirects (on by default). When disabled, the node shows a “No redirects” badge on the canvas.
-
Include Response Headers — include response headers in the output (off by default).
Authorization,Set-Cookie, andCookievalues are redacted. -
Declared outputs — declare typed output ports over the
response(for example, fields of the body): extract values, parse non-JSON bodies, attach a schema, and pick the mismatch policy. Strict fails the node when the response does not match.
The gear button (“Execution & runtime”) in the sidebar header opens settings every node shares:
- On Failure — what happens when this node fails: Stop (default), Continue, or Continue (pass error output).
- Run even if upstream failed — execute this node even when upstream nodes failed (off by default).
- Timeout (ms) — node-level timeout; defaults to 60000 for this node.
- Retry on Failure — retry the node when it fails (off by default), with max attempts (1–10, default 3), retry delay (default 1000 ms), and linear or exponential backoff.
Inputs
| Input | Type | Description |
|---|---|---|
| url | string | Optional override of the configured URL |
| body | object | Optional override of the configured body |
Both ports are collapsed by default — expand them on the node to wire values from upstream nodes. A wired value overrides the corresponding field in the node’s configuration. Method, params, and headers are configured in the node itself; use {{ }} templates to make them dynamic.
Outputs
| Output | Description |
|---|---|
| response.status | HTTP status code |
| response.body | Response body (parsed when the API returns JSON; binary bodies are base64-encoded) |
| response.headers | Response headers as key/value rows — only when Include Response Headers is enabled |
A non-2xx response fails the node, so response only carries successful statuses. The failure message includes the status code and an excerpt of the response body. Use On Failure when a failing status is expected and the run should continue.
Body formats
Choose a body type on the Body tab:
- None — no body
- JSON — JSON-encoded body, edited as text with template support
-
Form — form-style text such as
field=value&other=value - Text — raw string body
Using variables
Configuration fields accept {{ }} templates. Reference a wired input by its handle name, or any previous node’s output as nodes.<node-id>.<path>. The URL and body editors include an insert-variable picker that inserts these tokens at the cursor.
In URL:
https://api.example.com/users/{{nodes.fetch-user.response.body.id}}In Headers:
Authorization: Bearer {{nodes.get-token.response.body.access_token}}In Body:
{
"email": "{{nodes.fetch-user.response.body.email}}"
}
Templates can also embed expressions, for example {{ upper(name) }} or {{ default(nodes.n1.response.body.tag, "n/a") }}.
A reference that does not resolve — a missing node, a typo, or an upstream that produced no output — fails the node before the request is sent, so the literal {{...}} text never reaches the API.
Authentication
Pick a strategy on the Auth tab. This node does not use saved Connections — credentials are supplied per request. Common patterns are easy to model directly with headers or query params, especially when values come from previous nodes:
Bearer token:
Authorization: Bearer your-token-hereAPI key in header:
X-API-Key: your-api-keyBasic auth:
Authorization: Basic base64-encoded-credentialsTroubleshooting
Any non-2xx status fails the node; the error message names the status and quotes the response body.
400 Bad Request
- Check the JSON body is valid
- Verify required fields are included
-
Ensure the Content-Type header is set (usually
application/json)
401 Unauthorized
- Verify the API key or token is correct
- Check the Authorization header format
- Ensure credentials have not expired
403 Forbidden
- The API key may lack required permissions
- Verify IP allowlists if applicable
404 Not Found
- Double-check the URL
- Verify path parameters are correct
Timeout errors
- Increase Timeout (ms) under Execution & runtime
- Check if the API is slow or unresponsive
Failure on a 3xx status
- Check whether Follow Redirects is disabled
- The failure message names the redirect target