> Markdown version of https://authpi.com/docs/use-cases/b2b-saas/ — fetch the complete AuthPI docs index at https://authpi.com/llms.txt to discover all available pages.

# Build multi-tenant B2B SaaS

The end-to-end path to add authentication and organization-based multi-tenancy to a B2B SaaS app with AuthPI — from concepts to a working integration to production.

You're building software sold to **companies**, not individuals: each customer is a tenant with its own users, roles, and data boundary. Users belong to one or more organizations, admins invite teammates, and a token has to say *which* organization a request is acting in. This page is the whole path — from the concepts you need, to choosing an integration, to a working app, to going live.

If you're instead adding login for individual consumers, follow the [B2C login pillar](/docs/use-cases/b2c-login/). For non-human callers — services or AI agents — follow the [Agents & services pillar](/docs/use-cases/agents-and-services/).

## The path

1. **Understand** the four entities that model multi-tenancy → [concepts](#1-understand-the-model)
2. **Choose** your integration shape → [decision](#2-choose-your-integration)
3. **Build** a working sign-in + org flow → [quickstart & guides](#3-build-it)
4. **Harden** for production → [go-live checklist](#4-go-to-production)
5. **Look up** exact request/response behavior → [API reference](#5-api-reference)

---

## 1. Understand the model

AuthPI models a B2B tenant with four entities. Read these in order — fifteen minutes total — and the rest of the path will make sense:

- [**Issuers**](/docs/concepts/issuers/) — one OIDC identity provider instance per app (or per environment). This is your tenant boundary's root.
- [**Organizations**](/docs/concepts/organizations/) — your customers. Each is a tenant: members, invitations, and an isolated data boundary.
- [**Users**](/docs/concepts/users/) — people, who can belong to **multiple** organizations (the consultant who works with three of your customers).
- [**Multi-org tokens**](/docs/concepts/multi-org-tokens/) — how a single token expresses *which* organization a request acts in, and how you switch active org. This is the concept most B2B integrations get wrong — don't skip it.

New to the platform entirely? Start with the [five-minute overview](/docs/concepts/overview/).

## 2. Choose your integration

Three decisions determine your integration shape:

| Decision | For B2B SaaS, usually… | Details |
|---|---|---|
| **Which API?** | The [IdP API](/docs/reference/idp-api/) for user sign-in (OAuth 2.0 / OIDC); the [Core API](/docs/reference/core-api/) for managing orgs, users, and invitations from your backend. | [The two APIs](/docs/concepts/overview/) |
| **SDK or raw OIDC?** | The [AuthPI SDK](/docs/sdks/) (`@authpi/idp`, `@authpi/admin`) — it handles PKCE, refresh, and org switching. Drop to raw OIDC only if you have an existing client library. | [SDKs](/docs/sdks/) |
| **What client type?** | A **Web** [client](/docs/concepts/clients/) for a server-rendered or SPA app with a backend. | [Clients](/docs/concepts/clients/) |

## 3. Build it

Run the golden path first, then wire sign-in for your stack, then layer in the org-specific flows:

**Stand up the identity model** (15 minutes, terminal only):
- [Multi-tenant identity in 15 minutes](/docs/quickstarts/multi-tenant/) — the canonical setup: issuer → client → first organization → org-scoped credential → event trail. Everything below builds on this.

**Get sign-in working** (pick your stack):
- [Next.js quickstart](/docs/quickstarts/nextjs/) — App Router, Authorization Code + PKCE
- [TypeScript backend quickstart](/docs/quickstarts/typescript-backend/) — issuer, client, first authenticated user
- [All quickstarts](/docs/quickstarts/) — Hono, Cloudflare Workers, and more

**Add the multi-tenant flows:**
- [Create an organization and invite a teammate](/docs/use-cases/invite-a-teammate/) — the end-to-end onboarding outcome
- [Organization lifecycle](/docs/guides/org-lifecycle/) — create, suspend, and delete tenants
- [Invitations](/docs/guides/invitations/) — invite teammates into an organization
- [Session management](/docs/guides/session-management/) — list and revoke a user's sessions
- [Custom metadata](/docs/guides/metadata/) — attach your own fields to users and orgs
- [Validate tokens in your API](/docs/guides/validate-tokens/) — verify the access token and read the active-org claim

## 4. Go to production

Don't ship until you've worked through these — the content lives in Reference, but every B2B integration needs them:

- [ ] [**Verify tokens correctly**](/docs/guides/validate-tokens/) — signature, `iss`, `aud`, `typ`, and the org claim, on every request
- [ ] [**JWKS & key rotation**](/docs/reference/jwks-key-rotation/) — cache keys, handle unknown `kid` on rotation
- [ ] [**Webhooks**](/docs/guides/webhooks/) — react to `organization.created`, `user.created`, invitation events
- [ ] [**Idempotency**](/docs/reference/idempotency/) — safe retries on org/user mutations
- [ ] [**Rate limits**](/docs/reference/rate-limits/) — what applies to your API-key-authenticated backend calls
- [ ] [**API keys**](/docs/guides/api-keys/) — one minimally-scoped key per backend service

## 5. API reference

When you need exact parameters and response shapes:

- [Core API reference](/docs/reference/core-api/) — organizations, users, invitations, sessions, webhooks
- [IdP API reference](/docs/reference/idp-api/) — the OIDC/OAuth runtime endpoints
- [Token claims](/docs/reference/token-claims/) — every claim, including both `organizations` claim shapes
- [OIDC compliance](/docs/reference/oidc/) — discovery, supported flows, and standards conformance