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.

People join an organization by invitation: an Owner or an Admin invites them, and they accept. Nobody becomes a member by sharing the organization's email domain.

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
Turn a key's kill switch on and off 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
Turn the organization's kill switch on and off 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. An invitation never makes someone an Owner, and an Owner can make an invited member one.
  • 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.

Belonging to more than one organization

A person can be a member of several organizations, the one they founded and any they were invited to, and holds a role in each; the account menu switches between them, whatever the role. Founding is different: one verified mailbox founds one organization, and a second of your own is set up by Recovea on request (One organization per email).

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.