Wait for an External System
The Webhook node holds the conversation open until something outside Chatleadr calls back, then carries on with whatever that call sent.
Use it when a workflow has handed work to another system and the answer does not come back in the same breath. A payment that has to clear, a quote a human approves, a stock check that queues. An API Request node covers everything that answers immediately; this covers everything that does not.
The panel behind the gear.
How It Works#
Three steps, and the first one is not this node.
- An API Request node earlier in the workflow tells your system where to reply. Send
{{execution.callbackUrl}}in the body. It is in every node's variable list and resolves when the workflow runs. - The Webhook node parks the workflow. The visitor sees the bot appear to be thinking. Nothing else in the workflow advances.
- Your system POSTs to that address. The workflow wakes and leaves through Received, carrying the payload. If nothing arrives in time it leaves through Timed out instead.
The address is unique to one run of one workflow and stops working the moment the run moves on, so a replayed call cannot restart a conversation that has finished.
Wait Up to (Seconds)#
Between 1 and 900, defaulting to 30. The value is clamped on the server, so a number typed past the limit is brought back inside it rather than rejected.
The visitor is blocked for the whole wait. They are not told why, and on the web they are watching a typing indicator the entire time. Fifteen minutes is available for approvals that take that long. Long waits suit WhatsApp, where a reply arriving later in the day is normal; on the web, keep it under a minute.
If the Visitor Says Something While Waiting#
Optional. A visitor who types during the wait gets this back, once for each thing they write. Leave it blank and the bot stays quiet.
It accepts {{variables}}, so it can use what the workflow already knows rather than reading like a hold message. "One moment Sam, I'm confirming that with the warehouse" lands very differently from silence.
How Your System Sends the Token Back#
| Mode | The callback address |
|---|---|
| In the address | .../hooks/<token>, different for every run. The default |
| In the request body | One fixed address, with the token as a field you name |
In the address is the recommendation and needs no setup. Your system replies to whatever {{execution.callbackUrl}} gave it.
In the request body exists for gateways that accept one webhook address, set up once in their dashboard, and will not vary it per request. Choose it and the panel shows you the fixed address to register and hands you {{execution.callbackToken}} to send in the body under a key you choose.
Save Values From the Callback#
Maps fields out of the payload into workflow state, exactly as an API Request node does. A path of data.status becomes a variable you can branch on.
Map nothing and the whole payload is saved to <Node name>.payload instead, so the data is never lost while you are still working out its shape.
Anything That Arrives Continues#
Every payload that reaches the address leaves through Received. Validate it in the node after this one: the caller is outside Chatleadr, so a rule set in this panel could not be enforced.
A Function node or a Decision node is where to check it. If your provider signs its webhooks, the signature headers are among those kept, so you can verify them there.
Ports#
| Port | Taken when |
|---|---|
| Received | A callback arrived before the deadline |
| Timed out | It did not |
Connect both. A Webhook node with nothing on Received does not park at all: there is nowhere to continue to, so the run ends there and the visitor is left waiting for a reply that is never coming.
Variables It Produces#
Whatever you mapped, plus <Node name>.payload when you mapped nothing.
{{execution.callbackUrl}} and {{execution.callbackToken}} are published at the start of every run, so they are available before this node rather than because of it.
Practical Notes#
Say something before you park. A Message node immediately before this one turns a silent wait into an explained one.
Prefer a short wait and a graceful timeout. A Timed out branch that says "this is taking longer than usual, I will message you when it lands" is better than a visitor watching a typing indicator for ten minutes.
Test it with the timeout short. Set it to 5 seconds, confirm the Timed out branch reads well, then set it to what you actually need.
Common Questions#
Can Two Systems Call the Same Address?#
They can, but only the first arrival matters. The run resumes once, and the token stops working after it.
What Happens If the Callback Is Late?#
It is discarded. The run has already left through Timed out, and the token is inert. If late answers are normal for your provider, raise the wait rather than relying on a second attempt.
Does the Wait Cost a Conversation?#
No. A conversation is billed when it starts, and again for each additional hour it stays open. See what counts as a conversation.
Why Not Use a Delay Node?#
A Delay waits for the visitor or for a fixed duration. It has no way to be woken by another system, so a workflow using one would carry on whether the work had finished or not.