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 pipeline 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-pipeline.
  • 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-pipeline calls whose response you’ll keep using.

​
Configuration

​
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.

​
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.

​
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