Webhook node reference
Send visitor data to another system when someone reaches a flow step. You'll find webhook settings, payload fields, delivery limits, and log statuses here.
A Webhook node sends visitor data to an HTTPS endpoint when someone reaches that step in your flow. You can include extra context and check delivery logs to see whether the receiving system accepted it.
When to use it
Use a Webhook when another system needs the data available at a particular flow step. Put it after the steps that collect the information you need. Anonymous visitor data can lack an email address.
This node is separate from a form's Send a webhook submission action. To send data collected by a form, use its form action. Ordinary nodes below a terminal form don't handle its submission.
Settings
| Setting | What it does | Default |
|---|---|---|
| Friendly Name | Gives this webhook step an internal label. | Blank |
| Webhook URL | Sets the HTTPS endpoint that receives the payload. A non-HTTPS value shows a warning. | Blank |
| HTTP Method | Chooses POST, PUT, or PATCH. | POST |
| Only fire once per visitor | Prevents this node from firing again for the same remembered visitor. | On |
| Additional Context | Adds optional JSON under the payload's meta key. | Blank |
| Payload preview | Expands a preview of the generated request data. | Collapsed |
The stored timeout defaults to 10,000 milliseconds. There's no timeout control in the editor, and this default doesn't guarantee how long your receiving system takes to process a request.
Additional context and template variables
Additional Context must be valid JSON. If it can't be parsed, the editor shows Invalid JSON and the error. The editor lists these template variables:
visitor.emailandvisitor.id.flow.idandflow.node_id.page.url.segments.KEY.variables.KEY.
For example, this Additional Context uses a fixed source label and the current flow's ID:
These placeholders use the webhook's listed template names. They aren't the same as the singular variable.NAME Liquid namespace used in flow messages. Quote placeholders when they represent JSON strings. Check the received meta value, especially when visitor data contains quotes or other JSON-sensitive characters.
Payload fields and signatures
| Standard payload field | Value |
|---|---|
event | webhook_action |
flowId, nodeId | The flow and node IDs |
pageUrl | The page URL |
timestamp | The event timestamp |
visitor | Visitor context, including id, email, and segments |
Scores, variables, custom fields, and tags are included when present. Segment output uses readable group and segment names where the published configuration can resolve them.
Additional Context adds meta. It doesn't replace the standard payload. The preview uses sample visitor values and selected flow names, not the current visitor's real record. It helps you check configuration, but doesn't confirm that a destination received a request.
Requests use the X-RightMessage-Signature HMAC-SHA256 signature. Your receiving service should verify it with the project's webhook secret. Keep the secret out of screenshots and Additional Context. See the webhook payload and signature reference.
How visitors move through it
The node sends once per remembered visitor by default. Turn off Only fire once per visitor to allow later executions to send again. The check uses the project, node, and visitor identity. It doesn't identify a person across every browser or guarantee exactly one delivery after storage is cleared or their identity changes.
The flow continues after the action. Reaching a later screen doesn't confirm that the destination received the webhook.
Normal builder previews suppress external webhook delivery. Follow the authorized testing workflow before testing actions in your receiving system.
Things to know
Allowed destinations and delivery limits
The destination needs HTTPS and a hostname that resolves to a public address. Localhost, private or reserved addresses, unresolved hostnames, and literal IP destinations aren't suitable webhook URLs. The server enforces these restrictions as well as the editor's warning.
The relay allows 10 calls per visitor per project in a 60-second window. All webhook nodes share that allowance. A rate-limited request doesn't reach your endpoint.
Requests use JSON and your selected POST, PUT, or PATCH method. A 2xx response from the destination counts as success. A non-2xx response or timeout counts as failure. The relay accepting a request from the browser doesn't mean the destination accepted it. Check delivery logs alongside the receiving system's records.
The editor doesn't offer a retry schedule, custom request headers, or a timeout field.
Delivery logs
Logs loads delivery records the first time you open it. The refresh button requests an updated list. Rows show the time, status, HTTP code, duration, and visitor. Expand a row to see Request Payload and response details, including the error and target URL when available.
| Status | What it means |
|---|---|
| Success | The endpoint returned a successful HTTP response. |
| Failed | The outbound request failed or returned a non-success response. |
| Skipped | The once-per-visitor check may have found an earlier delivery. |
| Rate Limited | The shared visitor allowance blocked the request. |
Other validation or configuration statuses can appear under their raw names. Check the row details to see what happened.
A missing HTTP code isn't the same as a 4xx or 5xx response. Open Response to check the error and target URL, and Request Payload to check the data sent. The log view has no replay button or complete response-body viewer.
The editor can show No webhook deliveries yet. after a log-fetch failure, as well as when there are no records. Refresh the logs and check your receiving endpoint before concluding that the node never fired.