Set up outbound webhooks

Outbound webhooks send signed JSON to your own HTTPS endpoint when registrations, check-ins, refunds, and waitlist activity happen, and when your events are published, updated, rescheduled, cancelled, finished, or sell out, and when a whole recurring series is cancelled. You configure endpoints under Settings → Integrations → Webhooks, and they are available on the Growth plan and above.

Before you start

You need an Owner or Admin role on the team, because only owners and admins can create, edit, disable, enable, rotate, or remove webhook endpoints. You also need a public HTTPS URL that your server can receive requests at. Plain HTTP URLs and private, loopback, or link-local hosts are rejected at save time.

Webhooks are included on the Growth plan (1 endpoint) and Pro plan (10 endpoints). On the Free and Essentials plans, the Webhooks form stays locked until you upgrade.

Add an endpoint

1. Go to Settings → Integrations.

2. Open the Webhooks card and click Add endpoint.

3. Enter your endpoint URL in the Endpoint URL field. It must be a public HTTPS URL.

4. Optionally enter a Label (up to 100 characters) to identify the endpoint, such as your CRM's name.

5. Under Events to deliver, select at least one event. New endpoints select all 19 event types by default; clear any you don't want.

6. Click Add endpoint.

After you save, Eventually shows your signing secret once, with a Copy button. Copy it immediately, because it is not shown again in the normal endpoint view. The only way to see a new secret is to rotate it.

Send a test event

Use Send test event to confirm an endpoint accepts deliveries before you rely on it. It sends a signed ping event through the same delivery path as live events, shows the receiver's HTTP response, and logs the test in Recent deliveries as a ping row carrying the same delivery ID sent to your receiver.

Every test creates a row, even when the delivery fails. A 2xx response is recorded as one delivered attempt, shown as DELIVERED with the HTTP status beside it, the delivery timestamp, and a Show response control that opens an excerpt of what your server sent back. A non-2xx response is recorded as one failed attempt, shown as FAILED with the HTTP status. A rejected or unreachable target is also recorded as one failed attempt, shown as FAILED with the corresponding error message instead of a status, rather than being left out of the log.

If Recent deliveries is already open, it refreshes after the test response so the new row appears without a page reload. A closed drawer stays closed. A throttled test sends nothing and logs no row.

Test events are limited to 10 per minute, counted per client IP and per team, so spreading the clicks across members or machines does not raise the cap. Past the limit you see Too many test events, wait a minute and try again.

Edit an endpoint

To change an endpoint's URL, label, or event selection, click Edit on the endpoint, make your changes, and click Save changes. Editing an endpoint does not change its signing secret.

Every event type is opt-in per endpoint, including the six event lifecycle types (event.published, event.updated, event.rescheduled, event.cancelled, event.completed, and event.sold_out), and series.cancelled. An endpoint you created before those types existed is not subscribed to them automatically. Open Edit, select the ones you want under Events to deliver, and save.

Rotate the signing secret

Rotate the secret when you suspect it was exposed or you lost the original. Click Rotate secret on the endpoint. The new secret is shown once, so copy it immediately. After rotation, deliveries are signed with the new secret, so update your receiver to match.

Disable and enable an endpoint

Click Disable to stop deliveries to an endpoint without deleting its configuration. Disabled endpoints stop receiving events until you click Enable to turn them back on.

Recent deliveries

Each endpoint keeps a 30-day delivery log, visible under Recent deliveries on the endpoint in Settings → Integrations. The panel shows the last 25 rows, newest first. Each row is one published event: its type, its state, the attempt count, and the timestamp. Retries update the row in place rather than adding new rows.

The state sits beside the HTTP status your server returned, so a delivered row reads DELIVERED · 200 and a failed one reads FAILED · 503. The four states are:

• DELIVERED: your server answered with a 2xx status.

• FAILED: your server answered with something other than a 2xx status, or could not be reached.

• PENDING: the delivery is queued and has not been attempted yet.

• SKIPPED: nothing was sent, and the row names the reason. The endpoint is disabled, webhooks are not enabled for your account, or the endpoint is over your plan's endpoint limit.

Use Show response on a row to read what your server sent back. The log keeps the first 255 characters of the response body.

Redeliver an event

Use Redeliver on a logged event to re-send it through the normal delivery pipeline. Only Owners and Admins can redeliver, and the endpoint must be enabled. Redelivery reuses the same X-Eventually-Delivery-Id and follows the same retry and automatic-disable rules as a live delivery.

A skipped row can be redelivered once the reason it was skipped is gone, so a delivery skipped while your account was not entitled to webhooks can be sent as soon as your plan covers it.

Redeliveries are limited to 10 per minute, counted per client IP and per team, the same way test events are. Past the limit you see Too many redeliveries, wait a minute and try again.

Test pings and redeliveries of a test ping are the exception: they do not change the endpoint's failure streak, its last-delivered timestamp, or the health state that controls automatic disabling. A failed test does not count against the endpoint, and a successful one does not clear a failure streak recorded by live deliveries.

Remove an endpoint

Click Remove to delete an endpoint and stop all deliveries to it. Eventually asks you to confirm first. The endpoint's signing secret and its delivery log are removed with it, and a removed endpoint cannot be restored, so only remove one you no longer need.

Plan caps and over-limit endpoints

Your plan caps how many endpoints you can configure: 1 on Growth and 10 on Pro. The Webhooks card shows how many endpoints you've used out of your cap.

If you downgrade to a plan with a lower cap, your existing endpoints stay configured but deliveries to the endpoints over the new cap are paused until you upgrade or remove endpoints. Those deliveries appear in the log as SKIPPED with the limit named as the reason. You can re-enable delivery by removing other endpoints or upgrading your plan.

When an endpoint fails to respond, Eventually retries and then automatically disables it after repeated failures. See Troubleshoot outbound webhooks for what to do.