# 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.

Available on the Pro plan.

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](https://rightmessage.com/help/form-actions-reference). Ordinary nodes below a terminal form don't handle its submission.

## Settings

![WorkForge webhook configuration with HTTPS URL, POST method, once-per-visitor delivery, and additional context](https://rightmessage.com/help/screens/flows-webhook-settings.light.webp)

| 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.email` and `visitor.id`.
- `flow.id` and `flow.node_id`.
- `page.url`.
- `segments.KEY`.
- `variables.KEY`.

For example, this **Additional Context** uses a fixed source label and the current flow's ID:

```json
{
  "source": "workforge_assessment",
  "flow": "{{ flow.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](https://rightmessage.com/help/webhook-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](https://rightmessage.com/help/best-practices-for-testing) 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.