Skip to content

Tenant lifecycle

The admin endpoints manage a tenant’s lifecycle. They are identical between the Auth Relay and the Chat Relay, save for a few differences noted below. All are protected by the X-Admin-Key header (an operator key, distinct from tenant secrets).

One simple rule, everywhere:

  • provision takes a JSON body. It is the only creation call; it receives the tenant’s full configuration in the body.
  • Everything else takes ?tenant_id= as a query parameter (update, rotate/*, suspend, reactivate, fetch). update additionally takes a partial body.
MethodPathParamsEffect
POST/provision/tenantJSON bodyCreates the tenant; returns tenant_id + tenant_secret once.
POST/update/tenant?tenant_id= + bodyPartial config update.
POST/rotate/tenant-secret?tenant_id=New tenant_secret; the old one is invalidated immediately.
POST/suspend/tenant?tenant_id=Blocks signed calls (403) until reactivated.
POST/reactivate/tenant?tenant_id=Lifts the suspension.
GET/fetch/tenant?tenant_id=Returns the config (never the secret).
GET/fetch/tenants?limit=&offset=Paginated list.

Per-relay differences:

  1. Call POST /rotate/tenant-secret?tenant_id=... with X-Admin-Key.
  2. Read the new tenant_secret from the response (shown once).
  3. Deploy it to your backend’s secrets vault.
  4. The old secret stops signing validly immediately: plan for a brief cutover.

Suspension is reversible and immediately blocks all of the tenant’s signed calls (a 403 response). It is the lever to pull during an incident: suspend now, investigate, then reactivate.