Skip to main content
The callback node sends pipeline results to an external URL via an HTTP request. It is a terminal node: no action node runs after it. The one exception is another callback, which can chain after it to reuse its response (see Chaining callbacks). Use callbacks to integrate Ingestly with your backend systems, databases, or third-party services.

​
Configuration

Transient delivery failures are retried automatically by the platform. Use the node’s retry field to set the maximum number of attempts, between 1 and 5 (default 3).

​
Creating records from a reconcile result

With the JSON body format, click Generate from reconcile above the body editor to insert a starter body. The scaffold contains a header field and one $each row template per reconcile Expected extras label, plus a default template for unlabeled rows. Rename the example fields to your connector’s field names and the body posts the reconciled lines as one create request.

​
Write-back with

With the OData Batch body format, the body can embed the {{reconcileWriteback}} token. At run time the token expands into the batch operations that write the approved reconcile values back to the connector record (changed fields are updated, classified extra lines are added). Click Insert write-back above the body editor to insert the minimal body:
The token can also sit inside the operations array next to static operations you author yourself; the generated operations are spliced in at the token’s position. When the body contains the token, the write-back panel appears with the following fields: Two safety behaviors apply:
  • If the reconcile result has a blocking mismatch and no approved review, the step fails instead of writing
  • If nothing changed (an empty write set) and the body has no static operations, the step succeeds without sending a request
The Connector Write-back and Create record body formats still run on pipelines that were saved with them, and they appear in the format picker marked (legacy) on those nodes. New pipelines use the JSON and OData Batch formats described above.

​
Binary body

Set Body format to Binary (base64) to send the request body as raw bytes instead of JSON. 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 resulting bytes as the request body.
  • The content type defaults to application/octet-stream. Set a Content-Type header to override it.
  • GET and DELETE requests never send a body.
  • If the resolved body is not valid Base64, the step fails with a clear error instead of sending malformed bytes.
The raw bytes and the Base64 text are never persisted: the request history records a binary body as [binary N bytes, type]. A binary body is how you upload a file to a system that expects raw bytes, such as the Business Central attachmentContent endpoint. See the attachment recipe.

​
Chaining callbacks

A callback is terminal for action nodes, but you can connect one callback to another callback. The downstream callback runs after the first one returns and can reference its response. This is how you use a value that only exists after the first call completes, such as the id of a record the first callback created. Reference the previous callback’s response through its node name, using the same path syntax as any upstream node:
  • A callback’s payload is the response body. Request-level fields such as the status code ride under metadata.callback.
  • For a plain JSON response, read a field directly: {{<callbackName>.payload.id}}.
  • For an OData Batch response, the body is a responses array with one entry per operation, each shaped { id, status, headers, body }, where id echoes the operation’s contentId and body is that operation’s result. Index into it: {{<callbackName>.payload.responses[0].body.id}}.
Give the record-creating batch operation a contentId so you can tell which responses entry is the one you want.

​
Dry run behavior

On a Dry run, the callback node does not send the HTTP request. Instead, the run output shows a preview with:
  • The resolved request URL
  • The resolved request headers
  • The rendered request body
For a Connector Write-back callback, the dry-run preview shows the prepared request that would be sent, rendered in a read-only JSON editor.
Use a dry run to verify callback templates before you send live outputs.

​
Inputs and outputs

Allowed inputs: Any action node that produces a result payload (extract, review, validation, transform, merge, parse, HTTP, loop, variable, store, prompt), and another callback node (see Chaining callbacks). Filter and split are not among them: they emit page groups, not a result to send, so put the node that produces the data between them and the callback. Output: Sends an HTTP request to the configured URL with the pipeline results. The node is terminal for action nodes, but its response can feed one more callback.

Webhooks and callbacks guide

Payload format, verification, and integration patterns

Webhook signing keys

Verify webhook signatures for security

Email output

Deliver results via email instead

Transform action

Transform data before sending via webhook

Business Central guide

Connector write-back and OData batch requests