The booking engine is written. Build the experience.
Zooza is ready-made infrastructure for activity businesses — classes and courses, trials, make-up sessions, payment plans, waiting lists and the parent account. It runs for schools, studios, clubs and franchise networks worldwide.
You embed the widgets or build on the REST API, and keep your own site, your own design and your own customer journey. The rules underneath stay enforced by the platform.
What is already built
These are the parts of a class booking system that take a year to get right and never stop changing, because the business keeps refining its policy. They are in place, with the edge cases that only show up in the second term.
Registration & booking
Classes, courses and terms with capacity per class, age groups, filters, and a waiting list when a group is full. Capacity is enforced server-side at the moment of booking.
Trials
A trial carries its own price — often free — its own capacity, and a follow-up that turns it into a regular booking on the right payment plan. Conversion is tracked, because it is the number the owner manages weekly.
Make-up sessions
Earning rules, a limit per booking, expiry, the scope of where a make-up may be used, and spare capacity in classes already full for new sign-ups. The single most underestimated feature in a custom build.
How make-ups work → Make-up sessions on ZoozaPayments & payment plans
Monthly, per term, instalments or direct debit, with pro-rating for a late joiner, sibling discounts, failed-payment handling and invoices your accountant will accept.
The parent account
Bookings, payments, make-ups, cancellations and documents in one place, so the office is not the only path to an answer. Embeddable into your own site.
Multiple venues & franchises
Per-venue pricing, staff who see only their own venue, and reporting across the whole network — the point at which a home-grown data model usually has to be rewritten.
Six working examples
Each one is a complete, copy-paste integration in the docs — with the code, the API calls behind it, and a prompt you can hand straight to your AI coding agent.
Multi-step trial booking
A trial booking flow across several steps, on your own page and in your own markup.
Branded booking tiles
Course and session tiles restyled to your brand, down to the individual card.
Location map
Your venues on a map, fed by live data rather than a hand-kept list that goes stale.
Filtered timetable
A timetable filtered by venue, age or day — built on the API, laid out however you like.
Custom catalogue
Your own course catalogue on live availability, instead of a copy that drifts from reality.
Chatbot with a logged-in parent
A website chatbot that knows which parent it is talking to, and can answer about their own bookings.
Two ways in
Most integrations use both: widgets where the flow is standard, the API where you want something of your own.
Widgets
Drop-in booking, trials, timetables, maps and the parent zone. They carry the full rule set with them, and you style them to your brand. No server, no redirect away from your site.
- Only the widget key is needed — nothing secret in the browser
- Styled down to individual course and session tiles
- Booking events are trackable from the registration widget
REST API
Read and write the operational entities — registrations, classes, sessions, payments, attendance, clients — from your own backend, with server-side credentials.
- Versioned and rate-limited
- Server-side credentials, never exposed in the browser
- Build your own catalogue, timetable, app or internal tooling on live data
Getting started
Self-serve from the first step. You can be rendering live data the same afternoon.
Create a free account
Sign up at signup.zooza.online and set up a programme and a class, so you have real data to build against.
Embed a widget, or request an API key
Widgets need only your widget key, so you can embed one straight away. For the REST API, request a key from support — we issue them by hand on purpose, so write access to a live business is always a reviewed decision.
Start from an example
Pick the example closest to what you are building, copy the code, and adapt it. Each one includes a prompt for your AI coding agent.
There is no separate sandbox. A free account is the test environment — build against it, and switch the keys when you go live. Still weighing whether to build at all? What the estimate leaves out.
Built to be read by machines, too
A growing share of integration work starts with a coding agent, and a growing share of parents ask an assistant before they ask you.
Docs your coding agent can read
Every example ships with a prompt written for an AI coding agent, and the docs publish an llms.txt so an assistant can take in the whole surface at once.
docs llms.txt →MCP for the people running the business
Staff handle day-to-day work — classes, registers, clients, messages — by talking to Claude or ChatGPT, with a preview and a confirmation before anything is written.
AI assistants & MCP → Zooza AI for Claude & ChatGPTAn assistant inside your own site
A chatbot on your pages can recognise the logged-in parent and answer about their own bookings, rather than reciting the FAQ at them.
See the example →What it runs on
The operational detail a technical evaluation asks for, before the pilot rather than after it.
- Microsoft Azure, with private cloud networking
- Kubernetes and Docker
- 99.9% SLA, with a public status page
- Stripe and GoCardless — or connect your own gateway, and Zooza takes no cut of the transactions
- Xero
- Power BI, plus custom reporting endpoints for franchise networks
- REST, versioned and rate-limited
- Booking events from the registration widget, for your own analytics
Questions developers ask first
-
Is there a sandbox or test environment?
No separate sandbox. A free Zooza account is the test environment — create one, set up a programme and a class, and build against real behaviour rather than a mock that drifts from it. When you go live, you swap the keys. -
How do I get a REST API key?
Create a free account at signup.zooza.online, then request an API key from support. Keys are issued by hand on purpose: the API writes to a live business with real families and real money in it, so we would rather that access be a reviewed decision than a self-serve button. Widgets do not need it — they run on your widget key alone. -
What is the difference between the widget key and the API key?
The widget key is public by design. It is what the booking widgets, timetable and parent zone use in the browser, and it only permits what a visitor could do anyway. The REST API key is a server-side credential with far more reach — it never belongs in front-end code. -
Can I keep my own design and my own website?
That is the usual arrangement. Widgets are styled to your brand down to individual course and session tiles, and anything the widgets do not cover you can build yourself on the REST API — your own catalogue, timetable or app on live data. The rules underneath stay enforced by the platform, so your front end cannot sell something the business does not offer. -
Does Zooza take a cut of our payments?
Not when you connect your own payment gateway — the transactions are yours and Zooza takes no percentage of them. A card fee applies only on Zooza-provided card processing, where Zooza is the one carrying the processing. -
Is the API versioned and rate-limited?
Yes to both. The REST API is versioned, so an integration built today keeps working, and it is rate-limited, so one noisy client cannot degrade the platform for the businesses running on it.
Got a build in mind?
The docs answer most of it, and the examples answer the rest. If you are sizing up something bigger — a franchise network, a migration, an integration into an existing stack — talk to the people who built it.
