Tenants – Overview

​

Lifecycle

​

Endpoint reference

​

Typical call sequence

1. POST   /tenants/create              → returns "accepted"
2. GET    /tenants/infra/status (poll) → wait for all statuses true
3. POST   /ingestion/upload_knowledge  → start ingesting data
4. POST   /recall/full_recall          → query your data
5. GET    /tenants/monitor             → verify storage

GET /tenants/sub_tenant_ids → list active sub-tenants
GET /tenants/tenant_ids     → list all tenants in the org
GET /tenants/monitor        → check storage growth

DELETE /tenants/delete → schedule deletion (irreversible)

​

Key concepts

• Tenant – Top-level isolated workspace. One per organization in most cases.
• Sub-tenant – Subdivision inside a tenant. Created automatically the first time a sub_tenant_id is used. No explicit creation step, no confirmation.
• Default sub-tenant – Every tenant gets one at creation. API calls that omit sub_tenant_id target this default.
• Tenant metadata schema – Immutable field definitions set at creation. Cannot be changed later.

​

Related sections

• Essentials → Multi-Tenant Support – concepts, isolation guarantees, use cases
• Essentials → Metadata – tenant and document metadata
• API Reference → Ingestion – after tenant setup, start ingesting