Assign roles
Last updated: Apr-20-2026
This guide describes the Roles and Permissions system. For details on all roles available in the legacy system, see Role-based permissions.
- Enterprise accounts: Broad Enterprise migration hasn't started yet. If your team hasn't already been moved with Cloudinary's help, you're still on the legacy system.
- Existing free and paid accounts: Migration starts May 12, 2026.
- New free accounts (created since February 2026): You may already have the new system.
You can confirm which permissions system you have. Open Console Settings and look for Role Management. If it's listed, your account is on Roles and Permissions. If it isn't listed, you're still on the legacy permissions model.
The Roles and Permissions system provides more granular, flexible access control than the legacy system.- For a quick comparison, see Roles and Permissions vs. legacy.
- If your account is being migrated, see Migrating to Roles and Permissions to understand what changes.
Overview
You can assign all roles defined in your account to principals, including users, groups, and API keys.
-
Use the Permissions API to assign global, folder, and collection roles.
For Free plan customers:The Permissions API isn't available on the Free plan. You can manage roles and permissions via the Console only and assign folder roles to API keys and other principals programmatically via the Admin API. Use the Admin API to assign folder roles.
Assign roles via the Permissions API
Enterprise customers can use their account management keys to manage and assign all roles via the Permissions API.
Base URL and authentication
All Permissions API endpoints on this page use the following base path:
Replace ACCOUNT_ID with your actual account ID.
Find your account ID and credentials in the Account Management Keys page of the Console Settings.
Method 1: Assign a role to multiple principals
Use this method when you want to assign the same role to multiple principals.
Endpoint:
PUT /permissions/roles/{role_id}/principals
The request body should include:
- An
operationfield (at the top level) that defines whether to add or remove the listed principals. - A
principalsarray containing one or more principal assignment objects.
| Field | Applies To | Description |
|---|---|---|
operation |
Top-level | Whether to add or remove the listed principals from the role. Values: add, remove
|
| Principal object fields: | (Each object in the principals array must include the following fields.) |
|
principal_type |
Each role assignment | Type of principal. Values: user, group, apiKey, provisioningKey
|
principal_id |
Each role assignment | Unique ID of the user, group, or key receiving the role. |
scope_id |
Each role assignment (if scoped to a product environment) | The product environment ID. Find this on the Product Environments page. |
policy_parameters |
Each role assignment (if the role applies to a specific folder or collection) | ID of the folder or collection the permission applies to. |
Example 1: Assign principals to an account role
Example 2: Assign a global role across different product environments
Example 3: Assign a content role to different folders
Example 4: Remove a principal from a role
Method 2: Assign roles to a principal
Use this method to assign multiple roles of different permission types and scopes (account, product environment, global, and content) to a single principal:
PUT /permissions/principal_roles
The request body should include:
- An
operationfield (at the top level) that defines whether to add or remove the roles from the specified principal. - A
principalobject specifying the principal to assign roles to. - A
rolesarray containing one or more role assignment objects. Each object may optionally includescope_idand/orpolicy_parameters, depending on the role.
| Field | Applies To | Description |
|---|---|---|
operation |
Top-level | Whether to add or remove the listed roles from the principal. Values: add, remove
|
| Principal object fields: | (The principal object must include the following fields.) |
|
principal_type |
The principal | Type of principal. Values: user, group, apiKey, provisioningKey
|
principal_id |
The principal | Unique ID of the user, group, or key receiving the role. |
| Role object fields: | (Each object in the roles array must include the following fields.) |
|
id |
Each role | ID of the role to apply to the principal. |
scope_id |
Each role assignment (if scoped to a product environment) | The product environment ID. Find this on the Product Environments page. |
policy_parameters |
Each role assignment (if the role applies to a specific folder or collection) | ID of the folder or collection the permission applies to. |
Example: Assign multiple roles of different types to a principal
Inspecting role assignments
Use these endpoints to view current role assignments and permissions:
| Endpoint | Use Case |
|---|---|
| GET /roles/{role_id}/principals | See who has a specific role. |
| GET /principal_roles | See what roles a user or key has. |
| GET /principal_roles/inspect | View effective permissions for a user or key (debug access issues). |
View effective permissions
Use the GET /principal_roles/inspect endpoint to check which roles or permission policies apply to a user, group, or key, based on specific content, product environments, or scopes.
This endpoint is especially useful for debugging access issues, such as:
Why a user can or can't access a folder or collection
Whether a key has permission to perform an action in a specific product environment
Confirming inherited or global role assignments
You can filter by:
Principal:
principal_typeandprincipal_idScope:
scope_type(accountorprodenv), andscope_idif neededContent instance:
folder_id,collection_id, orasset_id
To inspect broad access, you can also use special values like folder_id=all.
Assign folder roles via the Admin API
You can use the Admin API to assign folder roles to users, groups, and API keys. This provides an alternative method for folder role assignment alongside the Permissions API.
folder_operations/invite endpoint is available for assigning folder roles to API keys and other principals. However, Free plan customers don't have access to the full Permissions API for managing and assigning other role types.
For additional role management options on the Free plan, see:
Base URL and authentication
You can assign roles to users, groups, and product environment API keys to grant permissions for specific folder instances via the Admin API.
By default, the Admin API endpoints use the following format:
https://api.cloudinary.com/v1_1/:cloud_name/:action
For example, to list all video assets in the cld-docs product environment:
The API uses Basic Authentication over secure HTTP. Your Cloudinary API Key and API Secret (which can be found on the API Keys page of your Cloudinary Console Settings) are used for the authentication.
You can experiment with returning a list of the images in your own Cloudinary product environment by replacing the API_KEY, API_SECRET, and CLOUD_NAME in the cURL command below:
folder_operations/invite
Enables you to grant or remove roles for a specific folder to a principal (user, group, or API key).
| Method | Description |
|---|---|
GET/folder_operations/invite/:folder_external_id
|
Lists the principals and roles assigned to a folder. |
POST/folder_operations/invite/:folder_external_id
|
Assigns or removes roles for a folder to a principal. |
Get folder roles
Lists the principals and their roles assigned to a specific folder.
Syntax
GET /folder_operations/invite/:folder_external_id
Required parameters
| Parameter | Type | Description |
|---|---|---|
| folder_external_id | String | The immutable identifier (external_id) of the folder, returned by Get root folders or Get subfolders. |
Example
Get the roles assigned to a specific folder:
Sample response
Assign folder roles
Assigns or removes roles for a specific folder to a principal (user, group, or API key).
The operation supports system folder roles such as cld::role::content::folder::editor. For a full list of system folder roles, see Folder roles.
Enterprise customers can also create and assign custom roles via this endpoint using the custom role's ID. To learn more about custom roles, see Manage roles via API.
Syntax
POST /folder_operations/invite/:folder_external_id
Required parameters
| Parameter | Type | Description |
|---|---|---|
| folder_external_id | String | The immutable identifier (external_id) of the folder, returned by Get root folders or Get subfolders. |
| principal_type | String | The principal type. Possible values: user, group, or apiKey
|
| principal_id | String | The ID of the principal. For type apiKey, use the key string itself. |
| operation | String | The operation to perform: add to grant roles, remove to revoke them. |
| roles | Array[String] | The IDs of the roles to assign or revoke. Example: cld::role::content::folder::editor
|
Examples
Assign the folder manager role to an API key:
Assign the folder editor role to a user:
Sample response
- Role-based permissions: An overview of Cloudinary's role-based permissions solution
- Role management in the Console: UI-based role management
- Manage roles: How to manage roles via API
- System role and policy reference: A list of all system roles and system permission polices provided by Cloudinary
- Permissions API reference: Full list of endpoints and schemas
- Define custom policies: Create and apply policies outside of roles
