A Webhook node parks a run until an external system posts to that run’s
callback URL. It is a resume mechanism, not a trigger.
There is no per-workflow HTTP endpoint that starts a run. Workflows are started
from the Portal, from the Management API, or from an agent or gateway that has
the workflow attached. The webhook below only resumes a run that is already
waiting.
The callback
run_id — the run that is waiting.token — a random bearer token minted per wait. Not an API key, not
reusable across runs.
The route is unauthenticated in the routing sense; the token is the credential.
Responses:
The 400 message is deliberately opaque — it does not distinguish a bad token
from an expired wait from a run that already moved on.
Timeout
The node’s timeout is a timeoutValue plus a timeoutUnit (minutes,
hours, days), defaulting to 24 hours.
A timeout does not fail the run. The node returns
and the graph continues. Branch on webhook_received when the difference
matters — otherwise a timed-out wait looks exactly like a successful one to
everything downstream.
Shape of the pattern
Kick off the external work, park, and let the other side tell you when it is
done — rather than polling.
Handling secrets
The callback token is generated for you and travels in the URL. You do not
configure it and should not try to.
If the outbound call — the one that tells the external system where to post
back — needs a credential, make it through a
connector. A workflow definition has no secrets
store; anything you type into a node is stored in the definition and readable by
anyone with write access to it.
Next
