Who needs it
The roles Account Platform is built for, and what each one can actually do here.
Account Platform is the identity layer every other product sits on, so almost everyone touches it somewhere — but most of that touch is invisible (signing in, staying signed in). This page covers what each role does on Platform's own visible surface: connecting accounts, managing the team, and the operator's own triage tools.
| Role | Comes here for |
|---|---|
| Workspace owner | Everything — team access, connecting platform accounts, API keys, sessions |
| Team member | Connecting/reconnecting their own scope's accounts, checking sync status, managing their own session and API keys |
| Trafficker | Nothing — Account Platform has no surface for this role |
| Platform operator | Reviewing problem reports across every tenant, outside any single workspace |
Workspace owner
Team access itself is exclusively the owner's: app/api/admin/team.py's own
module docstring states plainly that only the workspace owner manages team
access, "not a manager, not another teammate" — see
Manage team access. Beyond
that, the owner has the same reach as any team member below, without needing
a grant for it.
Team member
Platform's account-connection and session surface — connect.py, the
browser-runtime family, /api/me/api-keys — authenticates with
require_user/require_admin_principal and carries no owner-only statement
in its own module docstring, the same test this section's
admin-endpoints page uses
everywhere else. In practice, that covers:
- Connect or reconnect a platform account within their granted scope — see Connect an OnlyFans account and Reconnect a lost account.
- Check sync status for accounts they can see — see Check sync status.
- Manage their own session — timezone and display name are explicitly
self-service for "ANY panel principal — owner, creator, team member"
(
app/api/admin/auth.py's own comment on/auth/timezone), and Log out and clear sessions only ever acts on the caller's own session.
Not independently verified
/api/me/api-keys mints a key scoped to the calling principal's own
tenant id. Whether a team member's principal resolves to something useful
there, or to their own unrelated per-user id, wasn't traced end-to-end for
this page — don't assume team-member API keys work the way owner-minted
ones do without checking require_user's resolution for that case first.
Trafficker
Account Platform has no code surface for this role — a trafficker's work is smart links, domains, and traffic sources, all of which live in Link. See Boundaries.
Platform operator
require_platform_admin (app/core/auth.py) gates a distinct "operator
half" — the same principal require_owner accepts, but a deliberately
different gate name for a different class of door (the module's own comment
calls it that explicitly). Today that's problem-report triage across every
tenant at once: GET /api/admin/platform/reports,
PATCH /api/admin/platform/reports/{report_id}, and their attachment read —
see Admin endpoints. This is
separate from a workspace owner's own reach, which stays inside their own
tenant.
What's next
Boundaries — what Account Platform does and doesn't own, for the roles above and the other three products alike.