Governance · 14 / 23

Roles and permissions

Admin, Contributor and Viewer, checked on every protected API route rather than only hidden in the interface.

Members Invite member

Members

5 people who can sign in to this workspace.

MemberRoleStatusWorkspaces

Mara Lind mara@newsroom.example Admin Active 3 workspaces

Jonas Weber jonas@newsroom.example Contributor Active 2 workspaces

Aiko Tanaka aiko@newsroom.example Contributor Active 1 workspace

Priya Nair priya@newsroom.example Viewer Invited 1 workspace

Lucas Moreau lucas@newsroom.example Viewer Disabled No workspaces

1 Details 2 Role 3 Workspaces

What can they do? Continue to workspaces

How it works

01
Invite a member with one global role.
02
Choose the workspaces they can reach.
03
Every request is checked against that role’s permission keys.

Roles: Admin, Contributor, Viewer
Permission keys: 37, checked on the server
API tokens: Read-only or full access

In depth · For whoever signs off on access

Permissions checked by the API

Every protected route checks the caller’s permissions on the server; hiding a button in the interface is only a courtesy on top.

One file defines every role

Each route declares the permission keys it needs, and a guard checks them before the handler runs. The guard, the database seed and the tests all read the same role definitions, and removing a key removes the grant.

Twelve of the 37 permission keys against the three roles. An administrator holds every key; a contributor may create, update, publish, approve and delete content and media, but not manage users, tokens or webhooks; a viewer holds only reads — and, like every role, may use the assistant.
Permission	Admin	Contributor	Viewer
content:read	Yes	Yes	Yes
content:create	Yes	Yes	No
content:update	Yes	Yes	No
content:publish	Yes	Yes	No
content:approve	Yes	Yes	No
content:delete	Yes	Yes	No
media:delete	Yes	Yes	No
users:create	Yes	No	No
tokens:create	Yes	No	No
webhooks:manage	Yes	No	No
activity:read	Yes	No	No
copilot:use	Yes	Yes	Yes

Twelve of the 37 keys, the ones people ask about.

The three roles

Role	What it holds
Admin	All 37 keys.
Contributor	Eighteen keys: content and media, no users, tokens or webhooks.
Viewer	Seven keys, all reads, plus the assistant.

The 37 permission keys

Show the table

Area	Keys
Workspaces	workspaces:create · workspaces:read · workspaces:update · workspaces:delete
Users	users:read · users:create · users:update · users:delete · users:manage
Content	content:read · content:create · content:update · content:publish · content:approve · content:delete · content:export · content:import
Media	media:read · media:create · media:update · media:delete
API tokens	tokens:read · tokens:create · tokens:delete
Assistant	copilot:use · copilot:skills:manage
Audit	activity:read · activity:manage
Alarms	alarms:read · alarms:manage
Segments	segments:read · segments:manage
Webhooks	webhooks:read · webhooks:manage
Publication protection	protection:manage
Saved views	views:share
Content model	schema:manage

Decisions worth knowing

Publish and approve are separate keys: Somebody can write without making it live, or approve without editing.
Contributors can delete: Retracting is the same editorial act as publishing, and every delete is audited.
Every role can use the assistant: It holds the user’s own permissions, so a viewer’s assistant is read-only.
One role per person: Workspace membership decides where somebody may act.
Accounts are invite-only: There is no public sign-up; an administrator invites, or SSO provisions.

Questions

Can I make a custom role?

No. The three roles are fixed, so an access review is one list. Workspaces decide where each person may act.

Can I restrict somebody to one content type?

Partly, through workspaces: each is granted specific content types, and membership decides which workspaces somebody reaches.

How do API tokens fit?

A token carries a read or full scope instead of a role, and is granted to specific workspaces.

Full reference in the docs