# Call an HTTP endpoint from a workflow

> Configure the HTTP Request node, trigger it from an event, and handle its success, error and timeout outputs.

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. Configure the request 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 also has separate URL , Method , Headers , and Body inputs for feeding those parts of the request from other nodes. 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). The start of the error message also appears on the node, next to its Error output. 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 Expose a small authenticated REST endpoint from a workflow Store and rotate connection secrets Troubleshoot a workflow