Webhooks and an API for your event registration data

Yes, through webhooks. Point a webhook at your CRM's inbound endpoint, or at an automation platform that accepts webhooks, and each registration, payment, and check-in arrives as it happens. There are no built-in one-click CRM connectors: webhooks are how data leaves BagEvent, and they work with anything that can receive an HTTPS request.

Fifteen: attendee.registered, attendee.updated, attendee.cancelled, attendee.checked_in; order.created, order.paid, order.refunded, order.cancelled; invoice.issued, invoice.voided; speaker.submitted, speaker.accepted, speaker.declined; event.published and event.updated. Each webhook subscribes to the ones it needs.

Each delivery is signed with HMAC-SHA256 using a secret shown once when you create the webhook. The signature covers a timestamp as well as the body, so your endpoint can check both that the request is genuine and that it is recent — a delivery captured and resent later fails the check.

Each event is tried up to three times, 10 seconds and then 60 seconds apart. If a webhook fails ten times in a row it is paused and marked as erroring, so it stops sending to an endpoint that is not there. Resume it once the endpoint is fixed, and resend any missed delivery from the log.

Today it reads: the attendees and the orders for an event, authenticated with an API key and a signed request. It does not create registrations or change orders. Most integrations use webhooks to receive changes as they happen and the API to backfill or reconcile.

Business and Enterprise. Within an organisation, the person setting them up also needs the API and webhooks permission, because an API key can read attendee data.