Sign in

Concepts

Roles

The five roles, Owner, Admin, Member, Billing and Viewer, and what each may do, from the capability table the server enforces on every platform route.

View as markdown
On this page

An organization has members, and each member holds one of five roles: Owner, Admin, Member, Billing or Viewer. The server enforces them on every platform route from one table, before any handler runs; the platform mirrors the same table, so a role sees the state and the reason where it cannot act, never a control that fails on click. Seats are unlimited on every plan.

What each role may do

Owner Admin Member Billing Viewer
Sign in, edit your own profile and notification preferences, read the plans and the reference price list yes yes yes yes yes
See requests, spend, attribution, receipts and the ledger export, caps and alerts, runs, keys, provider keys and projects yes yes yes no yes
See billing and invoices yes yes yes yes yes
See members and invites yes yes yes no yes
Mint, rotate and revoke gateway keys yes yes yes no no
Set, edit, arm, disarm and delete caps on keys, and their alerts yes yes yes no no
Set, edit, arm, disarm and delete the organization's cap, and its alerts yes yes no no no
Add, rotate and remove provider keys; declare an upstream; connect a usage import yes yes no no no
Edit the run policy, and close a run yes yes no no no
Invite people, change roles, remove members yes yes no no no
Rename the organization, create and archive projects, assign a key to a project, set the organization's notification contacts yes yes no no no
Start, change and cancel the plan yes yes no yes no
Delete the organization yes no no no no

What the table means in practice

  • Owner can do everything. Only an Owner can delete the organization, and only an Owner moves ownership: "Only an Owner can change who owns this organization." An organization always keeps at least one Owner.
  • Admin can do everything else. Admin is the role that runs the estate day to day: caps on the organization, provider keys, people, projects and the run policy.
  • Member builds with Recovea: a Member mints and rotates keys, caps keys and sets their alerts, and reads everything an engineer needs. A Member can act on any key in the organization, not only keys they minted: nothing records who minted a key, and the fence is the route, not the key. A Member cannot change the organization's own cap; the server refuses with "Only owners and admins can change the organization cap."
  • Billing handles the plan and the invoices and sees nothing of the traffic: no requests, no caps, no keys. The Limits page tells a Billing user "Your role can see billing, not caps. Limits are part of the organization’s operating surface."
  • Viewer reads everything a Member reads and changes nothing, and cannot mint a key.

Where the organization's cap is fenced

Creating a cap on the organization and creating a cap on a key are the same route, so the route table alone cannot tell them apart. Every budget route requires the cap-writing capability that Owner, Admin and Member hold; inside each handler, once the cap's scope is known, a second check refuses a change to the organization's own cap from anyone but an Owner or an Admin. Where a cap is set has the cap-by-cap table.