Multi-tenancy

Tenant isolation by tenant_id, per-tenant configuration, branding & email templates, and IP allow/deny rules.

Qeet ID is multi-tenant by design. Every resource is scoped by tenant_id, and that scoping is enforced on every query. A personal tenant is auto-created on signup, and a user can belong to multiple tenants.

Tenants

POST/v1/tenantsCreate a tenant

GET/v1/tenantsList tenants

PATCH/v1/tenants/{id}Update a tenant

const tenant = await qeetid.tenants.create({ name: "Acme, Inc." });

Switch the active tenant

A user with multiple memberships can switch — Qeet ID re-mints an access token scoped to the target tenant.

POST/v1/auth/switch-tenantRe-mint a scoped token

Per-tenant configuration

Almost everything is configurable per tenant:

Area	Endpoint
Auth policy (password rules, login methods, breach checks)	`/v1/tenants/{tenantID}/auth-policy`
ABAC policy	`/v1/tenants/{tenantID}/policy`
Branding	`/v1/tenants/{tenantID}/branding`
Email templates	`/v1/tenants/{tenantID}/email-templates`
IP allow/deny rules	`/v1/tenants/{tenantID}/ip-rules`
SSO connections (SAML/LDAP/social)	see Enterprise
Retention	`/v1/tenants/{tenantID}/retention`
Analytics overview	`/v1/tenants/{tenantID}/analytics/overview`

Branding & email templates

Each tenant has its own branding and can override transactional email templates (with a preview endpoint to check rendering before going live).

PUT/v1/tenants/{tenantID}/brandingUpdate branding

PUT/v1/tenants/{tenantID}/email-templates/{key}Override a template

GET/v1/tenants/{tenantID}/email-templates/{key}/previewPreview a template

IP allow/deny rules

Restrict access by CIDR per tenant — allow lists, deny lists, and a check endpoint.

GET/v1/tenants/{tenantID}/ip-rulesList IP rules

POST/v1/tenants/{tenantID}/ip-rulesAdd an IP rule (CIDR)

GET/v1/tenants/{tenantID}/ip-rules/checkCheck an IP

Analytics

Per-tenant KPIs — MAU/DAU, login / MFA / failed-login counts, and method mix.

GET/v1/tenants/{tenantID}/analytics/overviewTenant KPIs

Data residency + BYOK is a deployment concern: self-host in the region you need, and source the secrets-vault key from a regional KeyProvider (AWS KMS drops in). It isn't a per-tenant toggle in the API today.