Watch the tutorial

The Async Callback Node pauses a workflow and waits for an external system to call back via a webhook before continuing. It is designed for integrations where the external process is long-running — the workflow sends a request to a third-party system (typically through a preceding Action Node), and that system calls back hours or days later when its work is done. The workflow remains in an "in progress" state until either the callback arrives or the configured timeout expires.

Each Async Callback Node generates a unique webhook URL that the external system uses to notify the workflow.

---

When to Use

Use an Async Callback Node when your workflow requires:

• Waiting for an external system to complete a long-running operation (e.g., a background check, a provisioning request, a third-party approval).
• Receiving structured data back from an external system once its processing is complete.
• Integrating with systems that use a fire-and-forget + callback pattern rather than synchronous request/response.
• Any scenario where the time between initiating an external action and receiving its result is unpredictable — minutes, hours, or even days.

---

Configuration

Webhook URL (Auto-generated)

When the node is created, the system generates a unique slug that becomes part of the webhook URL external systems use to send their callback. Share this URL with the external system during your integration setup.

Identification

Identification defines how the system matches an incoming callback to the correct waiting workflow instance. This is the most critical part of the configuration — without it, the system cannot determine which workflow execution the callback belongs to.

Where to look for the identifier:

Param Key — the field name or path within the selected source to extract the identifier value. For example, if the external system sends { "ticketId": "ABC-123" } in the body, set the param key to ticketId.

Data Centre Param — a Data Center expression that resolves to the same identifier value at the time the workflow first reaches this node. For example, if the preceding Action Node created a ticket and stored its ID, you'd reference that ID here. The system stores this value and later uses it to match the incoming callback.

When the callback arrives, the system extracts the identifier from the request and matches it to the stored value to find and resume the correct workflow instance.

Authentication

The callback endpoint supports two authentication modes:

Timeout

The timeout defines how long the workflow will wait for the callback. If the callback does not arrive within this window, the node is treated as a timeout.

For example, setting the type to Hours and value to 48 means the workflow will wait up to 2 days for the callback.

Output Mapping

The Async Callback Node supports mapping data from the callback response to form fields or global constants. Each entry maps a value from the callback payload to a target in the workflow.

This allows data from the external system's response to flow into subsequent workflow steps — for example, mapping the external system's status or result into a form field that an approver sees in the next step.

Failure Handling

Fail Workflow Item — when enabled, if the callback times out, the entire workflow item can be marked as failed (in combination with the Trigger Node's failure setting).

Remove Failure Handle — controls the node's output handles on the canvas:

Masked Fields

You can specify fields that should be masked in execution logs and audit trails, useful for sensitive data in the callback payload.

Progress Path

The node can optionally be hidden from the end-user progress tracker if it represents an internal integration step.

---

How It Works at Runtime

Workflow Pauses

When the workflow reaches the Async Callback Node, the system resolves the identifier from the Data Center, stores it along with the timeout deadline, and pauses the workflow. If the identifier cannot be resolved, the node is skipped.

Callback Arrives

When the external system sends a POST request to the webhook URL:

1. The system identifies the node by its slug and extracts the unique identifier from the request.
2. It matches the identifier to the waiting workflow instance.
3. The callback payload is stored and any configured output mappings are applied.
4. The workflow resumes and follows the Success path.

Timeout

If the callback does not arrive before the deadline:

1. The node is marked as failed.
2. If Fail Workflow Item is enabled, the entire workflow item is marked as failed.
3. Otherwise, the workflow follows the Failure path (if connected).

Identifier Sync

If workflow data changes while the node is waiting (e.g., a parallel branch updates a value), the system can automatically re-evaluate the identifier to ensure the callback can still be matched correctly.

---

Best Practices

• Always configure a meaningful unique identifier. The identifier must be something that both your workflow and the external system know — typically a ticket ID, request ID, or transaction reference generated by the preceding Action Node.
• Set a realistic timeout. Consider the external system's expected processing time and add a reasonable buffer. For background checks, this might be days; for provisioning requests, it might be hours.
• Use the Failure handle for timeout scenarios. Design a failure path that handles timeouts gracefully — for example, sending a notification, retrying the action, or escalating to a human.
• Use OAuth (Slug auth) for external integrations. This is more secure than platform session auth for system-to-system callbacks.
• Map critical response data to form fields. If the external system returns status, results, or reference numbers, map them so they're visible in subsequent Input or Approval steps.
• Consider removing the Failure handle only when timeouts are truly non-critical. If the external system is guaranteed to call back (e.g., an internal service with an SLA), you can simplify the canvas.
• Use masked fields for sensitive callback data. If the external system sends tokens, personal data, or credentials in the callback payload, add those fields to the masked fields list.