API permissions

API access is controlled by the same roles as in the Authorization Hub interface. Two kinds of roles apply:

• Platform roles (Tenant admin, Admin, and User) control who can create projects and manage users. Read User management for details.
• Project roles (Domain viewer, Project viewer, Project editor, and Project admin) control what a caller can do inside a project. Read Project roles for details.

Machine-to-machine clients are assigned project roles in the same way as users. Read Client management.

Project roles

Every request to a project's content, such as attributes, policies, or domains, is checked against the caller's role in the project identified by the X-Project-Id header. The caller must be a member of the project. If the caller is not a member, or the project does not exist, the request is rejected with 403 and the PROJECT_FORBIDDEN_ACTION error code.

Request	Domain viewer	Project viewer	Project editor	Project admin
Read domains (GET on the domain manager endpoints listed below)	✔️	✔️	✔️	✔️
Read any other project content (any GET)	❌	✔️	✔️	✔️
Change project content (POST, PUT, PATCH, DELETE)	❌	❌	✔️	✔️
Compose or roll back a domain	❌	❌	✔️	✔️

note

The rule is based on the HTTP method. Because of this, a Project viewer cannot call endpoints that use POST to run something without changing data, such as running a policy insights report.

Domain viewers

A Domain viewer can only read domains. The following GET requests are allowed. Every other project request returns 403.

Endpoint	Purpose
/api/adm/namespaces/<project-id>/names	List the domain names.
/api/adm/namespaces/<project-id>/names/<domain>/domain	Get a domain.
/api/adm/namespaces/<project-id>/names/<domain>/history	Get the domain's history.
/api/adm/namespaces/<project-id>/domains/metadata	List the domains' metadata.
/api/adm/namespaces/<project-id>/names/<domain>/policy	Get the policy package stored in the domain manager.
/api/adm/namespaces/<project-id>/names/<domain>/domain/policy/alfaSpecifications/<file>	Get a single ALFA file of a domain.

Requests without a project role check

The following endpoints are not subject to the project role rules above:

• /api/projects: Access is determined by the rules in Projects and users.
• /api/principal: Reading users and clients is available to any authenticated caller. Creating and updating users requires a platform role.
• /api/drafts: Every caller works with their own workspace. Read My workspace and the API for details.

Platform roles

Most endpoints are available to any authenticated caller. The following require a platform role:

Request	Required role
Create a project (POST /api/projects)	Admin or Tenant admin
Invite users (POST /api/principal/users)	Admin or Tenant admin
Update users (PATCH /api/principal/users)	Admin or Tenant admin
Update a project (PATCH /api/projects/<project-id>)	Tenant admin, or Project admin of that project

Further rules apply when managing users:

• Only a Tenant admin can assign the Tenant admin role.
• An Admin cannot edit a Tenant admin.
• A Tenant admin cannot remove their own role if no other active or invited Tenant admin exists.
• A Tenant admin cannot change their own status.
• A Tenant admin can only hold the Project admin role in a project.

A request that fails a platform role check returns 403 with the INSUFFICIENT_PERMISSIONS error code.

Permissions by area

The tables in the endpoint reference show the project role that applies. The rule above is applied uniformly:

Area	Read	Create, change, or delete
Attributes, namespaces, cache profiles	Project viewer	Project editor
Attribute connectors	Project viewer	Project editor
Policies	Project viewer	Project editor
Domains	Domain viewer (domain manager reads)	Project editor (compose, rollback)
Policy insights	Project viewer	Project editor
Activity feed	Project viewer	Not applicable
Project details and members	Any member	Project admin or Tenant admin