Security

Roles and permissions

What each workspace role can read and change, and how read-only viewers are enforced in the API and console.

Workspaces have five roles. The owner is the account that created the workspace and cannot be removed; every other member gets one of the four roles below.

Role summary

Role	Read events, deliveries, endpoints	Change endpoints, destinations, templates, alerts	Manage secrets	Manage members and billing
`owner`	✅	✅	✅	✅
`admin`	✅	✅	✅	❌
`member`	✅	✅	❌	❌
`developer`	✅	✅	❌	❌
`viewer`	✅	❌	❌	❌

“Change” covers endpoints, destinations, payload templates, transformations, variables, alert rules, task runs and API keys. Secrets are limited to owners and admins. Only the workspace owner can invite members, change roles and manage billing.

Read-only viewers

A viewer can sign in and inspect everything a project member can read: endpoints, events, deliveries, payloads, runs, alert history, usage and billing. Every mutating request (POST, PUT, PATCH, DELETE) is rejected before the route handler runs:

HTTP/2 403
content-type: application/json

{ "error": { "code": "AUTHORIZATION_DENIED", "message": "Viewers have read-only access to this workspace" } }

The rule is enforced for session cookies, API keys and CLI tokens alike, because the role is resolved from the workspace membership on each mutating request. A viewer’s API key can still be used for read scopes; it cannot create or change configuration.

The console hides the actions a viewer cannot perform rather than letting the API reject them: the top bar shows a Read-only badge instead of Add Endpoint, and create, edit, retry and delete controls are removed from the endpoints, destinations, deliveries and alerts pages.

Changing a role

Only the workspace owner can invite members and change roles. Use Settings → Members in the console, or the members API:

PATCH /v1/members/{userId}
content-type: application/json

{ "role": "viewer" }

The change takes effect on the viewer’s next request; existing sessions do not need to sign out.