Teachable's V2 API: what's new and why it matters for your school

Teachable has been quietly building a new version of its API, and it's a much bigger change than the version number suggests. This post is for school owners who already rely on integrations (Zapier, a CRM, a membership site, custom reporting) and want to know what's changed and what it makes possible. It isn't a tutorial. There's a short technical note at the end for developers, which everyone else can skip. I've been building and testing against V2 since August, so what follows is based on the public docs and on what I've actually seen come back from a live school.

One thing to say up front: V2 is in beta. Access is by request through Teachable Support, you need to be on the Growth plan or above, and Teachable's own docs warn that endpoints may change without notice. So this is a "what's coming" post rather than a "switch today" post.

Where V1 got us

The V1 API has done a lot of good work over the years. It's what made Zapier integrations possible, it let us pull enrolment and sales data out for reporting, and it would let a script create a user and enrol them in a course without anyone touching the admin. For a lot of schools that was enough.

Where it got frustrating was anything to do with course content. You could read a course's curriculum, but you couldn't create or change it. Enrolments were a one-way trip. Quiz responses were all users (even if you only needed a single student). Digital downloads, coaching, and bundles were largely invisible. And every API key had the run of the whole school, so handing a key to a contractor meant handing over everything. None of that was a dealbreaker, but it meant a lot of projects ended in "we'll do that bit by hand."

The headline changes

Courses and curriculum can be built and edited through the API

This is the big one, and I'll admit I hadn't spotted quite how far it goes until I went through the docs properly. V2 documents endpoints to create a course, add sections, add lectures, attach content, reorder any of it, set up quizzes, and update compliance settings (things like whether lectures must be completed in order). V1 was strictly read-only here.

I hold the scopes for this on my beta key, but I haven't put the write-to-Teachable side through its paces yet, so treat this as "documented and coming" rather than "tested by me". If it works as described, the course structure no longer has to be built by hand in the admin. You could keep your curriculum in a spreadsheet or another system and have the Teachable course generated from it. Or set up a template course and stamp out a new copy for each cohort with the dates and names changed.

Enrolments are tidier

To be fair to V1, enrolments were never its weak spot. You could add a student to a course and remove them again, and if they came back later their progress was still there. The odd part was that each time you granted access you got a new enrolment record, so a student who'd been in and out of a course a few times would show several enrolments for it when you pulled their data. That made sense once you knew why, but it caught people out.

V2 changes the shape of the call rather than what it can do. Enrolling someone is a single "put this person in this course" request that's safe to repeat: if they're already in, nothing breaks. There's a matching call to update an enrolment and one to remove it. I haven't yet checked whether V2 still stacks up multiple enrolment records the way V1 did, and I'd expect it to, so I'll cover that in a follow-up once I've tested it.

What it means in practice is that an automation can keep asserting the state it wants ("this person should be enrolled") without checking first. Let your CRM be the source of truth for who has access and have Teachable follow it. Access lapses, enrolment is removed. Access renews, it's put back. Less defensive code, fewer places for it to go wrong.

API keys can be limited to what they need

V2 keys have scopes. When you create a key you pick which resources it can touch (courses, users, enrolments, products, and so on) and which operations (read, create, update, delete). A V1 key had no such thing and could reach every V1 endpoint your plan allowed.

You could now give a reporting tool a read-only key, and give the contractor building your enrolment automation a key that can enrol and un-enrol but can't delete a user or touch your courses. One warning from the docs that's worth repeating: if you create a key without ticking any permissions, it's created with all of them. Tick something.

It covers all your products, not just courses

V1 was built around courses. V2 is built around products, with courses as one type among several. There's a single endpoint that lists everything you sell, and digital downloads and product collections (bundles) get full support: create them, update them, manage their enrolments, add products to a collection. Memberships and coaching are documented as still under development at the time of writing, so I'd hold off promising anything there.

You could now run the same "sync access from my CRM" automation across a bundle or a downloadable as easily as a course, which wasn't really possible before.

Progress and quiz results per student

V2 exposes a student's progress through a course, their completion status for each lecture (which you can also set), and their quiz responses across every quiz they've taken, with grades included and filterable by date. For anyone doing certification, cohorts, or anything with a pass mark, this is the data that previously had to be tediously exported by multiple calls, pulled by hand, or scraped from reports.

It behaves like a modern API

Less visible, but it matters for anyone building on it: responses have a consistent shape, lists can be sorted and filtered by creation date, there are published rate limits (360 requests a minute) with headers that tell you how much you have left, and every response carries a request ID you can quote to Teachable Support. V1 missed some of that, so a lot of integration bugs were guesswork. Your school's branding (colours, fonts, logo) is also readable through the API, which is handy for anything you build that should match your school.

What this makes possible

Three scenarios I see regularly.

A membership site gating access from an external CRM. Under V1 this needed a "check if enrolled, then enrol" dance and there was no clean way to remove access, so lapsed members often kept their courses. Under V2 it's one call to grant and one call to remove.

A school running cohorts on a schedule. Under V1 someone duplicated the course in the admin, renamed it, and enrolled the list by hand or through Zapier. Under V2 the enrolment side is a direct call today, and once the course endpoints are proven a script should be able to create the course from a template too, add the students, and remove them when the cohort ends.

A degree-style programme tracking credits across many courses. Under V1 progress had to be pieced together from webhooks and exports, and I've built exactly this the hard way. Under V2 you can ask for a student's progress in each course and their quiz results in one place, so the credit tracking becomes a straightforward report rather than a reconciliation exercise.

What school owners should do now

Nothing dramatic. V1 isn't going anywhere today and Teachable hasn't announced a shutdown date. But it's worth doing three things while V2 is still in beta.

First, list your current integrations. Zapier zaps, custom scripts, anything a freelancer built, anything that uses an API key. Second, note which of them rely on a workaround that V2 removes: manual course setup, "check then enrol" logic, exports for progress data, a shared all-access key. Those are the ones that will benefit most from a rebuild. Third, ask whoever built or maintains them whether they've looked at V2 yet. If that's nobody, that's the gap to fill before you need it in a hurry.

For developers: a short technical note

The base host is still developers.teachable.com, with /v2 in each path. Admin authentication is the same apiKey header as V1, so credentials carry over. Scopes are resource:action (for example courses:read) and are fixed on the key. The docs say permissions can be added to an existing key and take up to five minutes to apply, but I haven't been able to do that on a beta key, so for now assume a new scope means a new key. A missing scope comes back as a 403 that names the scope you need, which is handy. Responses are wrapped in a data key with a meta object for pagination (page, per_page, total_pages, total_count, max 100 per page). There's a separate OAuth-based end-user API for building things that act on behalf of a logged-in student. The docs are at docs.teachable.com, and if you're working with an AI coding tool, appending .md to any docs URL gives you a markdown version.

I'm updating my open-source Teachable SDK Optio Teachable to support V2 alongside V1. I'll write up the rougher edges I've found (null handling, error shapes, a few naming inconsistencies) in a separate post once things settle.

Closing thoughts

V2 is the API Teachable should have had years ago, and it's the first time the platform has been properly buildable from the outside. It's beta and it will shift a bit, but the direction is clear.

If you'd like a second pair of eyes on your existing integrations, or want to know what V2 would let you do that you've been doing by hand, get in touch. No obligation, and I'm happy to just talk it through.