Build your own checkout on our booking API.
The hosted page needs no code, and the widget needs a few lines. When you want booking screens of your own, the public REST API is there. Your developer starts from a published OpenAPI 3.1 spec, and booking calls are safe to retry.
Best for: developers building their own booking screens and logic. Underneath, it's the same booking system that runs the hosted page and widget.
Three ways to take bookings, one system behind them.
You don't have to decide up front. The hosted page gets you live today, and the widget puts booking inside your own website. The API is for when you want to design every screen yourself.
All three take payments, collect waivers and send confirmations in the same way. So you can start on the hosted page and call the API later without migrating anything.
# Create a booking POST /v1/bookings Authorization: Bearer sk_... Idempotency-Key: order_1042 { "event_id": "evt_01K5W3JQ8C9T2N4R7VXHFGMB6D", "seat_count": 2, "email": "jane@example.com", "first_name": "Jane", "last_name": "Smith", "payment_source_id": "pm_..." } -> 201 Created { "id": "bkg_01K5W4B2ZQ6M8P3T1YNC7RDXAE", "booking_number": "7Q4M2X", "status": "confirmed" }
Everything a booking screen needs to talk to.
- Events and availability. Read your schedule with live spot counts, so your front end only offers what can actually be booked right now.
- Bookings. Create, read and cancel bookings. Send an idempotency key and a retry after a dropped connection won't book twice. Look a booking up by its number to show it on your own thank-you page.
- Checkout. Check a promo code, look up a gift card and apply it, and handle the payment steps for a booking.
- Courses. List multi-session courses by category, quote a price and book the whole course in one call. The purchase reads back as one record with every session in it.
- Customers and referrals. Work with customer records matched by email, and look up a referral link so the right person gets the credit.
- Configuration. Fetch the public settings and categories your booking screens need to render.
- Signed webhooks. Your server hears about it the moment a booking is made, changed, canceled or checked in, a payment is taken or refunded, or a waitlist spot is offered. Every delivery is signed so you can prove it came from us, and a failed one is retried.
- A published spec. Download the complete OpenAPI 3.1 spec and generate typed clients from it. The app has an interactive reference with request and response examples you can copy.
Ask an AI assistant about your studio.
- Connect Claude or ChatGPT in a couple of clicks. Add FullClass as a connector, approve it once, then ask "how full is Saturday?" or "what did we make in March?"
- Read-only, always. Nothing on this endpoint books, cancels, refunds or emails. It answers questions and does nothing else.
- Your schedule and how full it is. Ask what's coming up, how full each session is running, and what your fill rate looks like class by class or month by month.
- What needs promoting. Pull the sessions sitting under half full, emptiest first, while there's still time to do something about them.
- Bookings, money and turnout. Booking counts with cancellations and failed payments shown separately. Revenue from classes, gift cards and private events. And whether the people who booked actually turned up.
- No customer data leaves. Seat counts, never names, emails or phone numbers. No payment records, and no join links for online classes.
- Numbers come with their fine print. Every answer names the time zone it was worked out in, and money figures carry their own accounting notes, so a total is harder to quote out of context.
- Or point your own tools at it. It's a standard Model Context Protocol endpoint over HTTPS, so other MCP clients can connect too, authenticating with a secret key you already have.
A public key you can safely put on a public website.
-
Public and secret keys. Put
pk_public keys in the browser. Keepsk_secret keys on your server for full access. - Scopes on public keys. A browser key gets only what it needs, like browsing events or checking a gift card balance.
- Origin checks for public keys. List the sites a public key belongs to. Any request carrying a browser Origin has to match, so nobody can lift the key and use it on another site.
- Expiry, revoke and edit. Set an expiry date if you want one, revoke a key instantly, or change its name, scopes and origins as your integration changes.
- Secrets stored hashed. You see the full key once, when you create it. We only keep a hash, so a leaked database never exposes a usable key.
- Rate limits. Requests are rate-limited to keep the API stable under heavy load or abuse.
From the first key to a live checkout.
Create your keys
Make a public key and a secret key. Limit what the public key can do and which sites can use it.
Read the schedule
Fetch the sessions people can book and how many spots each has left. Check promo codes before checkout.
Create bookings
Send the booking with an idempotency key and the payment is captured. If you turn on checkout holds, spots are held while the customer checks out.
Build the rest your way
Design whatever screens you like on top, working from the documented endpoints and SDK examples.
You don't have to start with the API.
Go live on the hosted booking page today, drop the booking widget into your own site, and move to the API when you want a checkout of your own. Your bookings and data stay where they are, so there's nothing to migrate.
Related features
Build booking your way.
Launch on the hosted page today and switch to the API when your own build is ready.
30-day free trial · Cancel anytime