How to integrate Kajabi online courses with Webflow Cloud using the Public API

Kajabi ships a real Public API, and Webflow Cloud runs your own code on Cloudflare Workers at the edge, giving you a server-side home for credentials and API calls. Put them together, and the integration stops being a series of brittle embeds and becomes an app you control.

In this guide, we build that integration step by step, from authenticating to Kajabi through to a webhook that keeps course access in sync no matter where the purchase happens.

What do you need to integrate Kajabi courses with Webflow Cloud?

You need a Webflow Cloud Next.js app, a Kajabi account on the plan that includes the Public API, and a Kajabi User API Key. The API is the part with a hard requirement. It is included with Kajabi's Pro plan and otherwise sold as a $25 per month add-on, so confirm your account has it before you start wiring calls.

Here is the full list of what you need:

• A Webflow Cloud project running a Next.js app, deployed or in local dev
• A Kajabi account with Public API access (the new Pro plan, or the Public API add-on)
• A Kajabi User API Key (client_id and client_secret) created in Settings > Public API (app.kajabi.com)
• At least one Kajabi Offer that grants access to the course you want to sell or gate
• Node.js 22.13.0 or higher locally, the minimum for Webflow CLI 2.0

The Offer is the piece people forget. In Kajabi, a Course is the content and an Offer is what actually grants access to it, so every "enroll this person" action in the API is really "grant this Offer."

Once these are in place, the integration is a handful of Route Handlers, and I usually have the first one returning live Kajabi data within an hour.

6 steps to integrate Kajabi online courses with a Webflow Cloud app

The integration covers the full lifecycle of a course on your site:

• Create an API key
• Authenticate to Kajabi
• List courses
• Check whether the current member has access
• Grant access after a purchase
• Keep everything in sync when Kajabi fires an event

Every step runs in a Route Handler on the Node.js runtime that Webflow Cloud provides through the OpenNext Cloudflare adapter, so the client_secret and the access token stay server-side and never reach the browser.

The order matters because each step builds on the one before it. Every later handler imports the token utility built in step two, so that is where the real work starts.

1. Create a Kajabi User API Key

Log in to app.kajabi.com and go to Settings > Public API. This page is where you create the credentials the API uses, and where you rotate or delete them later. Click Create User API Key, give it a name that identifies the project (for example, webflow-cloud), select the user and the permissions the key should carry, and click Create.

Kajabi shows you a client_id and a client_secret. Copy both now, because the secret is only fully visible at the time of creation. If it ever leaks, the same page lets you rotate the key, which invalidates all access tokens issued under the old secret without requiring you to rebuild the integration.

Add both values to .env.local and to your Webflow Cloud project under Settings > Environment Variables:

KAJABI_CLIENT_ID=your_client_id
KAJABI_CLIENT_SECRET=your_client_secret

Neither value gets a NEXT_PUBLIC_ prefix. The browser never touches these; only Route Handlers read them. Treating the client_secret as a server-only value is the single most important habit in this whole integration, and it is the reason the API path is safer than any client-side embed.

2. Build a Kajabi OAuth token utility for Webflow Cloud

Every authenticated Kajabi call requires a Bearer access token, which you obtain by exchanging your credentials at the /v1/oauth/token endpoint using the client_credentials grant.

Rather than doing that exchange in every handler, I keep it in a single utility and cache the token in memory for the lifetime of the isolate, since tokens are valid for a fixed number of seconds and re-requesting one on every call is wasteful.

Create lib/kajabi.ts:

// lib/kajabi.ts

const KAJABI_API = 'https://api.kajabi.com/v1'

type TokenResponse = {
  access_token: string
  refresh_token: string
  token_type: 'Bearer'
  expires_in: number
}

// Cache the token in module scope. It survives for the life of the
// Worker isolate, so warm requests skip the token exchange entirely.
let cached: { token: string; expiresAt: number } | null = null

async function getAccessToken(): Promise<string> {
  // Reuse the cached token until 60s before it expires.
  if (cached && Date.now() < cached.expiresAt - 60_000) {
    return cached.token
  }

  const body = new URLSearchParams({
    grant_type: 'client_credentials',
    client_id: process.env.KAJABI_CLIENT_ID!,
    client_secret: process.env.KAJABI_CLIENT_SECRET!,
  })

  const res = await fetch(`${KAJABI_API}/oauth/token`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body,
  })

  if (!res.ok) {
    throw new Error(`Kajabi token request failed: ${res.status}`)
  }

  const data = (await res.json()) as TokenResponse
  cached = {
    token: data.access_token,
    expiresAt: Date.now() + data.expires_in * 1000,
  }
  return data.access_token
}

// A thin wrapper so handlers never deal with tokens or base URLs directly.
export async function kajabiFetch(
  path: string,
  init: RequestInit = {}
): Promise<Response> {
  const token = await getAccessToken()
  return fetch(`${KAJABI_API}${path}`, {
    ...init,
    headers: {
      Authorization: `Bearer ${token}`,
      Accept: 'application/vnd.api+json',
      ...init.headers,
    },
  })
}

Two things in this code are doing real work:

(1) The token request is application/x-www-form-urlencoded, not JSON, because that is what the OAuth endpoint expects; sending JSON is the most common reason a first token call fails.

(2) The Accept: application/vnd.api+json header is also deliberate, because the Kajabi API follows the JSON:API spec and returns resources under a data key with separate attributes and relationships. Setting it once in the wrapper means every downstream handler receives correctly shaped responses without repeating the header.

This utility is the foundation. From here on, no handler talks to fetch directly; they all call kajabiFetch, which means token handling, the base URL, and the media type live in exactly one place.

3. Display the Kajabi course catalog from a Route Handler

The first useful thing your Webflow site can do is show the real list of courses straight from Kajabi, so the catalog is never out of date with what you actually sell. The endpoint is GET /v1/courses, and it supports pagination and filtering, plus sparse fieldsets for trimming the payload, all of which you proxy through a Route Handler so the browser only ever sees the fields you choose to expose.

Create app/api/courses/route.ts:

// app/api/courses/route.ts

import { kajabiFetch } from '@/lib/kajabi'
import { NextResponse } from 'next/server'

type KajabiCourse = {
  id: string
  type: 'courses'
  attributes: {
    title: string
    description: string
    status: string
    thumbnail_url?: string
  }
}

export async function GET() {
  // fields[courses] keeps the payload small; only ask for what the UI renders.
  const res = await kajabiFetch(
    '/courses?fields[courses]=title,description,thumbnail_url,status&page[size]=50'
  )

  if (!res.ok) {
    return NextResponse.json(
      { error: 'Failed to load courses' },
      { status: 502 }
    )
  }

  const { data } = (await res.json()) as { data: KajabiCourse[] }

  // Flatten the JSON:API shape into something the frontend can map over directly.
  const courses = data
    .filter((c) => c.attributes.status === 'active')
    .map((c) => ({
      id: c.id,
      title: c.attributes.title,
      description: c.attributes.description,
      thumbnail: c.attributes.thumbnail_url ?? null,
    }))

  return NextResponse.json({ courses })
}

The fields[courses] parameter is the part worth keeping. Kajabi returns a rich resource by default, and narrowing it to the four attributes the UI needs keeps the response small and means you are never accidentally shipping internal fields to the client.

Filtering to status === 'active' server-side is the same instinct: drafts stay private without any frontend logic.

From any Client Component in your Webflow Cloud app, the catalog is now a single fetch against your own endpoint:

// In a Client Component
const res = await fetch('/api/courses')
const { courses } = await res.json()
// Render courses; the Kajabi token never left the server.

Because the request goes through your Route Handler rather than directly to Kajabi, the access token stays server-side, and you have one place to add caching or filtering later. With the catalog rendering, the next question is the one that embeds can never answer: Does the person looking at it actually have access?

4. Check a member's course access server-side

Access checks have to run on the server, full stop. Hiding a "Continue learning" button with JavaScript is not access control, because anyone can open DevTools and see what was hidden. The correct approach is to ask Kajabi, from a Route Handler, whether a given person has been granted the Offer that opens the course, and to return only a yes or no to the browser.

The email must come from a verified session on your side, never from a query parameter the caller controls. A handler that answers any address is both a customer-list oracle and a bypass, because an attacker can simply pass a known buyer's address. Read the address from your own session cookie or token, and treat the query parameter below as illustrative only.

Kajabi models this on the Contact.

You look up the contact by email, scoped to your site, and ask whether they hold the Offer behind the course using the filter[has_offer_id] parameter.

Create app/api/access/route.ts:

// app/api/access/route.ts

import { kajabiFetch } from '@/lib/kajabi'
import { NextResponse, type NextRequest } from 'next/server'

type Contact = { id: string; type: 'contacts' }

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url)
  const email = searchParams.get('email')
  const offerId = searchParams.get('offerId')

  if (!email || !offerId) {
    return NextResponse.json({ error: 'Missing email or offerId' }, { status: 400 })
  }

  // Ask Kajabi for contacts on this site who hold the offer AND match the email.
  const query = new URLSearchParams({
    'filter[site_id]': process.env.KAJABI_SITE_ID!,
    'filter[has_offer_id]': offerId,
    'filter[email_contains]': email,
  })

  const res = await kajabiFetch(`/contacts?${query.toString()}`)

  if (!res.ok) {
    return NextResponse.json({ error: 'Lookup failed' }, { status: 502 })
  }

  const { data } = (await res.json()) as { data: Contact[] }

  // filter[email_contains] is a partial match, so a non-empty array is not an
  // answer on its own. Confirm the exact address before granting access.
  const target = email.trim().toLowerCase()
  const hasAccess = data.some(
    (c) => c.attributes.email.toLowerCase() === target
  )

  return NextResponse.json({ hasAccess })
}

Add KAJABI_SITE_ID to your environment variables; you can read it from any resource's site relationship or the /v1/sites endpoint. The combination of three filters is what makes this trustworthy:

• filter[site_id] scopes the search to your site
• filter[has_offer_id] restricts it to people who actually hold the Offer behind the course
• filter[email_contains] narrows it to the person asking

A matching exact address in the data array is a positive access result, and the browser only ever sees { hasAccess: true }.

The critical part is what you do with the answer. The boolean decides whether your server renders or returns the protected resource; it does more than toggle a CSS class. If the protected content is a lesson video URL or a download, serve it from this same handler only when hasAccess is true, the way you would gate any resource behind server-side session validation.

That way, the content never sits on the page waiting to be revealed. Newer Kajabi accounts can also use the filter[has_active_product_id] to check product ownership directly, which is handy when a single course is sold through multiple offers.

Note that product ownership and offer access are not identical, so use the product filter only when you specifically want to gate on the underlying product rather than the offer.

5. Grant course access after a purchase

When someone buys a course on your Webflow site, you need to grant them the matching Kajabi Offer so the course shows up in their Kajabi library. That is a single POST to the contact's offers relationship, and Kajabi handles the rest: it creates a customer record if one does not exist, sends the welcome email, and triggers any automations attached to the Offer.

The flow is to find or create the contact, then grant the offer.

Here is app/api/enroll/route.ts:

// app/api/enroll/route.ts

import { kajabiFetch } from '@/lib/kajabi'
import { NextResponse, type NextRequest } from 'next/server'

type Contact = { id: string; type: 'contacts' }

async function findOrCreateContact(email: string, name: string): Promise<string> {
  const siteId = process.env.KAJABI_SITE_ID!

  // 1. Look for an existing contact by email on this site.
  const lookup = await kajabiFetch(
    `/contacts?filter[site_id]=${siteId}&filter[email_contains]=${encodeURIComponent(email)}`
  )
  const { data } = (await lookup.json()) as { data: Contact[] }
  if (data.length > 0) return data[0].id

  // 2. None found: create one. JSON:API requires the vnd.api+json content type.
  const create = await kajabiFetch('/contacts', {
    method: 'POST',
    headers: { 'Content-Type': 'application/vnd.api+json' },
    body: JSON.stringify({
      data: {
        type: 'contacts',
        attributes: { name, email },
        relationships: {
          site: { data: { type: 'sites', id: siteId } },
        },
      },
    }),
  })
  const created = (await create.json()) as { data: Contact }
  return created.data.id
}

export async function POST(request: NextRequest) {
  // In production, only call this AFTER you have verified the payment.
  const { email, name, offerId } = (await request.json()) as {
    email: string
    name: string
    offerId: string
  }

  const contactId = await findOrCreateContact(email, name)

  // Grant the offer. The body is a JSON:API resource identifier array.
  const grant = await kajabiFetch(`/contacts/${contactId}/relationships/offers`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/vnd.api+json' },
    body: JSON.stringify({
      data: [{ type: 'offers', id: offerId }],
      meta: { send_customer_welcome_email: true },
    }),
  })

  if (!grant.ok) {
    return NextResponse.json({ error: 'Grant failed' }, { status: 502 })
  }

  return NextResponse.json({ enrolled: true })
}

The meta.send_customer_welcome_email flag is the lever most people want to pull. Leave it true, and Kajabi sends its standard welcome email; set it false when your Webflow app already sends its own onboarding sequence, and you do not want the buyer to get two.

The grant call is also idempotent on Kajabi's side, so it checks whether the contact already holds the Offer before creating a duplicate.

One rule overrides everything in this handler: never expose it as an open endpoint. Granting an Offer is giving away paid content, so this should run only after your server has confirmed a real payment, for example, inside a verified Stripe Checkout success flow or behind the same auth that protects the rest of your app. Treat /api/enroll as privileged code, not a public route. Derive the offer id server-side from the verified payment record rather than accepting it from the request body, or a caller who reaches the route can name whichever Offer they like.

6. Sync Kajabi events with a webhook Route Handler

Purchases do not always originate on your Webflow site.

Someone might buy directly through a Kajabi sales page or renew a subscription, and refunds happen too, and your app needs to hear about it. Kajabi's outbound webhooks cover this. You create one with POST /v1/hooks, passing a target_url, a site relationship, and an event such as purchase or payment_succeeded, and Kajabi posts a JSON body to that URL when the event fires. An Offer's Activation and Deactivation URLs run the other direction: those are inbound URLs you POST to in order to grant or revoke access, so they cannot notify your app.

A Route Handler is the right home for that URL.

Create app/api/webhooks/kajabi/route.ts:

// app/api/webhooks/kajabi/route.ts

import { kajabiFetch } from '@/lib/kajabi'
import { NextResponse, type NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  // 1. Gate the endpoint with a shared secret in the URL, since Kajabi's
  //    offer webhooks carry no documented signature to verify. Set this when you save the hook URL.
  const { searchParams } = new URL(request.url)
  if (searchParams.get('token') !== process.env.KAJABI_WEBHOOK_TOKEN) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // Hooks created through POST /v1/hooks deliver a JSON body, not form data.
  const body = (await request.json()) as {
    event?: string
    payload?: { member?: { email?: string }; email?: string }
  }
  const email = body.payload?.member?.email ?? body.payload?.email ?? ''
  if (!email) {
    return NextResponse.json({ error: 'No email in payload' }, { status: 400 })
  }

  // 2. Do not trust the payload alone. Re-query Kajabi to confirm the
  //    current state before changing anything in your own store.
  const siteId = process.env.KAJABI_SITE_ID!
  const offerId = process.env.KAJABI_COURSE_OFFER_ID!
  const verify = await kajabiFetch(
    `/contacts?filter[site_id]=${siteId}&filter[has_offer_id]=${offerId}&filter[email_contains]=${encodeURIComponent(email)}`
  )
  const { data } = (await verify.json()) as { data: unknown[] }
  const hasAccess = data.length > 0

  // 3. Persist the confirmed state (KV, a database, the Webflow CMS, etc.).
  // await saveEnrollment(email, hasAccess)

  return NextResponse.json({ received: true, hasAccess })
}

The shared-secret check on the first line is not optional, and it is the part I see skipped most often. Kajabi's offer activation and deactivation webhooks give you no documented signature to verify against, so a bare endpoint is something anyone who guesses the URL can POST to.

Putting a long random token in the query string and rejecting anything without it gives you a cheap but real gate. I have stopped trusting webhook bodies on their own entirely; the re-query on step two means even a forged payload cannot grant access, because the decision comes from Kajabi's own state, not from the request.

Where you persist the result is up to your app. A KV store or a serverless database such as Neon is the natural home for an enrollment record, and wrapping this handler in error tracking is worth it because a silently failing webhook is how access drifts out of sync.

With the webhook closing the loop, the integration now reflects Kajabi's reality, whether the purchase started on your site or theirs.

What breaks a Kajabi and Webflow Cloud integration?

Most failures here trace back to a few predictable causes:

• The wrong content type on the token request
• Missing or mismatched credentials between local and deployed environments
• The JSON:API media type is being dropped, or an open webhook endpoint

Each one tends to fail quietly, returning an error status with no obvious cause.

The symptoms below map to those causes, starting with the one that stops everything before it begins.

Token requests return 401 or invalid_client

The /v1/oauth/token call is failing authentication. Two causes account for almost all of these. First, the request body must be application/x-www-form-urlencoded, not JSON; if you send a JSON body, Kajabi cannot read the credentials and rejects the request.

Confirm you are building the body with URLSearchParams and setting the matching Content-Type header.

Second, check the credentials themselves. A rotated key invalidates every token from the old secret, so if the integration worked yesterday and not today, someone may have rotated the key in Settings > Public API.

Re-copy the current client_secret into your Webflow Cloud environment variables and redeploy, since a value that only exists in .env.local is not present in the deployed Worker.

Course or contact calls return 403 forbidden

The token is valid, but the User API Key does not carry the permission the endpoint needs. Kajabi scopes each key to the user and the permissions you selected when you created it, so a key made for reading contacts cannot grant offers.

Go back to Settings > Public API, open the key, and confirm it has the permissions for every resource your handlers touch: courses and contacts at a minimum, plus offers for the grant in step five. If you tighten permissions later for security, expect the corresponding handler to start returning 403 until the key is updated.

A 403 is also what you get when the key belongs to a user who cannot see the resource on the site in question. So when one site works, and another does not, check that the key's user has access to both sites before assuming the permission scopes are wrong.

Reads return the wrong shape or empty attributes

The JSON:API Accept header is missing. Without Accept: application/vnd.api+json, the API can return a different representation, and your code that reads data[].attributes.title finds nothing where it expects a value.

This is why the kajabiFetch wrapper sets the header once for every request. If you bypassed the wrapper for a one-off call, add the header back. Remember that resources come back under data with attributes and relationships as separate objects, so course.title is always course.attributes.title, never a top-level field.

The same applies to related data. When you request ?include=modules,lessons, those related records arrive in a top-level included array rather than nested inside the course, so you match them up by the IDs listed under the course's relationships.

Reading from the wrong place here is the most common reason a course renders, but its lessons appear empty.

Granting an offer returns 400 or creates duplicate customers

The grant request body is malformed, or the contact lookup was skipped. The body must be a JSON:API resource identifier array, { "data": [{ "type": "offers", "id": "OFFER_ID" }] }, sent with the application/vnd.api+json content type. A plain { offerId } object returns a 400 status code.

Duplicate customers arise when a new contact is created instead of reusing the existing one. Always run the filter[email_contains] lookup first and only create a contact when none comes back, the way the findOrCreateContact helper does.

Kajabi matches customers by email during a grant, so a clean find-or-create keeps one record per buyer. Watch the lookup itself, too: filter[email_contains] is a partial-match filter so that a short address can match multiple contacts.

In a high-volume store, I tighten the result by comparing the returned contact's exact email before reusing its ID, which avoids granting an offer to the wrong person who happens to share a substring.

The webhook fires, but access never updates

Either the endpoint is rejecting the call, or the payload is being trusted blindly.

First, confirm the shared-secret token in the saved Kajabi hook URL exactly matches KAJABI_WEBHOOK_TOKEN in your deployed environment; a mismatch returns 401, and Kajabi's delivery log will show the failure.

If the call is getting through but the state is wrong, the cause is usually trusting the webhook body instead of re-querying. Offer webhooks ship with no documented signature you can verify, so the payload is a notification, not proof.

Re-query Kajabi for the contact's current offer status inside the handler and persist that result, never the raw payload. One more timing trap is worth knowing about: webhook delivery and the API's read-after-write are not perfectly instantaneous. Hence, a re-query fired the same millisecond a hook arrives can occasionally read a stale state.

If you see fluctuating enrollment, add a short retry or a delay of a few seconds before the verifying read, and let the state settle.

Extend the Kajabi integration across your Webflow Cloud app

The six steps above cover the core loop: authenticate, list, check, grant, and sync. Once that loop is solid, the same kajabiFetch utility opens up the rest of the platform without new infrastructure.

A member portal is the most common next build. With the access check already server-side, you can pull a course's modules and lessons using GET /v1/courses/{id}?include=modules,lessons,lessons.media and render a real "my courses" view, the kind of authenticated, data-driven screen covered in building a real-time dashboard on Webflow Cloud.

Course thumbnails coming back from Kajabi are a good candidate for serving responsive, optimized images, so a catalog of large cover images does not slow the page. And because a webhook that fails silently is how enrollment quietly drifts, adding error tracking to the Webflow Cloud app around the sync handler pays for itself the first time Kajabi changes a payload.

Explore Webflow + Kajabi to compare the embed and automation approaches against the API path.