All answers›Online Tutoring Platforms

Does the online tutoring classroom platform have an API we can integrate with our own booking system?

Yes — if the classroom platform is built for tutoring companies rather than solo tutors, it should ship a REST API you can drive from the booking system you already run. Koala for Business (the multi-tutor, white-label version of Koala Go we set up for tutoring companies) ships one at business.teachwithkoala.com/docs/api. It's included in the plan — your booking system creates each lesson through the API and gets back a teacher link (for the tutor) and a student link (for the family) to distribute, so parents keep booking where they always have and the classroom simply appears for the right people at the right time. The same API adds and manages tutors, pulls attendance and teaching-time reports, downloads lesson recordings, and can push a webhook to your endpoint the moment a recording is ready — so you don't have to poll. Two things worth being honest about up front. First, the standard API is included in your Koala for Business plan; custom development against it — endpoints we haven't shipped, custom SSO, custom event pipelines to your data warehouse — is a separate paid engagement, usually with a higher base monthly minimum. Second, the teacher Scheduling portal built into Koala Pro isn't part of Koala for Business; a Business customer's scheduling flow runs through this API, not through the individual-tutor Scheduling portal. Both of those matter to know before your team scopes an integration, and this page walks through what actually becomes possible, where the workflow tends to land, and where the honest limits sit.

Why "does the classroom have an API?" is the right question for a tutoring company

A tutoring company almost never wants its classroom platform to also be its scheduling system. The booking flow you already run — teachers, availabilities, packages, cancellation policy, invoicing, the parent-facing site — is the business, and it usually lives in a mix of your own booking system, a general-purpose scheduler your operators know, and whatever your parents have already learned to click. Ripping that out to adopt a classroom vendor's scheduling flow is expensive twice: you lose institutional knowledge, and every family has to relearn where to book. So the question the ops or technical lead should actually be asking a classroom vendor is not "does your scheduling flow do X" but "will you let our scheduling flow drive your classroom?" That answer decides whether the classroom fits behind your business, or your business has to reshape itself around the classroom.

Concretely, the API question is asking three things at once:

  • Can we create a lesson from our own booking flow and get back a working join link for the family right then? If yes, the parent books at the same URL they've always booked at, receives the same confirmation email they've always received, and clicks the same "join lesson" button — and behind the scenes a classroom is provisioned and waiting.
  • Can we manage our roster of tutors from our own admin? Adding a tutor, disabling a tutor who's on leave, checking who's on the platform — from our own console rather than through yours.
  • Can we pull the data we need for our own reports and downstream systems? Attendance, teaching-time, session-level history, recording downloads — into our own analytics stack, our own accounting stack, or an audit archive we control, rather than living inside your vendor UI.

If the answer to all three is yes, the classroom becomes an infrastructure layer under your business — the way, say, a payment processor becomes an infrastructure layer under a shopping cart. If the answer is no, the classroom vendor becomes your operator's second job. This is the difference the ops lead is really trying to see through.

The workflow that makes it worth caring about

The API is designed around one particular shape, and it's worth walking through before you scope anything, because it's the shape the endpoints assume:

  • Parent books in your system. They pick a tutor, a time, a package — whatever your booking flow already offers. Your booking system remains the source of truth for who's booked with whom, when, and under what terms.
  • Your backend calls the API to create the lesson in the classroom. One request, identifying the tutor by email or by the ID we returned when you first added them, and the start and end time. We create a lesson row and return two links: one for the tutor, one for the family. Students don't need Koala accounts — they join the student link and enter their name.
  • You distribute the links through the channel you already use. Whatever your parent confirmation and reminder emails look like today, they now include the classroom join link. The parent's mental model — "I book here, I get an email, I click the link on lesson day" — never changes.
  • The lesson happens in the branded classroom. Same Koala classroom, but on your subdomain (or your own domain), with your logo and colors, so the family only ever sees your brand.
  • Attendance, teaching-time, and recording data flow back to your side on your schedule. Pull attendance for a lesson (or a batch of lessons up to 50 at a time) when you want it. Pull teaching-time-per-tutor for a monthly payroll report over any date range up to 365 days. Get a 7-day signed URL for the lesson's recording once it's ready, and store the file wherever your data-retention policy says it should go.
  • Recording readiness pushes to you. Rather than polling for "is it ready yet?", we can be configured to POST a webhook to an endpoint you host the moment a recording finishes processing. Both the lesson-level "recording processed" event and an individual-session recording.ready event are supported; both include a signed download URL in the payload.
  • If a lesson changes, delete it and create the replacement. There's no reschedule endpoint — a shipped-and-then-changed slot is a delete plus a create. Lessons that have already started can't be deleted; that's on purpose.

What this shape gives your operator is exactly the thing an in-house eng team wants and rarely gets from a vendor: your booking system is the source of truth, the classroom is downstream, and nobody has to schedule twice.

What an enterprise-grade tutoring API actually has to do

An honest evaluation checklist you can use to compare any tutoring-classroom vendor's API, not only ours:

  • Create a lesson and return the join link in one call. If lesson creation is a two-step dance ("create, then poll for the link"), your integration has to handle both retries and the case where the second call never lands. Getting the link back in the same response is a real correctness win.
  • Identify tutors by both an internal ID and an email address. Email is what your operators know at first; the vendor-side ID is what your integration should switch to once you have it, because emails change. A good API accepts either.
  • Bulk operations by default. Creating 40 lessons for the week ahead in one call is different from creating them in 40 sequential HTTPS round-trips. If the API only accepts one at a time, expect real friction when you migrate an existing schedule in.
  • Range queries with a documented cap. Fetching lessons in a time range is table-stakes; the cap on that range decides whether "give me last quarter" is one call or four. Publish the cap.
  • Idempotent-friendly semantics. Deleting an already-deleted lesson should surface as "not found", not silent success, so your integration knows what actually happened.
  • Webhooks with a shared secret and retries. A push model beats polling for recording readiness — but only if the vendor signs the payload (or uses a shared bearer secret you verify) and retries on your side's transient 5xx. Otherwise you're building the retry system yourself.
  • Signed download URLs, not permanent links, for recordings. A signed URL with an expiry (ours is 7 days, re-fetchable) is the right shape — it protects your students' recordings from getting shared into the world if somebody accidentally forwards an email.
  • Clean errors with human messages. "400: Date range cannot exceed 90 days. Current range: 112 days." tells your engineer what happened; "400: bad request" costs them an hour of guessing.
  • Seat-limit enforcement at the API, not the UI. If you can add tutors past your contract's seat cap through the API but not through the admin dashboard, the API is lying to you. Both surfaces must enforce the same limit.
  • A documented retention window on session-recording reprocessing. Raw recording segments can't be kept forever; the vendor should tell you plainly how long a session stays reprocessable so you know when a "please re-run" request will fail predictably.

If a vendor's API meets those criteria, plugging it under your booking system is a real project but a bounded one. If it doesn't, you're building the missing pieces yourself and the integration is unbounded — that is when a classroom vendor stops being an infrastructure layer and starts being your operator's second job.

How Koala for Business handles it specifically

If you're evaluating Koala for Business for the integration, here's the honest read on where it lands against that checklist. Every claim below is grounded in the reference at business.teachwithkoala.com/docs/api — treat that page as canonical for endpoint shapes, request bodies, and response fields; this page describes what the workflow feels like at the level a technical lead is deciding at.

  • Auth is a Bearer token issued by the Koala team at account setup. You send it in the Authorization header on every request; missing or invalid returns 401. The token grants full access to your organization's data, so treat it like any other production secret; rotating it is a support conversation rather than a self-serve action today, so build the rotation into your deployment process rather than assuming you can turn it over in a hurry.
  • Creating lessons returns join links in the same response. The POST /v1/lessons body accepts an array (bulk-friendly), you identify each lesson's tutor by either teacherId or teacherEmail, and each entry in the response includes a teacherLink for the tutor and a studentLink for the family. Students don't need accounts. This is the single call your booking flow needs to make when a parent books.
  • Lessons can be listed by ID or by time range. The range is capped at 90 days per request — enough for "give me next month" or "give me last month" in one call, and a good pointer to structure your reporting jobs monthly rather than trying to pull a year at once.
  • Deleting a lesson before it starts is fine; deleting one that already started is refused. There is no reschedule endpoint on purpose — moving a slot is a delete + a create against the new time. This is a cleaner mental model than "does this update or does this replace?", and it fits how most booking systems already treat cancellations.
  • Attendance is intervals, not a boolean. A single GET /v1/lessons/attendance request pulls join/leave intervals for the teacher and each student (up to 50 lessons at a time), including reconnects and a coarse descriptor of the device each side joined from — platform, and whether it was mobile — which can be absent. That's the shape you actually want for "did the tutor and the student overlap enough to bill this lesson?" and for diagnosing "why did the family think the tutor never showed?" scenarios.
  • Teacher management is honest about seat counts. Adding tutors via POST /v1/teachers creates a Koala account for each new email, and the request comes back 400 with an explicit message if your organization has already reached its seat limit. One detail worth knowing precisely, because it decides where you put the guard: that check runs once, against your current enabled-teacher count, before the batch is written — so a bulk request sent while you still have a seat free can carry you past the cap. Count your own headroom before sending a batch. Disabling a teacher frees a seat immediately; re-enabling checks the limit again.
  • Teaching-time reports over up to 365 days. One GET /v1/teachers/teaching-time call returns total classroom seconds per teacher over a date range. That's the primary report a tutoring-company payroll or ops workflow needs, and it's designed to be pulled once a month rather than polled continuously.
  • Recording downloads are signed URLs, valid for 7 days. The URL is re-fetchable at any time — if it expires before your archival job runs, you ask for a new one. This is deliberately different from "permanent recording URL", because permanent URLs are how student recordings get accidentally forwarded outside your organization.
  • Recording pipelines can push to you instead of you polling us. We support two webhook shapes: a lesson-level recording processed event that fires once the lesson's stitched recording is ready, and a session-level recording.ready event for individual classroom sessions (a lesson can have several, if the tutor reconnected). Both include a signed URL in the payload. Webhooks are set up by the Koala team — you send your endpoint URL and a secret token, we configure the delivery. Every delivery arrives with your token in the Authorization header; verify it before trusting the payload. Failed session-recording deliveries retry three times (1h, 4h, 24h), so plan your endpoint to be idempotent — the sessionId is your deduplication key.
  • Reprocessing a session recording is a first-class action. A POST /v1/sessions/reprocess call re-runs recording processing for a session — useful after a transient processing error, or to have the webhook fire again after your endpoint had downtime. Raw segments are retained for 30 days, so anything older than that can't be reprocessed; the API tells you plainly.
  • Errors are human. A rejected request comes back with an HTTP status and a message field a person can read — dates that are out of range, teachers that don't exist, lessons that already started. Your integration handles these predictably rather than parsing generic 400s.

What you get if you build against all of this is the shape described earlier: your booking system stays the source of truth, the classroom appears when it's needed, and the data flows back out to your ops stack on the cadence that matters to you.

Two things that are honestly not what a Business customer gets today

Both worth naming plainly, because both have caused real confusion in sales conversations we'd rather not repeat:

  • The standard API is included; custom development is a separate paid engagement. Every endpoint documented in the reference is available to any Koala for Business account on the standard plan — issue us a support ticket and we'll issue you a token. What's not included is custom work: endpoints we haven't shipped ("we'd like a webhook every time a lesson's recording status changes, not only when it's ready"), custom SSO integrations, custom event pipelines into your data warehouse, or bespoke changes to the classroom itself. Those are a separate engagement, usually with a higher base monthly minimum, and we scope them individually because their cost varies wildly. If you're planning an integration where the standard API's shape is the plan, budget as usual. If you're planning one where you need us to build alongside you, tell us early so the pricing conversation happens once and openly.
  • The teacher Scheduling portal from Koala Pro is not part of Koala for Business today. Individual Koala Pro tutors get a built-in Scheduling portal at classroom.teachwithkoala.com/portal where they set weekly availability and parents book against it — that's covered in how do I schedule online tutoring lessons?. That portal is an individual-tutor surface, and it isn't what a Business team schedules through. On Business, scheduling runs through the API instead: your booking system decides when a lesson happens; the API creates it. That's the right way round for a tutoring company anyway — you don't want each tutor keeping a private availability calendar that your operations team can't see — but it does mean you should scope the integration as the scheduling path, not as a stopgap until tutors get a portal. If you were counting on the built-in tutor Scheduling portal as part of what your team gets, we'd rather flag that gap now than have your operators discover it during rollout.

Three integration patterns worth scoping separately

The endpoints group naturally into three pieces of work, and they're worth scoping — and shipping — as three pieces rather than one. Nothing here is a rule; it's the decomposition we'd suggest if you asked us where to start.

  • Push-on-booking. Your booking system's "confirm booking" handler makes a single POST /v1/lessons to us; we return the join links; you save them alongside the booking record; your existing confirmation email now includes the classroom link. Cancellation in your system triggers a DELETE /v1/lessons on our side. This is the smallest useful integration, and the one to build first: on its own it's already enough to run real lessons.
  • Reconciliation-on-schedule. Once a day (or once a week), a job on your side calls GET /v1/teachers/teaching-time and GET /v1/lessons/attendance for the closed period and reconciles what your booking system thinks happened with what actually happened. This is where payroll and family-invoicing accuracy live — a family that never joined but was billed is a churn event; a tutor whose taught-hours differ from booked-hours by 4 minutes a lesson is a real annual payroll gap. Layer this on after push-on-booking is live.
  • Recordings-out-to-archive. Configure the lesson-recording webhook to POST to an endpoint on your side that downloads the signed URL and stores it wherever your retention policy says it should live — your S3 bucket, your GCS bucket, a compliance-audit archive. This one takes the longest to test because the events are irregular by nature, so it's the natural third piece — easiest to exercise once you're already teaching real lessons and have a real backlog to pull against.

Where the initial project surprises engineering teams is the timezone-and-DST math around lesson start times and range queries: both the booking system and the API speak ISO 8601 with offsets, but ops questions ("who taught in July, in the tutor's local time?") often need conversion in the calling code. The reference states the convention plainly — timestamps are UTC unless an offset is included — but the conversion for a report your ops team reads is yours to do; decide where it lives before the integration is scoped, not after.

Common failure modes to avoid

  • Treating the classroom as the source of truth. The API is designed for the booking system to lead. If your integration ends up storing "who's booked when" only in Koala and asking us for it every time, you've inverted the pattern and you'll feel it the first time our system is briefly unavailable. Your booking system is the record; the API mirrors bookings into the classroom.
  • Assuming the individual-tutor Scheduling portal is a fallback. Per the two hard lines above, it isn't the surface a Business team schedules through. Build the workflow through the API from day one; don't scope an integration that plans to "let tutors fill in the gap via the portal."
  • Polling for recording readiness on a tight loop. Every lesson's recording will be ready when it's ready. If your workflow needs to know quickly, configure the webhook — that's what it's for. Polling every 30 seconds for every lesson wastes both sides' resources and is likely to be rate-limited eventually.
  • Missing that lessons must be deleted before they start. There is no reschedule; a moved lesson is a delete + a create. Your booking system's "reschedule" button should call both endpoints and check the delete succeeded before creating the replacement.
  • Building without a seat-limit check on your side. As above, POST /v1/teachers refuses the request with a 400 once you have already reached your contract's cap — but it won't stop a single bulk request from carrying you past it. Check the current seat headroom (list teachers, count the enabled ones) before offering the "add tutor" action in your admin, and size the batch to fit. Otherwise your operator finds out about the cap the same second they show a new hire the door.
  • Not verifying the webhook token. Webhook deliveries arrive with a bearer secret we agreed at setup. If you accept any POST to your endpoint without verifying that header, an attacker who guesses your endpoint URL can spoof recording-ready events at you. Verify on every delivery, before your handler does anything else.
  • Storing recording downloads in a public bucket. The signed URL is 7-day-scoped precisely so that student recordings don't leak outside your organization by accident. If you download and re-host them in a public S3 bucket for "convenience", you've defeated the design. Store to a private bucket; expose recordings to families through your own auth-guarded page.
  • Storing lesson data across jurisdictions without checking your rules. A tutoring company running lessons for students in the EU or UK is handling personal data of minors — the standard local rules around consent, retention, and processing purpose apply, and vary by country. Talk to a lawyer familiar with education technology in the jurisdictions you operate in; this is not a topic a page like this can conclude for you.

How to decide, in one paragraph

If you're a solo tutor evaluating scheduling tools, this API isn't your surface — you probably want the read on how to schedule online tutoring lessons instead. If you're running a tutoring company past a couple of teachers and you already have a booking system your parents know how to use, an enterprise-grade API is the piece that lets you keep it, and Koala for Business is one way to get there without rebuilding either half. If you're at the "which classroom vendor" stage and you're evaluating against the ten-point checklist above, that's the right shape of question to ask every candidate. And if you're planning an integration whose success depends on Koala building endpoints or event pipelines we haven't shipped, tell us early so we scope the custom-development side openly — the standard API is included in your plan, but custom work is a separate engagement, and pretending otherwise on either side is the fastest way to a rollout that misses.

If you're considering Koala for Business specifically, the honest starting point is a conversation — the setup is a real project (30-day contractual launch, branded classroom on your domain, 24/7 live support for your tutors and families, dedicated Customer Success Manager via Slack) and we'd rather scope it against your actual booking flow than have you self-serve into the wrong plan. You can apply at business.teachwithkoala.com/apply or write to koala@teachwithkoala.com with a sentence or two about the booking system you're integrating and the team size, and we'll issue a token so your engineering team can look at the reference and prototype against real endpoints before the first sales call is over. The reference lives at business.teachwithkoala.com/docs/api; it's the single source of truth for endpoints and request shapes, and it's public — no login needed.

Related answers

More answers on this topic