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. For non-human callers — services or AI agents — follow the Agents & services pillar.

The path

1. Understand the four entities that model multi-tenancy → concepts
2. Choose your integration shape → decision
3. Build a working sign-in + org flow → quickstart & guides
4. Harden for production → go-live checklist
5. Look up exact request/response behavior → 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 — one OIDC identity provider instance per app (or per environment). This is your tenant boundary’s root.
• Organizations — your customers. Each is a tenant: members, invitations, and an isolated data boundary.
• Users — people, who can belong to multiple organizations (the consultant who works with three of your customers).
• 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.

2. Choose your integration

Three decisions determine your integration shape:

Decision	For B2B SaaS, usually…	Details
Which API?	The IdP API for user sign-in (OAuth 2.0 / OIDC); the Core API for managing orgs, users, and invitations from your backend.	The two APIs
SDK or raw OIDC?	The AuthPI SDK (@authpi/idp, @authpi/admin) — it handles PKCE, refresh, and org switching. Drop to raw OIDC only if you have an existing client library.	SDKs
What client type?	A Web client for a server-rendered or SPA app with a backend.	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 — 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 — App Router, Authorization Code + PKCE
• TypeScript backend quickstart — issuer, client, first authenticated user
• All quickstarts — Hono, Cloudflare Workers, and more

Add the multi-tenant flows:

• Create an organization and invite a teammate — the end-to-end onboarding outcome
• Organization lifecycle — create, suspend, and delete tenants
• Invitations — invite teammates into an organization
• Session management — list and revoke a user’s sessions
• Custom metadata — attach your own fields to users and orgs
• Validate tokens in your API — 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 — signature, iss, aud, typ, and the org claim, on every request
• JWKS & key rotation — cache keys, handle unknown kid on rotation
• Webhooks — react to organization.created, user.created, invitation events
• Idempotency — safe retries on org/user mutations
• Rate limits — what applies to your API-key-authenticated backend calls
• API keys — one minimally-scoped key per backend service

5. API reference

When you need exact parameters and response shapes:

• Core API reference — organizations, users, invitations, sessions, webhooks
• IdP API reference — the OIDC/OAuth runtime endpoints
• Token claims — every claim, including both organizations claim shapes
• OIDC compliance — discovery, supported flows, and standards conformance