A proper API
Products, availability, baskets, quotes, orders, bookings, stock levels and redemption — the same surface our own checkout runs on, rather than a read-only reporting feed dressed up as an API.
For your technical team
If you have a developer, they will be fine.
You do not need to read this page. They will, and this is roughly what they will want to know before they look at the documentation properly.
The documentation
The public docs site, on the booking API page.
What is available
Notifications
Your other systems can be told the moment a booking is made, changed or refunded, on a documented format that will not change under them. Signed, retried if your endpoint is down, with a delivery history you can inspect.
AI assistants
An assistant can browse your availability and build a genuine basket, then hand the guest to your checkout to pay — so it never touches card details. Bookings that came through one are recorded as such, which makes it a number you can look at rather than a guess.
Things your developer will care about
- Requests can be safely retried. Anything that redeems or takes money requires a key that makes a repeat request harmless — so a flaky connection can never charge or admit twice.
- Notifications carry the whole booking. Not a description of what changed. Two updates arriving in quick succession are still individually correct, and nobody has to reconstruct the current state from a sequence of differences.
- Scoped to one site or the whole group, with an option that automatically includes sites you open later.
- Public documentation. Readable before you talk to us, without a sales call or a login.
Notification history
Connections → Webhooks, showing subscriptions and a delivery history.
See it running on your own products.
Bring one activity, one ticket type and one price. We will show you what it looks like in a real checkout.