Team roles

Three roles. You assign two of them; the third is you.

The dashboard stores exactly two assignable values, admin and viewer, and rejects anything else. There is no custom role, no per-page permission and no way to grant one capability without the rest of its tier — which keeps the decision small, at the cost of it being coarse.

The matrix

Two boundaries, and they are not in the same place:

Admin versus viewer is read against write. A viewer sees everything and changes nothing; an admin operates the tools.

Owner versus everyone is the account itself. Credentials, membership and money never delegate, so several rows above stay owner-only even for an admin. That is deliberate, and it is the reason handing out an admin seat is a smaller decision than it looks.

Viewer

Read-only access to keys, analytics and usage.

A viewer sees the whole workspace with every control disabled, and the pages that show data rather than settings mark themselves View only rather than hiding anything. That is more useful than it sounds: most of what a colleague needs is to look — at what an integration is spending, at whether a call actually arrived, at which key an environment is using.

The right role for anyone who needs to answer questions rather than change things: a manager watching spend, an engineer debugging a client's integration, someone on support triaging a report.

Two things a viewer can still do, which surprise people:

Run the playground, including against the workspace's own key. Read-only governs settings, not requests, so a viewer can spend the account's credits one call at a time. The key picker labels which key each call will use — see workspaces.

Read every credential on the page. Which is the next note.

Admin

Everything a viewer can do, plus manage the tools.

An admin runs the day-to-day: managing the platform tools, exporting the audit history on Mega, and asking the AI Assistant about the account — the one tool a viewer is shut out of entirely, because its token allowance belongs to the account being viewed.

On the developer side that means creating and editing mock endpoints, managing JSON bins, and configuring embedded forms.

What an admin cannot do is touch credentials or the account. Key management is owner-only — attempting to rotate a key or create a sub-key from a workspace you do not own is refused outright (Only the workspace owner can manage keys), regardless of role. Billing, membership and the account's own profile and security settings are the same.

So the honest description of admin is operator, not deputy: enough to keep an integration running, not enough to change what the account is.

Owner

You. There is exactly one, and the role cannot be transferred from the dashboard — moving ownership means moving the subscription, which is a support conversation rather than a button.

The owner-only actions are the ones where a mistake is expensive or irreversible:

Rotating a key takes effect instantly and with no grace period, so it can break every integration on the account in one click. See key rotation.

Issuing and scoping sub-keys creates credentials that bill to your account and outlive any seat, so they stay with the person who pays for them. See sub-keys.

Membership — inviting, removing and re-roling — is how access itself is controlled, and it would be circular to delegate it.

Billing and plan changes move real money.

Changing someone's role

Teams, then switch the member between admin and viewer. It takes effect immediately, including in a session they already have open, and it is recorded in the audit history on Mega.

Roles are per workspace. Being an admin on one account says nothing about your role on another — each owner decides separately, and a member of several teams can hold a different role in each.

Changing a role does not disturb anything else: no re-invite, no seat change, no effect on keys.

Choosing a role

Start people as viewers. It is the right answer for most people who ask for access, and the upgrade takes five seconds when it turns out to be wrong.

Promote to admin when someone is actually operating the tooling — maintaining mocks, configuring forms, keeping bins tidy — rather than reading about it. Because key management is owner-only anyway, the promotion grants less than the word suggests.

If what needs access is a system and not a person, no role is right. Issue it a sub-key, scope it to what it calls, and revoke it on its own when the job ends. A seat is for someone who signs in.

Next

Invites covers getting someone into the account in the first place, and workspaces covers what it looks like from their side.