Webhook
Starts the automation when an external system sends an HTTP request to a URL generated for this trigger. Reach for it when the system you want to react to can call out to you but has no integration of its own—a server, a script, or a device that can do nothing more than request a fixed address.
Fields
| Field | Description |
|---|---|
| Name | What the trigger is called on the canvas. Once the trigger has been saved, everything the sending system needs is shown beneath this field: the Webhook URL and, depending on the authentication scheme, the signing secret or bearer token. |
| Authentication | How the sending system proves it is who it says it is. Signature is the default; see Authentication for the choice. |
| Example Request | A read-only, copy-paste-runnable shell example for this trigger's endpoint, written for the selected scheme. Where a signature is involved it shows the sender computing it from the secret and the exact request, rather than a fixed value, because that is how the signature has to be produced on every request. |
The URL is derived from the trigger and rebuilt on every save, so it survives the server being moved. The first credential is generated the first time the trigger is saved and kept stable afterwards, so the copy held by the sending system stays valid.
Authentication
Pick the scheme by what the sending system can do.
| Scheme | The sender needs | What it sends | Replay protection |
|---|---|---|---|
| Signature | To compute an HMAC-SHA256 | A signature over the request; the secret itself never travels | Built in: a signed timestamp and a unique delivery id |
| Bearer Token | To set a request header | The token, in an Authorization: Bearer header | Optional: a header the sender fills with a value unique to each delivery |
| URL Secret | Only to call a URL | The secret, as the final segment of the webhook URL | Optional: the same per-delivery header, if the sender can set one |
Signature
The sender signs each request following the Standard Webhooks convention: a webhook-id header carrying a unique id for the delivery, a webhook-timestamp header carrying the time in seconds, and a webhook-signature header carrying v1, followed by the base64 HMAC-SHA256 of id.timestamp.body. The signing secret is shown as whsec_…, which the Standard Webhooks client libraries accept as-is. A request whose timestamp is more than five minutes off is refused, and a delivery id that has already been accepted is recorded but not run again.
The older form—an X-Automation-Signature-256: sha256=<hex> header carrying the HMAC-SHA256 of the body alone, keyed by the secret's text—is still accepted, so a sender configured before the standard form was available keeps working. A secret generated before then is shown as it was, and the example request for it uses the older form.
Bearer token
The sender puts the token in an Authorization: Bearer <token> header. If a proxy in front of your deployment already occupies the Authorization header with its own credential, send the token in an X-Auth-Token header instead.
Because the token itself travels with every request, a captured request could be sent again. If the sender can set a header with a value unique to each delivery, name that header in the Deduplication Header field; a second live delivery carrying a value already accepted is recorded but not run.
URL secret
The sender appends the secret to the webhook URL as its final path segment, so the Webhook URL shown beneath the Name field is the whole configuration: a device that can only be told "on this event, request this address" needs nothing else. Anything the sender wants to say goes in the query string; see What later steps see.
The secret travels in the URL, so TLS is what keeps it private. Rotate it if it is ever exposed.
Credentials and rotation
The Credentials node action lists the credentials the trigger accepts—at most two—with what to hand the sender for each, when it was created, and when a delivery last verified against it.
To rotate a credential:
- Click Generate New Credential. Both credentials verify; nothing breaks.
- Move the sending systems to the new one, at your own pace.
- When the old credential's Last used shows nothing still presents it, click Revoke beside it.
Last used is read from the trigger's retained deliveries, so it can tell you a credential was used recently but not that it was never used. If a credential has leaked and it is the only one, click Regenerate: the leaked credential is refused from that moment and a replacement is minted in the same step, so the trigger is never left without one.
Node actions
Once the trigger has been saved, the node's menu offers:
- Fire Test—send a test delivery, presented the way the selected scheme expects, to confirm the wiring end to end. Offered once the trigger holds a credential.
- Deliveries—review past delivery attempts, including ones that were rejected or not run, and replay one.
- Credentials—see, generate, and revoke the trigger's credentials.
What later steps see
The trigger's output is whatever the caller posted as a JSON object—so its shape is not knowable before an event arrives, and the trigger declines to invent one. If the request had a query string, its parameters are added inside the trigger's own _trigger object, so _trigger.query.relay reads a ?relay=on parameter, and a body field named query is left exactly as the sender wrote it. An empty body with a query string is a valid delivery whose output is just _trigger. A body that itself carries a _trigger object keeps its entries, with the trigger's own written over any of the same name; the picker marks the object as the trigger's so it is not mistaken for the sender's data.
A reference into the webhook's payload cannot be checked against a schema, so the editor leaves such references unverified rather than flagging them as broken. Build the flow against the shape you expect, fire a test delivery, and read the real payload back from the run.
Deliveries that do not run
Beyond a disabled or archived automation, the Deliveries screen records two outcomes particular to this trigger: DUPLICATE_DELIVERY, for a live delivery whose id or deduplication value the trigger had already accepted, and rejections such as STALE_TIMESTAMP, MISSING_CREDENTIAL, and INVALID_CREDENTIAL, which name what was wrong with the request rather than leaving it at "401".