Overview
Tenants provide data isolation within an application. Each tenant can have its own authentication configuration and user base.PUT /recipe/multitenancy/tenant
Create or update a tenant configuration.Request Body
Parameters
- tenantId (string, optional): Unique identifier for the tenant. If not provided, defaults to “public”
- emailPasswordEnabled (boolean, optional): Enable email/password authentication
- passwordlessEnabled (boolean, optional): Enable passwordless authentication
- thirdPartyEnabled (boolean, optional): Enable third-party (social) authentication
- coreConfig (object, optional): Tenant-specific configuration overrides
- firstFactors (array, optional): List of allowed first-factor authentication methods
- requiredSecondaryFactors (array, optional): List of required second-factor authentication methods
Response
- createdNew:
trueif a new tenant was created,falseif existing tenant was updated
Example
GET /recipe/multitenancy/tenant
Retrieve tenant configuration.Query Parameters
The tenant is identified from the request context (headers or domain).Response
Error Response
Example
GET /recipe/multitenancy/tenant/list
List all tenants for the current app. Note: This endpoint can only be called from the public tenant.Response
Example
DELETE /recipe/multitenancy/tenant
Remove a tenant.Request Body
Response
- didExist:
trueif the tenant existed and was deleted,falseif it didn’t exist
Example
User-Tenant Association
POST /recipe/multitenancy/tenant/user
Associate a user with a tenant.Request Body
Response
POST /recipe/multitenancy/tenant/user/remove
Disassociate a user from a tenant.Request Body
Response
Implementation Details
- Located in:
src/main/java/io/supertokens/webserver/api/multitenancy/CreateOrUpdateTenantOrGetTenantAPI.java:35andListTenantsAPI.java:39 - Recipe:
MULTITENANCY - Tenant IDs are normalized and validated before use
- The public tenant (ID: “public”) is created automatically
- Protected configuration values can be hidden based on API key permissions
- Tenant configuration supports version-specific JSON formats
Permissions
- Listing tenants requires calling from the public tenant of an app
- Creating/updating tenants can be done from any tenant context
- The public tenant cannot be deleted
Best Practices
- Use descriptive tenant IDs (e.g., “acme-corp” instead of “t1”)
- Configure authentication methods per tenant based on requirements
- Test authentication flows after creating/updating tenants
- Keep tenant-specific configuration minimal - use app-level defaults when possible
- Document your tenant structure and authentication setup