Heimdall — tenants ship as a first-class primitive
Group your end-users into tenants ("organizations") inside any Heimdall app. EndUser JWTs now carry org_id + org_role, and members can switch tenants without re-authenticating.
If your product looks anything like Slack or Linear — one customer account that holds many users sharing data — you've been rebuilding tenancy on top of Heimdall manually. That stops now. Heimdall apps can opt into tenants, the same primitive Auth0, Clerk, and WorkOS expose as Organizations. A tenant is a named group of end-users inside a single app, with its own membership list, its own per-member role, and a stable public id of the shape tnt_a1b2c3d4e5f6.
Tenants are opt-in: existing apps that don't create any tenants behave exactly as before. When a user signs into a tenant, their EndUser JWT picks up two new claims — org_id and org_role — that your backend can authorize against without a second call. A new endpoint POST /:appSlug/v1/auth/switch-tenant reissues tokens against a different membership without making the user sign in again.
Tenant lifecycle and members are managed two ways: from your backend via the Consumer API (under /:appSlug/v1/tenants, gated by Platform API Keys carrying the new heimdall.tenant.* permissions), or from the Heimdall console UI on each app. Adding a member by email auto-creates an EndUser account if one doesn't exist yet — useful for inviting people who haven't signed up. Every mutation fires a webhook (tenant.created, tenant.member.added, etc.) so you can keep your own systems in sync.