> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ingestly.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Wait node
> Pause a run for a fixed duration, until a timestamp, or until an external system calls a resume webhook.
The **Wait** node pauses a run and resumes it later. Use it when the next step should not happen yet: hold an invoice until its due date, give an external system time to settle a record, or park the run until another service says it is ready.
A Wait is a pass-through. It changes nothing about the data flowing through it: the upstream node's `payload` and `metadata` are carried forward verbatim, and the node adds only its own `metadata.wait` block. Whatever the next node could read before the Wait, it can still read after it, at the same paths.
Waiting is free. A Wait step consumes no credits, however long it waits.
## Modes
Choose a **Mode** in the properties panel. The remaining fields change with it.
| Mode | The run resumes when |
| ------------------- | ------------------------------------------------------------------------------------------------ |
| **Duration** | A fixed number of minutes has elapsed |
| **Until timestamp** | A specific instant is reached |
| **Webhook** | An external system POSTs to the node's resume URL, or the timeout elapses (which fails the step) |
### Duration
Set **Duration (minutes)** to how long the run should pause. The value must be between **1 and 43200** minutes (30 days).
### Until timestamp
Set **Wait until** to the instant the run should resume. It accepts either a literal ISO 8601 instant with an offset (`2026-09-01T09:00:00Z`) or a template expression that resolves to one:
```
{{extract.payload.dueDate}}
```
Give the timestamp an explicit offset. A value with no offset (`2026-09-01T09:00:00`) is read as UTC, so a date extracted from a document in another timezone resumes at the wrong local time. Use a [date filter](/guides/expressions#date-filters) upstream if you need to shift it.
If the resolved instant is **already in the past**, the run does not park at all: the step completes immediately and the run carries on.
### Webhook
The run parks until an external system calls back. Set **Timeout (minutes)** to how long to wait before giving up. The value must be between **5 and 43200** minutes (30 days).
When the step parks, Ingestly mints a resume URL for that run and node. Open the Wait step in the [run detail](/runs/monitoring#run-detail) to see and copy it, then hand it to the system you are waiting on.
To resume the run, that system sends:
```bash theme={null}
curl -X POST https://api.ingestly.ai/webhooks/wait-resume/YOUR_TOKEN
```
The request body is ignored. The token in the path is the entire credential, so no API key or signature header is needed.
**The resume URL is a secret.** Anyone holding the link can resume that run. Share it only with the system that will call it back. Ingestly never offers the URL in the data picker for exactly this reason, so a template cannot paste it into a prompt, an HTTP body, or an email.
If nobody calls the URL before the timeout, the step **fails** with "Wait timed out before the resume webhook was called." Wire the node's error output if you want to handle that case rather than fail the run.
## Configuration
| Field | Required | Description |
| ---------------------- | ------------------------------ | ----------------------------------------------------------------------------- |
| **Mode** | Yes | `Duration`, `Until timestamp`, or `Webhook`. Defaults to `Duration` |
| **Duration (minutes)** | When mode is `Duration` | 1 to 43200 minutes. Defaults to 60 |
| **Wait until** | When mode is `Until timestamp` | An ISO 8601 instant, or a template expression that resolves to one |
| **Timeout (minutes)** | When mode is `Webhook` | 5 to 43200 minutes. How long to wait for the callback before failing the step |
## Inputs and outputs
**Allowed inputs:** extract, if, switch, HTTP, loop, variable, validation, reconcile, store, prompt, call workflow, review, another Wait, the connector nodes (Business Central and QuickBooks in any operation, and callback), and the sub-workflow trigger. Maximum one input connection.
**Output:** the upstream node's output, unchanged, plus the `metadata.wait` block below. The node also has an error output port, which fires when a webhook wait times out.
### Referencing a Wait
Because a Wait is a pass-through, reference the upstream data through the Wait node's own name and it resolves at the same paths:
```
{{hold.payload.total}}
```
The node's own timing lives under `metadata.wait`:
| Path | Description |
| ---------------------------------- | ------------------------------------------------- |
| `{{hold.metadata.wait.mode}}` | `duration`, `timestamp`, or `webhook` |
| `{{hold.metadata.wait.parkedAt}}` | When the run parked (UTC) |
| `{{hold.metadata.wait.resumedBy}}` | `timer` or `webhook` |
| `{{hold.metadata.wait.resumedAt}}` | When the run resumed (UTC) |
| `{{hold.metadata.wait.waitedMs}}` | How long the run actually waited, in milliseconds |
(Replace `hold` with your Wait node's actual name.)
The resume URL and its expiry are stored on the step so the run detail can show them, but they are deliberately not offered as reference paths.
## While a run is waiting
* The run's status is **Waiting** and the parked step's status is **Waiting**. Unlike **Review**, this needs nothing from a person: a timer or a webhook moves it forward. See [run statuses](/runs/introduction#run-lifecycle).
* Selecting the parked step in the run detail opens a read-only panel showing the mode, when (or on what) the run resumes, and the resume URL in webhook mode.
* **Cancelling the run** settles the waiting step as Cancelled. The resume URL stops working: a later POST is refused because the step is no longer waiting.
* Resuming twice does nothing the second time. Once the step has resumed, timed out, or been cancelled, further POSTs to the resume URL are refused.
## Testing a workflow with a Wait
**A Wait never parks in a test.** In a [test step](/workflows/editor#test-step) or a [dry run](/workflows/editor#dry-run), the node still resolves and validates its configuration (so a bad timestamp template still fails there), then continues immediately instead of pausing. No resume URL is minted. Only a [live run](/workflows/editor#live-run) actually waits.
This means a webhook Wait cannot be exercised end to end from the editor. Activate the workflow and trigger a real run to test the callback.
## Limits
* A Wait cannot go inside a [Loop](/nodes/loop) body.
* Maximum one input connection.
* Both the duration and the webhook timeout are capped at 43200 minutes (30 days).
## Errors
* **Duration must be between 1 and 43200 minutes**: the Duration field is empty or out of range.
* **A target timestamp is required**: the Wait until field is empty in `Until timestamp` mode.
* **The target timestamp must be an ISO 8601 instant or a template**: the literal value in Wait until is not a valid instant.
* **Webhook mode requires a timeout between 5 and 43200 minutes**: the Timeout field is empty or out of range.
* **Wait target timestamp is not a valid ISO 8601 instant**: the template in Wait until resolved at run time to something that is not an instant. The failing value is named in the error.
* **Wait timed out before the resume webhook was called**: the timeout elapsed with no callback. The step fails and its error output fires.
## Related
Resolve a timestamp from extracted data
Find a waiting run and copy its resume URL
Pause for a person instead of a timer
Send data out of a workflow