Skip to main content
The HTTP action node sends a request to an external HTTP endpoint and makes the response available to downstream nodes. Use it to enrich workflow data with external APIs, trigger third-party services, or fetch reference data during processing.

​
When to use HTTP action

  • You need to enrich an extracted record with data from your own backend, a CRM, or a public API mid-workflow.
  • You want to trigger an external workflow before continuing (create a ticket, post a notification, kick off downstream processing in another system).
  • You need to fetch reference data that varies per run (a customer ID, a tax rate, a currency conversion) and feed it into a downstream transform or validation step.
  • Use the callback output instead when the goal is just to deliver final results at the end of the run; HTTP action is for mid-workflow calls whose response you’ll keep using.

​
Configuration

In a dry run, a GET is still sent and the step returns the real response, so the nodes downstream of a lookup can be tested. POST, PUT, PATCH and DELETE return a preview of the request instead of sending it.

​
Template expressions

The URL, headers, and body fields support template expressions using the {{expression}} syntax. This lets you dynamically build requests using data from upstream nodes.

​
Authenticating to any API

Select a connector on this node to authenticate the request without exposing credentials in the workflow configuration. An API Key, Basic Auth, OAuth 2.0, OAuth 2.0 (Client Credentials), or Business Central connector all carry a Base URL: selecting one prefixes the URL field with it and adds the connector’s credentials to the request automatically, whether that means a header, an Authorization value, or a bearer token. See Connectors for how to set one up.

​
Response path

If the API returns a large response and you only need part of it, use the response path to extract a subset. For example, if the response is { "data": { "results": [...] } }, set the response path to data.results to pass only the array to downstream nodes as payload.

​
Required result path

Required result path is a guardrail, not an extractor. Where Response path only narrows the output and yields null when it does not resolve, Required result path fails the step when no record is present at that path (missing, null, or an empty array). The two are independent and can be set together. For an OData list response shaped like { "value": [...] }, set Required result path to value so a run with zero records fails fast with a no-records error instead of passing an empty result downstream.

​
Detect from response

Next to the Response Schema field, use Detect from response to build the schema from a real request instead of typing it by hand. It sends an actual request and derives the schema from the response, prompting you for a test value for each dynamic token in the URL and body (headers are excluded). The detected schema populates the Response Schema editor so downstream nodes can reference fields under payload.
Detect from response sends a real request. For non-GET methods (POST, PUT, PATCH, DELETE) this may create or modify real data on the target system.

​
Retries and duplicate requests

A timed-out or transport-failed request is retried under the node’s retry settings. Because a request can time out after the endpoint already received it, a retry can deliver the same call twice. To make that safe, Ingestly sends a stable Idempotency-Key header (ingestly-<step execution id>) on POST requests. The value is the same on every attempt of the same step, so an endpoint that honors idempotency keys can recognize the repeat and avoid creating a duplicate record. The key is not sent when you set an Idempotency-Key header yourself, or on an OData $batch body (which the target rolls back as one snapshot).
PUT, PATCH, and DELETE requests are not sent an idempotency key. If your endpoint ignores idempotency keys, or a PATCH is not safe to apply twice, set Retry attempts to 1 on that node so a timeout fails the step instead of re-sending it.

​
Binary body

Set Body format to Binary (base64) to send the request body as raw bytes. The body template must resolve to a Base64 string, typically exactly {{$document.file.base64}} (the source document).
  • Ingestly decodes the Base64 string and sends the bytes as the request body for POST, PUT, and PATCH. GET and DELETE never send a body.
  • The content type defaults to application/octet-stream. Set a Content-Type header to override it.
  • A resolved body that is not valid Base64 fails the step with a clear error.
The bytes are never persisted; the request history records a binary body as [binary N bytes, type]. To upload the source file to Business Central, see the attachment recipe.

​
Inputs and outputs

Allowed inputs: All trigger nodes and all action nodes. Output: The HTTP response. The node’s data lives in payload and request-level fields are under metadata.http. payload - the response body data: metadata.http - request-level information:

Callback output

Send final results to a webhook after processing

Extract action

Extract structured data before or after HTTP calls

Transform action

Transform HTTP response data into a specific format

Webhooks and callbacks

Guide to working with external integrations