Tenant members

The tenant members resource manages the roster of users with access to your tenant — useful for SCIM-style provisioners, Terraform-managed RBAC, or just batch role changes that would be tedious in the dashboard.

How members get added

POST is intentionally absent. New members join through the tenant invitations flow — create an invitation, the recipient accepts via the link in the email, and a membership row appears here. Bypassing the invitation flow would sidestep email verification + the consent moment, which is a posture we deliberately don't expose.

PATCH changes a member's role; DELETE is the equivalent of "kick from tenant".

ID quirk: encoded user UUID, not row UUID

The underlying tenant_members table has both a row UUID and a (tenant_id, user_id) composite, but every code path that addresses a member uses the user UUID. So the id field this API returns is tnm_<encoded user UUID> — round-trip-safe for GET / PATCH / DELETE. The raw user_id is also surfaced separately for clients that want to correlate with their own SSO records.

No notification emails

Role changes and removals via the public API do not trigger the "your role was updated" / "you've been removed" emails the dashboard sends. Operators using this API typically have their own change- notification pipeline; mirroring the dashboard emails would also pull this resource into a Resend dependency it doesn't currently have.

Notes

  • Capability-gated to owner/admin (or any member in flat-mode tenants).
  • The RPC enforces last-owner / self-action guards — you cannot demote the last remaining owner or remove yourself from a tenant.

Endpoints