Skip to content
DocsOpen Hub
Node reference

HTTP Request node

On this page

Use an HTTP Request node to call an external service from a workflow. Configure the method, URL, headers, and input body, then pass the named result to later nodes.

Configure the request#

  1. Add HTTP Request and name it for the result, for example FetchCustomer.
  2. Select the method required by the upstream API.
  3. Set its URL, using selectors for environment-specific configuration.
  4. Add enabled headers and any query, form, or body fields required by that API.
  5. Connect it after validation and authorization, then save.
text
Method: GET
URL: ${SERVICE_BASE_URL}/customers/${customerId}
Accept: application/json
Authorization: Bearer ${SERVICE_TOKEN}

This is a configuration example. Replace the route and authentication with the upstream service's actual contract. Ensure a route value is valid and correctly encoded for its position in the URL.

Handle the result#

Reference ${FetchCustomer} in the next node. In Python, customer = ${FetchCustomer} reads its JSON result directly. Inspect a real response before choosing field names: some services return an object, others wrap data in result, data, or a collection.

Set Content-Type to match the body you send. JSON text, form fields, and multipart uploads are different contracts. Avoid sending multiple competing body representations.

Test failures as well as success#

Check invalid credentials, missing records, provider errors, and timeouts. A failed request can stop the workflow before the next node, so do not assume a later Function will always receive an error body to transform.

Use Workflows → HTTP Requests to inspect outbound calls and the workflow session to see where the request occurred. Newer diagnostics can identify DNS, TLS, connection, timeout, and response-processing failures; older logs may contain less detail.

Retry deliberately#

Confirm the node's configured timeout and retry behavior. Retrying a create, email, or payment operation can duplicate its effect. Use the provider's idempotency contract when available and test with fixtures before enabling repeated writes.

Follow the complete service integration guide for a worked pattern.

Need to investigate a problem? Start with troubleshooting