Appearance

Roles and permissions ​

Each user in an account holds one of four roles: OWNER, ADMIN, MEMBER, or VIEWER. Roles form a strict hierarchy — each higher role can do everything the lower roles can, plus more. The role determines exactly which API actions and which console affordances are available.

A concrete example ​

You're the founder of Acme. You sign up — that makes you the OWNER. You invite your CTO with the ADMIN role; she can do everything except spend money or delete the account. You invite three engineers as MEMBERs; they can configure flags, configs, and loggers, but they can't manage users or billing. You invite the head of customer success as a VIEWER; she can browse the console and see what's running but can't change anything.

The four roles ​

OWNER ​

The financial decision-maker — typically the founder, the biller, or whoever holds the corporate card.

  • Pays the bill, manages subscriptions, adds and removes payment methods.
  • Can delete the entire account.
  • Can do everything an ADMIN can do, and everything a MEMBER can do, and everything a VIEWER can do.

Every account has exactly one OWNER. The role can't be transferred away through a routine PUT — see Transfer ownership.

ADMIN ​

The platform admin — typically a CTO, lead engineer, or operations lead.

  • Invites users, changes user roles (within their own constraints — ADMINs can only assign MEMBER or VIEWER), removes users.
  • Mints, rotates, and revokes API keys.
  • Creates, deletes, and promotes/demotes environments.
  • Can read billing information but can't change subscriptions or payment methods.

MEMBER ​

The day-to-day developer.

  • Reads, creates, updates, and deletes configs, flags, and context instances.
  • Renames and recolors environments (but can't create or delete them).
  • Can rename services.
  • Cannot mint API keys, manage users, or touch billing.

VIEWER ​

A read-only spectator — typically support, sales, or auditors.

  • Reads configs, flags, loggers, environments, services, contexts.
  • Updates their own profile and personal settings.
  • Cannot write any shared resource.
  • Can ingest metrics (the SDK posts metrics regardless of role).

Permission matrix ​

The authoritative version. Anything not on this list is read-only or self-management.

ActionOWNERADMINMEMBERVIEWER
Read all resources✓✓✓✓
Self-management (own profile, own settings)✓✓✓✓
Metrics ingestion (POST /metrics/bulk)✓✓✓✓
Configs, flags, loggers — create/update/delete✓✓✓
Context instances — create/update/delete✓✓✓
Context types — create/update/delete✓✓✓
Environments — rename, recolor✓✓✓
Services — create, rename, delete✓✓✓
Read users, list users✓✓
Invitations — create, list, revoke, resend✓✓
Change user role (within own scope)✓✓
Remove user from account✓✓
API keys — create, rename, revoke, delete✓✓
Environments — create, delete, promote/demote classification✓✓
Account settings (PUT /accounts/current, /settings)✓✓
Read billing (subscriptions, payment methods, invoices)✓✓
Subscriptions — create, upgrade, downgrade, cancel, uncancel✓
Payment methods — add, update, remove, set default✓
Account deletion✓

Constraints worth knowing ​

  • The OWNER can't be demoted via PUT /api/v1/users/{id}. The platform rejects with HTTP 400 "Cannot change the owner's role" — there's exactly one OWNER per account, and demoting the only OWNER would leave the account ownerless.
  • ADMINs can only assign MEMBER or VIEWER. An ADMIN can't promote anyone to ADMIN; only an OWNER can.
  • You can't remove yourself. DELETE /api/v1/users/{id} rejects when the target is the requester.
  • You can't remove the OWNER. Deleting the OWNER would leave the account ownerless. Use Transfer ownership instead.

Console affordances ​

The console hides what you can't do — buttons and clickable rows simply aren't rendered when your role wouldn't allow the action. This means:

  • VIEWERs and MEMBERs don't see the Account sidebar.
  • ADMINs see Account but don't see Subscriptions or Payment Methods.
  • Restricted action buttons (e.g. Promote to managed) are hidden, not disabled-with-tooltip.

The role is not the security boundary — the API enforces permissions independently and returns 403 if you bypass the UI. UI gating is for legibility.

Behind the scenes — backend enforcement ​

The backend uses three FastAPI dependencies:

  • require_owner — OWNER only
  • require_admin — OWNER or ADMIN
  • require_write — OWNER, ADMIN, or MEMBER

Each raises 403 Forbidden if the caller's role is insufficient. The dependency is declared on the route, so the role requirement is part of the OpenAPI spec and visible in the API reference.