Scopes & permissions

MyCLM has one access model for people and integrations: permissions, granted by a role, on a node of the organization tree (and everything below it). Each endpoint of the API reference lists the permission it needs.

Permissions

Permission	Allows
org.manage	Manage the organization itself (and consent to partner applications).
nodes.manage	Create, rename and delete entities and groups.
members.read / members.manage	See / invite, move and remove members.
roles.manage	Create custom roles.
features.manage	Configure features and their settings.
integrations.manage	Manage API keys, connected apps and webhooks (in the app).
tasks.use	Create and work on tasks (own or assigned).
tasks.read_all	See every task of the scope (scope=team).
signature.read / signature.send / signature.manage	See / send / manage every request.
registered_mail.read / registered_mail.send / registered_mail.manage	See / send / manage every mail and the sender accounts.
contacts.read / contacts.write / contacts.manage	See / create and edit own contacts / edit every contact, import, export and merge.

Roles

Every organization has five system roles, plus the custom roles its administrators create (GET /v1/orgs/{orgId}/roles).

Role	Permissions
owner	Everything.
admin	Everything except org.manage.
manager	Members (read, manage), tasks (use, read all), signature, registered mail and contacts (all levels).
member	members.read, tasks.use, signature.read / send, registered_mail.read / send, contacts.read / write.
viewer	members.read, tasks.use, signature.read, registered_mail.read, contacts.read.

An API key has exactly the permissions of its role, at its node. To check them at runtime, call GET /v1/me and read scopes[].permissions.

Features

On top of permissions, each feature (signature, registered_mail, tasks) must be enabled for the entity. When it is not, calls answer 403 feature_disabled. GET /v1/me lists the enabled features per scope (scopes[].features).

Partner scopes

Partner applications are declared with scopes. On an organization that approved the application, the scopes are the maximum; the effective permissions depend on the credentials:

• machine credentials (client_credentials): provisioning and administration scopes (orgs:write, nodes:write, members:write) only, intersected with the role of the grant (chosen by the administrator on the consent page, or the organization role given at provisioning);
• delegated tokens (delegated OAuth): business scopes only (signature, registered_mail, contacts, tasks), those the person authorized, intersected with the permissions of the person.

Scope	Permissions it allows
orgs:write	org.manage
nodes:write	nodes.manage
members:write	members.read members.manage
signature:read	signature.read
signature:write	signature.read signature.send signature.manage
tasks:read	tasks.use
tasks:write	tasks.use tasks.read_all
contacts:read	contacts.read
contacts:write	contacts.read contacts.write contacts.manage
registered_mail:read	registered_mail.read
registered_mail:write	registered_mail.read registered_mail.send registered_mail.manage

• orgs:write is a provider-level scope: it cannot be requested on the consent page.
• Provisioning endpoints require their scope explicitly (403 insufficient_scope).

Note

OAuth scopes in the token request are unrelated to partner scopes: the token request only carries openid (plus offline_access for delegated tokens) and the API audience scope. Partner scopes are configured on the application by MyCLM and consented by the organizations and people; they never travel in the token.