Managing organizations
Creating tenants, inviting people, changing roles and reading the client code.
Creating a tenant (staff)
Account → Organizations → Create organization (staff only). Enter the name and slug; the client code is minted on the server and shown read-only on the organization's Settings page afterwards. Staff become owners of the new organization automatically.
Programmatically: POST /api/auth/organization/create with a staff session. Non-staff callers receive
403.
People
The People page (/organization/<slug>/people) lists members with their role and pending invitations.
| Action | Who | API |
|---|---|---|
| Invite | owner, admin, staff | POST /organization/invite-member |
| Cancel invitation | owner, admin, staff | POST /organization/cancel-invitation |
| Change role | owner (any), admin (below owner) | POST /organization/update-member-role |
| Remove member | owner, admin, staff | POST /organization/remove-member |
| Leave | the member | POST /organization/leave |
Staff memberships cannot be removed or re-roled by tenants; those requests fail with STAFF_MEMBERSHIP.
Settings
Owners and staff can rename an organization. The slug and client code are fixed after creation because backends and URLs depend on them. Organization deletion is disabled outside development; ask staff to retire a tenant.
Switching organizations
Users who belong to several organizations switch from the header. Switching updates the session's active
organization, which changes what /api/auth/token mints. Apps that need a specific organization should call
/api/token?org=<slug> and ignore the active one.
Reading tenancy in your app
From the browser client:
const { data: org } = authClient.useActiveOrganization();
const clientCode = (org?.metadata as { "client-code"?: string } | undefined)?.["client-code"];From a backend: read org_meta["client-code"] from the verified JWT.