Webhooks

Webhooks let your own systems be told the moment something happens in EventMann — a booking confirmed, a ticket checked in, a payout paid — instead of you polling for changes. They live under the same Integrations row in the sidebar, on the Webhooks tab.

How to add an endpoint

1. Go to Integrations → Webhooks → Add
2. Give it a name and the public http(s) URL that should receive the calls — a private or internal address is rejected outright, both here and every time a webhook actually fires
3. Tick which event types you want to receive
4. Save. A 64-character signing secret is generated for you automatically and shown masked; use Show/Hide to reveal it once

Events you can subscribe to

Event	Fires when
booking.created	a booking starts, before payment
booking.confirmed	a booking is confirmed
booking.cancelled	a booking is cancelled
booking.refunded	a booking is refunded
event.created	you create a new event
event.published	an event goes live
event.cancelled	an event is cancelled
event.updated	event details change
ticket.checked_in	a ticket is scanned at the door
payment.received	a payment settles
payment.refunded	a payment is refunded
payout.created	a payout is created
payout.paid	a payout is paid out
staff.assigned	a staff member is assigned to your event
staff.checked_in	a staff member checks in for a shift
vendor.assigned	a vendor is assigned to your event
vendor.invoice_submitted	a vendor submits an invoice

The delivery itself

Every call is a POST of JSON shaped like this:

{"event":"booking.confirmed","data":{"id":1,"reference":"BK-ABC123","status":"confirmed","total":49.99,"currency":"USD","attendee_name":"Jane Doe","attendee_email":"jane@example.com","event_id":10,"confirmed_at":"2026-03-01T12:05:00Z"},"timestamp":"2026-03-01T12:05:00Z","delivery_id":"..."}

Alongside it you get an X-Webhook-Event header naming the event, an X-Webhook-Delivery-Id, and an X-Webhook-Signature header — an HMAC-SHA256 of the raw request body, keyed with the secret shown on the endpoint page. Recompute it the same way on your end and compare before trusting a payload.

Retries and what happens when a receiver is down

• A delivery is tried up to 5 times, waiting 10, then 30, then 60 seconds between attempts; only a 2xx response counts as delivered
• Once all 5 attempts for one event have failed, the endpoint's failure count goes up by exactly one — not once per attempt
• 10 failed deliveries inside a rolling hour pause that endpoint for 5 minutes; if the failure count ever passes 10, or that pause is triggered, the endpoint switches off automatically and stops receiving anything until you fix it
• You will get an in-app notification the moment this happens, naming the endpoint
• A disabled endpoint shows a “This endpoint is disabled” notice, with the reason, on both the endpoint list and its own page — editing its name, URL or events does not bring it back. Fix whatever was wrong with your receiver, then use the Re-enable button; it clears the failure count and unpauses delivery, keeping the same URL and signing secret
• Delivery history — event type, HTTP status, duration and time — is kept for 30 days and then purged automatically

Good to know

• Test, on an endpoint's page, sends a synthetic ping event so you can check your receiver and signature verification before subscribing to anything real
• Retry on a failed delivery re-sends that event fresh to your currently active endpoints — it is a new delivery, not a resumption of the original attempt chain
• Webhook sends run on their own queue, separate from checkout and email, so a slow or broken receiver on your end cannot slow down bookings or ticket emails
• Un-ticking an event type silently stops it being sent — there is no notice that you stopped receiving something

Troubleshooting

• Deliveries stopped with no error visible on my end — open the endpoint and check its failure count and status; if it shows disabled, fix your receiver and click Re-enable
• Signature never matches — hash the exact raw request body, not a re-serialized copy of it, with the secret shown on the endpoint's page
• Test succeeds but real events never arrive — confirm the specific event type is ticked on that endpoint; unsubscribed types are simply never sent

Related

• Integrations
• Orders
• Check-in
• Payouts