How to Integrate Kinde with Your Headless CMS

What is Kinde?

Kinde is an authentication and identity platform for web and SaaS applications. It handles login, signup, social auth, SSO, multi-factor authentication, roles, permissions, organizations, and user management. Product and engineering teams use Kinde when they need developer-friendly auth without building identity flows from scratch.

Why integrate Kinde with a headless CMS?

Auth rules change more often than most teams expect. A pricing page adds a new plan, a help center adds partner-only articles, or a SaaS product introduces organization-level content. If Kinde controls who can access something, and your headless CMS controls what that thing says, those two systems need to agree.

Connecting Kinde to structured content lets you treat access rules as part of the content workflow instead of a separate spreadsheet. For example, an editor can publish a Sanity document with a permission key like "content.guides.pro.read", and a webhook or Sanity Function can create or update that permission in Kinde. Your frontend can then use Kinde session claims to decide whether to show the content, hide it, or ask the user to upgrade.

The disconnected version gets messy fast. Someone updates roles in Kinde, someone else edits gated pages, and a third person manually checks whether the access matrix still matches production. With Sanity, content is structured as typed JSON in the Content Lake, GROQ can select only the fields Kinde needs, and webhooks can trigger the sync when content is published, updated, or deleted.

Architecture overview

A typical Kinde and Sanity integration starts in Sanity Studio, where developers model access-related content as schema fields: permission keys, required roles, organization rules, plan labels, and gated content references. When an editor publishes one of those documents, a Sanity webhook fires with the document ID and mutation type. The webhook can call a Sanity Function or your own API route. That server-side code uses @sanity/client and GROQ to fetch the current published document from the Content Lake, including joined references such as roles or plans. It then requests a machine-to-machine access token from Kinde using the OAuth 2.0 client credentials flow, with the audience set to the Kinde Management API. With that token, the function calls Kinde's Management API to create or update permissions, roles, or organization metadata. At runtime, the end user signs in through a Kinde SDK, such as the Next.js SDK. Kinde returns session claims that include user, organization, role, and permission data. Your frontend uses those claims to render the right Sanity-powered experience, such as premium guides, customer-specific onboarding, or admin-only product documentation.

Common use cases

Step-by-step integration

1. 1

   Set up Kinde

   Create a Kinde account, add your application, configure callback URLs, and install the SDK for your app, such as @kinde-oss/kinde-auth-nextjs for Next.js. For server-to-server sync, create a machine-to-machine application, authorize it for the Kinde Management API, and copy the Kinde domain, client ID, and client secret into environment variables.

2. 2

   Model access rules in Sanity Studio

   Create schema types for access policies, plans, roles, or gated content. Include fields such as title, permissionKey, description, requiredRole, organizationCode, and references to the content that should use the rule.

3. 3

   Create a publish trigger

   Add a Sanity webhook that fires on create, update, and delete events for your access policy documents. Use a GROQ filter such as _type == "accessPolicy" so you don't sync unrelated content changes.

4. 4

   Add server-side sync logic

   Use a Sanity Function, API route, or small worker to receive the webhook. Fetch the published document from the Content Lake with @sanity/client and GROQ, then call Kinde's OAuth token endpoint and Management API from the server. Don't expose the Kinde client secret in browser code.

5. 5

   Connect the frontend experience

   Use the Kinde SDK in your frontend to handle login, logout, session checks, roles, permissions, and organization context. Use those claims to decide which Sanity content to query, render, or hide.

6. 6

   Test with real roles

   Create at least three test users: one with no gated permissions, one with a paid-plan permission, and one organization admin. Publish a Sanity access policy, confirm it appears in Kinde, and verify that each user sees the expected content.

How Sanity + Kinde works

CMS approaches to Kinde

Keep building

Explore related integrations to complete your content stack.