Webhook triggers reference

A webhook trigger starts a workflow the moment something happens in another system: an invitee books a Calendly event, a payment lands, an issue opens. The other system POSTs an event to a URL Cotera mints for the trigger, Cotera verifies and filters it, and your workflow runs with the event payload as its input.

For the click-through setup, see Kick off from a webhook. This page is the technical reference for how deliveries are handled, and links to the per-provider pages.

The delivery URL and secret

Each webhook trigger gets its own delivery URL, of the form:

https://app.cotera.co/api/triggers/webhooks/<trigger-id>

Cotera also generates a signing secret for that trigger. Treat the URL like a secret — anyone who can POST to it can start a run.

Depending on the provider, the URL is registered for you or you paste it in yourself:

Verifying deliveries

Cotera authenticates every delivery before it runs anything, using the trigger's secret — you don't write any verification code. A delivery that fails is rejected and never reaches your workflow. Providers fall into two camps, and each provider page documents which:

• Signature — the provider signs the request body with the secret and sends the signature in a header (for example GitHub's X-Hub-Signature-256, Calendly's Calendly-Webhook-Signature). Cotera recomputes and compares it.
• URL token — the provider can't sign, so the secret is carried as a token — inside the delivery URL (Gong, Grain), in a header the provider echoes back (Telegram's secret token), or in the delivery body (Lemlist). Cotera timing-safe compares it. Treat these URLs and tokens like a secret.

Event filtering and deduplication

1. Event filtering. A trigger is bound to one event type (for example invitee.created). Deliveries for other event types on the same endpoint are ignored — only matching events start a run.
2. Deduplication. A delivery identical to one already seen for that trigger in the last hour is skipped, so a provider that retries a delivery won't double-run your workflow.

What your workflow receives

The raw JSON body of the delivery becomes the workflow's input. Downstream nodes and your agent read its fields directly — no unwrapping. Each provider page below shows the exact payload shape for its events.

Testing

While building, use the Test webhook button on the trigger to send a signed sample delivery for the selected event through the full pipeline — verification, filtering, and your workflow — without waiting for the real system to fire.

Provider catalog