client.admin — workspaces, users, roles, system keys
get_me tells you who the key is; client.admin.enabled is set from it when load_me=True.
Tenant-level operations (users, workspaces, roles, system keys) require a
tenant-admin / system key, not an ordinary workspace key.
Workspaces
Workspace fields: id, name, description.
Users (tenant)
Reading users needs a system key withusers:read, creating them users:invite and deleting them users:delete. Editing a user, their workspace memberships or their organization role, and suspending or reactivating them, needs org:admin.
TenantUser fields: id, email, display_name, tenant_admin, is_active, status (active, pending or suspended), tenant_role. TenantUserDetail adds metadata and memberships (each with workspace_name and role).
A user is never left without a workspace, and the organization’s last active admin cannot be suspended or deleted.
Roles
System keys (tenant-scoped)
System keys live in the tenant’s hidden admin workspace and may carry tenant-wide permissions (users:*, workspace:*, providers:manage, org:*, billing:manage) — ordinary workspace keys cannot. Mint them here:
ApiKey fields: id, name, tenant_admin, value, permissions.
client.variables — variables & secrets
Workspace-scoped key/value config. kind="secret" values are write-only (never returned on read).
client.files — raw file transfer
client.analytics — usage metrics
metric is the platform metric name; the window is [time_start, time_end]. Agent-specific dashboards (CSAT, topics, sentiment) live under client.insights instead — see Agent Insights.
All methods here have
a-prefixed async twins.