Developer API

Start simple, then integrate deeply.

Launch on the hosted page for speed, embed the widget for your own site design, or build a fully custom flow on the public REST API, with scoped keys, idempotent booking, and a published OpenAPI 3.1 spec.

Best for: developers building a custom booking experience (your own UI, your own logic) on top of the same engine behind the hosted page and widget.

What it solves

Three ways to build, one booking engine.

Not every business needs the same level of control, and you should not have to choose up front. The hosted page gets you live fast, the widget puts booking inside your own site design, and the API is there when you need a fully custom experience.

All three run on the same engine, so spot locks, payments, waivers, and confirmations behave identically no matter which you pick. Begin simple and reach for the API when your product needs custom logic, no migration in between.

# Create a booking POST /v1/bookings Authorization: Bearer sk_... { "event_id": "evt_8KQ2", "seats": 2 } -> 201 Created { "id": "bkg_5X9", "status": "confirmed" }
What the API covers

The REST API your booking flow is built on.

  • Events and availability. Read your schedule with live spot availability, so your own front end shows exactly what is bookable right now.
  • Bookings. Create, read, and cancel bookings, with an idempotency key so a dropped connection never turns into a duplicate.
  • Checkout. Validate promo codes, look up and apply gift cards, and run the payment steps that go with a booking.
  • Courses. List multi-session courses, quote a price, and book a whole course in one call.
  • Customers and referrals. Work with customer records linked by email, and look up a referral code so the credit lands in the right place.
  • Configuration. Fetch the public settings and categories your booking flow needs to render correctly.
  • A published specification. The whole API ships as a complete, downloadable OpenAPI 3.1 specification you can generate typed clients from, with an interactive reference in the app and copy-paste request and response examples.
AI assistants

Ask an AI assistant about your studio.

  • Connect Claude or ChatGPT in a couple of clicks. Add FullClass as a connector, approve it once, and ask about your studio in plain language.
  • 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 is coming up, how full each session is running, and which classes carry your fill rate.
  • What needs promoting. Pull the sessions sitting under half full, emptiest first, while there is still time to do something about them.
  • Bookings, revenue, and attendance. Booking counts with cancellations and failed payments broken out, revenue across classes, gift cards, and private events, and whether the people who booked turned up.
  • No customer data leaves. Seat counts, never names, emails, or phone numbers. No payment records, and no join links for online classes.
  • The caveats travel with the numbers. Every answer names the timezone it was worked out in, and the 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 is a standard Model Context Protocol endpoint over HTTPS, so other MCP clients can connect too, authenticating with a secret key you already have.
Keys & safety

Built for production from the first request.

  • Public and secret keys. Embed pk_ public keys in the browser and keep sk_ secret keys server-side for full access.
  • Scopes on public keys. Grant a browser key only the access it needs, like browsing events or checking gift-card balances, and nothing more.
  • Origin checks for public keys. Add allowed origins to a public key and requests carrying a browser Origin must match, so a key cannot be reused from another site.
  • Expiry, revoke & edit. Give a key an optional expiry date, revoke it instantly, or update its name, scopes, and origins as your integration changes.
  • Secrets stored hashed. The raw key is shown once at creation; only a hash is stored, so a leaked database never exposes a usable key.
  • Rate limits. Requests are rate-limited to keep the API stable under load and abuse.
  • Idempotency keys on booking. Safe retries mean a dropped connection never turns into a duplicate booking.
  • The same engine underneath. Spot locks, payments, waivers, and confirmations match the hosted page and widget exactly.
How it works

From first call to live custom flow.

1

Create your keys

Generate public and secret keys, set scopes on public keys, and add allowed origins so browser requests are checked.

2

Read the schedule

Read bookable sessions and their spot availability, and validate promo codes before checkout.

3

Create bookings

Send the booking with an idempotency key. Spots lock during checkout and payment is captured.

4

Ship your custom experience

Build the UI you want on top of the API, using the documented endpoints and SDK examples to move fast.

Start simple, then integrate deeply.

Go live on the hosted booking page today, drop the booking widget into your own site, and move to the API when you need a fully custom flow. Same bookings, same data, no migration.

Get started today

Build booking your way.

Start taking bookings in minutes. Launch fast on the hosted page, then integrate the API when you need full control.

30-day free trial · Cancel anytime