The HTTP Request node calls an external HTTP endpoint and hands the result back into your workflow: useful for triggering something on a web-based system, or pulling in a one-off value. It's built for single, one-shot calls; for continuously polling an endpoint, use HTTP Query instead.
Before you begin#
- The endpoint's URL, method, and any authentication it needs.
- If it needs a bearer token or basic-auth password, a secret already created for it.
- Add an HTTP Request node to your workflow.
- Set the URL and Method (GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS).
- Set Content Type to match what the endpoint expects.
- Set a Timeout if the default 30 seconds isn't right for this endpoint.
- If the endpoint needs authentication, set Authentication to Bearer Token or Basic Auth.
Bearer tokens and Basic Auth passwords are always bound to a secret through the same picker used elsewhere in Buttons: there's no field to type a raw token directly. Basic Auth's username is a plain text field; only its password is secret-bound.
Trigger the request and use the result#
Connect an event into the node's Trigger input to fire the request using its configured URL/method, or into Request Object to override the URL, method, headers, and body entirely from elsewhere in the graph. The node exposes:
- onSuccess / onError: events, fired based on the outcome.
- Body: the response body.
- Full Response: status, headers, and body together.
- Error: the error message, if any.
- Status Code: the numeric HTTP status.
Understand timeout and error behavior#
A timeout, a non-2xx response, and a network error are all treated as failures: each sets Error and fires the onError event, with Status Code populated for a non-2xx response (and left empty for a timeout or network failure, since no response was ever received).
Note
This node's own failures don't trigger the workflow-wide error badge described in Troubleshoot a workflow; a timeout or a failed request is a normal outcome the node reports through its own outputs, not a configuration error. Check Error and onError, not the node's border, to catch a failed call.
There's no automatic retry: each trigger makes exactly one attempt. Build your own retry logic downstream (for example, with a Scheduler node re-triggering on a delay) if you need one.
If you get stuck#
What you see | What to try |
|---|
The request never seems to fire. | Confirm something is actually connected to Trigger or Request Object: the node does nothing without an incoming event. |
Authentication fails. | Confirm the bound secret actually holds the value your endpoint expects, not a placeholder: the field only shows the secret's label, not its value. |
A slow endpoint always times out. | Raise the Timeout field: the default is 30 seconds. |
You need to retry a failed call. | Build that logic yourself downstream: this node makes a single attempt per trigger, with no built-in retry. |
The node never shows a red error border, even when calls are failing. | That's expected: check Error/onError on the node's own outputs instead; HTTP failures don't drive the workflow-wide error indicator. |
Where to go next#
