Tenants
A Tenant represents a company or developer that uses Zautha to add authentication to their application.
A Tenant represents a company or developer that uses Zautha. Each tenant gets a completely isolated environment — their users, sessions, API keys, and audit logs are invisible to every other tenant.
One Zautha customer = one tenant.
Properties
| Property | Type | Default | Description |
|---|---|---|---|
id | UUID | Auto-generated | Unique identifier |
name | string (max 255) | Required | Display name (e.g., "Acme Corp") |
slug | string (max 63) | Required, unique | URL-safe identifier (e.g., "acme-corp") |
plan | string | "free" | Subscription plan: free, pro, enterprise |
status | string | "active" | Status: active, suspended, deleted |
settings_json | JSON | {} | Custom tenant-wide settings |
Tenant Isolation
Zautha enforces tenant isolation at every layer. This is the most critical security property of the system.
Database Layer
Every tenant-scoped entity implements the ITenantScoped interface. The base TenantDbContext applies a global query filter so that every database query automatically includes WHERE tenant_id = @current_tenant. This makes it impossible to accidentally read another tenant's data.
API Layer
The tenant ID is derived from the authenticated admin session's JWT tid claim. It cannot be overridden by the client.
Cache Layer
Redis keys are prefixed with tenant:{tenant_id}: to prevent cross-tenant cache pollution.
Logging & Events
All log entries, domain events, and audit records include tenant_id for scoped querying and compliance.
API Endpoints
| Method | Path | Description |
|---|---|---|
POST | /v1/admin/tenants | Create a new tenant |
GET | /v1/admin/tenants/{tenant_id} | Get tenant details |
PATCH | /v1/admin/tenants/{tenant_id} | Update tenant name or settings |
Example
{
"id": "d316e6c5-2dfa-44de-9c91-9e933e073261",
"name": "Acme Corp",
"slug": "acme-corp",
"plan": "pro",
"status": "active",
"settings_json": {},
"created_at": "2026-01-15T10:00:00Z"
}