Wait for Webhook
The Wait for Webhook node pauses your workflow and generates a unique callback URL. When an external system calls that URL, the workflow resumes with the data from the callback. Use it for async patterns where you need to wait for something external to happen.
When to use Wait for Webhook
| Scenario | Why |
|---|---|
| Payment confirmation | Start an order workflow, wait for a payment processor webhook to confirm payment |
| External approval | Send an approval request, wait for the approver to click a link |
| Async processing | Send data to a slow external service, wait for its completion callback |
| Multi-step forms | Wait for the user to complete a second form or action |
How it works
- The workflow reaches the Wait for Webhook node
- Execution pauses; the workflow goes into "waiting" state
- A unique callback URL is generated:
https://hooks.tinycommand.com/wait/wfr_abc123 - You send this URL to the external system (in an email, API call, etc.)
- When the external system calls the URL (via POST), the workflow resumes
- The callback payload becomes available as output variables
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
| Timeout | Duration | No | How long to wait before timing out. Default: 7 days. |
| Timeout action | Select | No | What happens on timeout: Stop workflow or Continue (with empty data) |
| Authentication | Select | No | Require a secret token in the callback request |
| Allowed methods | Multi-select | No | Which HTTP methods are accepted (POST, GET, PUT). Default: POST |
Output variables
When the callback is received:
{{wait_webhook.callback_url}} → the unique URL (available immediately)
{{wait_webhook.body}} → the POST body from the callback
{{wait_webhook.headers}} → request headers
{{wait_webhook.method}} → HTTP method used
{{wait_webhook.received_at}} → timestamp when callback was received
{{wait_webhook.wait_duration}} → how long the workflow was paused
Common patterns
Approval flow via email
Trigger → Transformer (build approval email) →
Send Email (include approve/reject links with callback URL) →
Wait for Webhook (timeout: 48 hours) →
If-Else (body.decision == "approved") →
Approved: Continue workflow
Rejected: Send Email (rejection notice)
The email includes two links:
Approve: {{wait_webhook.callback_url}}?decision=approved
Reject: {{wait_webhook.callback_url}}?decision=rejected
Payment confirmation
Create Order → Send to Payment Gateway (include callback URL) →
Wait for Webhook (timeout: 1 hour) →
If-Else (body.status == "paid") →
Paid: Update order status → Send confirmation email
Failed: Send payment failed email → Retry
Async API processing
HTTP Request (submit job to slow API, include callback URL) →
Wait for Webhook (timeout: 30 minutes) →
Transformer (process the completed results) →
Google Sheets (log results)
Wait for Webhook vs. Delay
| Node | What it does |
|---|---|
| Delay | Waits a fixed amount of time (5 minutes, 2 hours, etc.) |
| Wait for Webhook | Waits until an external event happens (could be seconds or days) |
Use Delay when you know how long to wait. Use Wait for Webhook when you're waiting for something unpredictable.
Wait for Webhook vs. HITL
| Node | Who triggers the resume |
|---|---|
| HITL | A TinyCommand user clicks a button in the HITL interface |
| Wait for Webhook | Any external system calls the callback URL |
HITL is for human review within TinyCommand. Wait for Webhook is for external system integration.
Waiting workflows consume a "slot": you can have up to 100 waiting workflows simultaneously on the Pro plan. If all slots are full, new Wait for Webhook nodes will fail to pause. Monitor your waiting workflows in the execution history.
Always set a reasonable timeout. A workflow waiting indefinitely for a callback that never arrives wastes a slot and can be confusing when reviewing execution history.