Manage end users
End users are the consumers of your tenant's published Applications. Anyone who connects an AI client to your MCP server, signs into your web app, or grants a workload access to your APIs is an end user. They are not members of your tenant. See Members vs End Users.
Where to find it
End Users in the admin UI (/end-users). This is the default workspace — it's where you'll spend most of your operational time.
What you can do
- List and search end users by email / username substring.
- Filter by status (
active/suspended) and plan tier. - Suspend an end user — every token they hold against any of your Applications immediately fails introspection. Their identity and consents with other tenants are untouched.
- Reactivate a suspended end user.
- Set a plan tier (
free,pro, or a custom string). Plan tier drives role binding via your billing policy (Phase E). - Override rate limits on a per-user basis (Phase E).
End-user lifecycle
End users are created lazily. The first time someone consents to one of your Applications, AuthSec inserts a tenant_end_user_states(tenant_id, user_id) row with status='active' and tracks first/last activity. You do not invite end users; they self-onboard through OAuth.
End-user fields
| Field | Description |
|---|---|
| User | Email / username (from the underlying identity record) |
| Status | active or suspended |
| Plan tier | free, pro, or any custom string |
| First consent | Timestamp of the first OAuth consent against any of your Applications |
| Last seen | Last activity timestamp (introspection / refresh / tool call) |
| Rate-limit override | Optional JSON overriding plan defaults |
Plan tier and roles
Setting plan_tier='pro' does not automatically grant Pro-tier permissions. Phase E ships a plan-to-role mapping policy that reconciles role_bindings whenever a tier changes. For Phase A you can manually bind plan-tier roles via Authz → Assignments with the user as subject.
Suspending end users vs deleting
Suspend when you want to block access reversibly (abuse, payment issues, security investigation). Their consents, tokens, and audit history are preserved.
Hard delete of an end user identity is a v3 / GDPR feature handled by /v2/me/delete. In Phase A, suspended is the only state you should use.
API reference
| Method | Path | Purpose |
|---|---|---|
GET | /uflow/v2/tenants/:tenant_id/end-users | List (filters: status, plan_tier, q) |
GET | /uflow/v2/tenants/:tenant_id/end-users/:user_id | Get one |
PATCH | /uflow/v2/tenants/:tenant_id/end-users/:user_id | Update status / plan_tier / rate_limit_override |
POST | /uflow/v2/tenants/:tenant_id/end-users/:user_id/suspend | Convenience: suspend with reason |
POST | /uflow/v2/tenants/:tenant_id/end-users/:user_id/reactivate | Convenience: reactivate |
Bulk operations
Phase A ships single-user actions only. Bulk suspend / bulk plan change / CSV export land in Phase B alongside the tool policy editor.