Skip to main content
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.

​
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:
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 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 to see and copy it, then hand it to the system you are waiting on. To resume the run, that system sends:
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

​
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:
The node’s own timing lives under metadata.wait: (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.
  • 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 or a 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 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 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.

Expressions and filters

Resolve a timestamp from extracted data

Monitoring runs

Find a waiting run and copy its resume URL

Review action

Pause for a person instead of a timer

Webhooks and callbacks

Send data out of a workflow