Skip to content

API Call

Calls a specific endpoint on one of your Connections. Internally this is routed through the OneHazel gateway, which applies the Connection's credentials, enforces the connector's schema, applies rate limits, and captures the request/response for the execution log.

Every API call to a configured service goes through this node. If you need to call a generic HTTP endpoint without a Connection, use HTTP Request instead.

When to use

  • You have a Connection set up (Stripe, Postmark, HubSpot, etc.) and want to call one of its operations from inside a workflow.
  • Examples: "Create a Stripe charge." "Send an email via Postmark." "Look up a HubSpot contact by email."

Configuration

FieldRequiredWhat it does
connectionIdYesWhich active Connection to use. Only active connections appear — configure credentials first in the Connections tab.
operationYesWhich endpoint on that connector to call. The dropdown lists every operation exposed by the connector's OpenAPI spec.
operationParamsAuto-rendered once operation is picked. One input per path/query/body/header parameter.

Parameter fields

After you pick an operation, OneHazel auto-renders the required and optional parameters. Each is prefixed with its location:

  • path_X — goes into the URL path (e.g. /customers/{id}path_id)
  • query_X — appended as ?X=… query string
  • body_X — sent in the JSON request body
  • header_X — sent as a custom HTTP header

Every parameter field is a data reference field — you can pipe values from earlier nodes with {{...}} syntax. Click the branch icon on the right to open the data picker.

Connection defaults show up as placeholder hints on the relevant fields. If you set Authorization: Bearer xyz as a default on the Connection, the header_Authorization field will show default: Bearer xyz (from connection) and leaving it blank uses the Connection's value.

What it outputs

{
  status: 200,
  success: true,
  data: <parsed response body>,
  request: { method, url, headers, body },
  latencyMs: 142
}

Downstream nodes can reference fields on the response body via {{<node_id>.data.<path>}}. The request object is included so debugging failed calls is straightforward — sensitive headers are masked.

On failure

If the gateway returns a 4xx/5xx status, this node throws an error and its branch terminates. To catch the failure and route it to a different branch, wrap this node in a Try/Catch or Retry block.

Gotchas

  • connectionId must be active — disconnected Connections won't appear in the dropdown and will 404 at runtime if you paste in a stale ID.
  • Some connectors embed credentials in the base URL itself (Telegram uses /bot{token}). The gateway substitutes those placeholders automatically from your Connection's credentials — you do not set them as parameters.
  • The gateway has per-connection rate limiting. If a 429 comes back, the response includes data.error.retryAfterMs. A Retry node is usually the right way to handle it.