Workflows: Manage tenants

Tenant lifecycle: list, create, edit, deactivate.

Prerequisites

• acaso_os:admin on the connection. Tenant administration is cross-tenant and admin-gated. Operators without admin do not see the Tenants nav item.

List tenants

Open /tenants. The page calls GET /v1/admin/tenants and lists every tenant on the connected AcasoOS instance with slug, name, active flag, created date, and a one-line summary of active templates.

Note: This is the only console surface that crosses tenant boundaries. It works because the tenants table has no RLS — admin endpoints connect with the bare engine and check acaso_os:admin at the application layer.

Create a tenant

Click New tenant. The form:

Field	Required?	Notes
Slug	yes	URL-safe handle. Immutable. Lowercase, dashes, no spaces.
Name	yes	Display name. Editable later.
Data residency	no	Region hint used by downstream model-endpoint selection.
Active templates	no	List of agent templates the tenant opts into.
langgraph_checkpoint_retention_days	no	How long LangGraph keeps chat state. Default applies if omitted.

Submit calls POST /v1/admin/tenants. The bootstrap flow runs server-side: default roles (admin, member, viewer) are installed, a system user is created, and the tenant is ready to accept its first key.

Edit a tenant

Open the tenant detail page. Editable fields: name, data_residency, active_templates, langgraph_checkpoint_retention_days. Save calls PATCH /v1/admin/tenants/{slug}.

The slug is immutable. To rename a tenant for URL purposes, create a new one and migrate data; v1 does not support slug changes.

Mint the first key

A freshly created tenant has no API keys. To use the console against it, do one of:

1. Run python -m datahub.interface.cli.bootstrap on the AcasoOS host.
2. Open the new tenant's Keys subpage from the console and mint a human key bound to a user the tenant has (you may need to create the user first via POST /v1/users in a separate connection).

See Workflows: Mint and revoke API keys for the full minting flow.

Soft-deactivate

Click Deactivate on a tenant detail page. The console calls DELETE /v1/admin/tenants/{slug}. The tenant's active flag flips to false; the row is greyed in the list with an "inactive" badge.

Warning: Deactivation does NOT revoke existing keys. Sessions against the deactivated tenant continue to authenticate until the keys are revoked separately. Revoke keys explicitly when offboarding a customer.

Subsequent data calls into a deactivated tenant may fail depending on policy. An acaso_os:admin operator can still reach /v1/admin/tenants/* to reactivate; flip active back to true and the tenant resumes normal service.