Webhooks

Webhooks push events to your endpoint as they happen, so you do not have to poll the API. For the full delivery contract, payload envelope and verification code samples, see API webhooks. This page is the product-level view: what fires, and what to do with it.

​

Events

​

Subscribing

Under Settings, then Integrations, add an endpoint and choose which events it receives. You get a signing secret at creation. New event types appear in the picker automatically as they ship. Subscribe to what you need. An endpoint that receives everything and discards most of it is an endpoint that will eventually be rate limited by its own noise.

​

Verification

Every delivery is signed. Verify the signature before acting on the payload, and reject anything that fails. Signatures include a timestamp so a captured request cannot be replayed later. Never trust a payload just because it reached your endpoint. See API webhooks for the verification snippet.

​

Delivery

• At least once. A delivery can arrive twice. Every event carries a stable id, so deduplicate on it rather than assuming uniqueness.
• Retried with backoff on failure. Return a 2xx quickly and do the work asynchronously; an endpoint that does slow work inline will time out and be retried, causing exactly the duplicates you did not want.
• Ordering is not guaranteed. Use the event timestamp rather than arrival order.

Delivery attempts and their outcomes are visible in the console, so a failing endpoint is diagnosable without guesswork.

​

Webhooks or triggers

Both act on the same events. The difference is where the logic lives. Most workspaces use both. A trigger to route the conversation, a webhook to tell your own stack it happened.

​

Sending events into Vorel

The reverse direction, your events driving Vorel, is the trigger engine’s generic source. You get a signed ingress URL and a secret. See Triggers.