Troubleshoot outbound webhooks

Most webhook problems come from endpoints that don't meet the delivery requirements or that have been automatically disabled after repeated failures. Match your symptom below for the cause and fix.

What the delivery states mean

Recent deliveries on the endpoint in Settings → Integrations is where every diagnosis starts. Each row shows the event type and its state, with the HTTP status your server returned beside it, so a delivered row reads DELIVERED · 200 and a failed one reads FAILED · 503.

• 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. Check again in a moment.

• SKIPPED: nothing was sent, and the row names the reason.

Use Show response on a row to read what your server sent back. The log keeps the first 255 characters of the response body, which is usually enough to see the error your framework raised.

A delivery says SKIPPED

A skipped delivery was never attempted, so nothing on your side went wrong. The row names one of three reasons:

• The endpoint is disabled. Enable it from Settings → Integrations → Webhooks.

• Webhooks are not enabled for your account. Webhooks are available on the Growth plan and above.

• The endpoint is over your plan's endpoint limit. Growth includes 1 endpoint and Pro includes 10. Remove endpoints or upgrade.

Once the reason is gone, use Redeliver on the skipped row to send it.

My endpoint was automatically disabled

An endpoint is automatically disabled after 10 consecutive exhausted deliveries, meaning deliveries that ultimately fail, either after retries or because the target returned a permanent error that isn't retried. When this happens, the team owner receives an email linking to Settings → Integrations. Fix your server, then re-enable the endpoint from Settings → Integrations → Webhooks. Re-enabling resets the failure counter.

Common causes of exhausted deliveries are an endpoint that doesn't respond within 10 seconds, returns a non-2xx status, or can't be reached. A URL that cannot be reached at all, because it is not HTTPS or resolves to a private address, is not retried. It fails immediately and still counts toward the disable threshold.

My endpoint URL was rejected when I saved it

Eventually only accepts public HTTPS URLs. Known invalid hosts, such as plain HTTP URLs and private, loopback, or link-local addresses, are rejected at save time. A hostname that resolves to a disallowed address can still pass saving and is instead rejected at delivery time. Use a public HTTPS URL for your endpoint.

My deliveries aren't arriving

Check that the endpoint is enabled and that you've selected at least one event type on the endpoint. Use Send test event to see the exact reason a delivery fails, since it shows the receiver's HTTP response.

If you are waiting on one of the six event lifecycle types (event.published, event.updated, event.rescheduled, event.cancelled, event.completed, or event.sold_out), check that the endpoint subscribes to it. Every type is opt-in per endpoint, and an endpoint you created before those types existed is not subscribed to them automatically. Open Edit on the endpoint, select them under Events to deliver, and save.

If you downgraded to a plan with a lower endpoint cap, deliveries to endpoints over the new cap are paused until you remove endpoints or upgrade, and they appear in the log as SKIPPED. See Set up outbound webhooks for how endpoint caps work.

Something happened but no event arrived

Some state changes send nothing at all, so there is no delivery to look for:

• A partial refund. Refunding some of the seats on a registration does not fire registration.refunded. A whole refund does.

• Undoing a check-in. registration.checked_in has no inverse event.

• Removing a guest from the roster. The registration is discarded quietly, with no cancellation event.

• Deleting an event, and restoring one.

• Editing an event's description, image, SEO fields, or internal notes. Only the time, location, capacity, ticket types, and status send a lifecycle event.

• Anything on a draft event. Lifecycle deliveries fire only for events that are or were live.

Treat the record in the next delivery you do receive as the source of truth for these fields, or poll if your reconciliation cannot wait that long.

I hit a rate limit

Send test event is capped at 10 per minute and answers Too many test events, wait a minute and try again past the cap. Redeliver has its own cap of 10 per minute and answers Too many redeliveries, wait a minute and try again. Both are counted per client IP and per team, so spreading the clicks across members or machines does not raise them. A throttled test sends nothing and logs no row.

My receiver got a delivery it couldn't verify

Verify the signature against the raw request body, before any JSON parsing or re-serialization. Check the timestamp too: reject any delivery whose t is more than five minutes (300 seconds) old. If your server's clock is off by more than that, verification fails on deliveries that are perfectly good, so check the clock before you suspect the secret.

If you lost the signing secret, rotate it from the endpoint to generate a new one, then update your receiver. See Verify Eventually webhook signatures for the verification steps.