Permission Roles
This document contains endpoints for creating, retrieving, updating, deleting, and assigning permission roles in DocStudio.
Permission roles combine multiple account or mailbox permissions into reusable access configurations. Instead of granting every permission separately, an organization can create roles for specific responsibilities and assign those roles to users.
A system role is predefined by DocStudio and can be reused but not created through the API. A custom role belongs to a specific account and contains a user-defined name and permission set.
Business goals
Permission Role endpoints support the following business goals:
Standardize user access. Create reusable permission sets for users with the same responsibilities.
Separate account and mailbox access. Define roles that apply either to account-level administration or to work within a specific mailbox.
Simplify permission management. Assign a role instead of granting the same permissions separately to multiple users.
Retrieve available access configurations. Find system and custom roles before assigning access to a user.
Maintain custom roles. Create, retrieve, update, or delete roles as organizational responsibilities change.
Endpoint summary
Role lifecycle
GET
/api/v1/permission/role/{uuid}
Retrieve a role by UUID
POST
/api/v1/permission/role
Create a custom role
PUT
/api/v1/permission/role/{uuid}
Change the role name and permissions
DELETE
/api/v1/permission/role/{uuid}
Delete a custom role
Role discovery
GET
/api/v1/permission/role
Retrieve the predefined system roles
GET
/api/v1/permission/role/account/{uuid}
Retrieve system and custom roles available to an account
Role structure and headers
Role operations require an API token in the Authorization header. Requests that create or update a role must also use Content-Type: application/json.
A role contains the following properties:
uuid
UUID
Unique identifier of the role returned by DocStudio
name
string
Role name displayed to account administrators
description
string
Explanation of the responsibilities associated with the role
type
string
Role context: account or mailbox
permissions
array of integers
Numeric identifiers of the permissions included in the role
accountUuid
UUID
Account that owns the custom role
system
boolean
Indicates whether the role is predefined by DocStudio
An
accountrole contains permissions that apply to account-level administration.A
mailboxrole contains permissions for working within a mailbox, so its type must correspond to the context in which the role will be assigned.
Retrieve available roles and permission IDs
Retrieve the predefined system roles before creating a custom role. The response contains each role’s type and the numeric permission IDs included in its permissions array.
Supported query parameters:
type
string
No
Filters roles by account or mailbox type
name
string
No
Filters roles by name
permissions
array of integers
No
Filters roles by included permission IDs
offset
integer
No
Number of roles to skip; the default value is 0
limit
integer
No
Maximum number of roles to return; the default value is 25
The response is a paginated collection of roles. Use the returned permissions arrays to select the permission IDs required for a new custom role.
The 0 permission ID is the generic value used by the Swagger schema. Actual responses contain the numeric permission IDs assigned to the returned roles.
Practical example: Create and assign a mailbox role
A company wants employees responsible for reviewing contracts to receive the same mailbox permissions. The integration retrieves the available roles, selects the required permission IDs, creates a reusable Contract Reviewer role, and assigns it to a user.
Retrieve existing mailbox roles
Retrieve the roles available to the account and filter the results by the mailbox type. Use their permissions arrays to identify the permissions required by the new role.
Create the custom role
Send the selected numeric permission IDs in the permissions array. The role type is mailbox because it will be assigned within a mailbox.
Replace 0 with an actual permission ID returned by the role discovery endpoints. Include every permission that users assigned to this role must receive.
A successful request returns 201 Created and the created role object. Save the returned uuid because it identifies the role in subsequent read, update, delete, and assignment operations.
Retrieve the created role
Use the returned roleUuid to verify the stored role configuration. The response contains the current name, description, type, permissions, account UUID, system-role indicator, and role UUID.
Assign the role to a user
Use the mailbox permission endpoint to assign the created role to a user. Send its UUID in the roles array and leave permissions empty when no individual permissions need to be added.
The PATCH request adds the role without removing the user’s existing mailbox permissions or roles. If the custom role has the account type, assign it through the corresponding account permission endpoint.
Use PUT instead of PATCH only when the complete set of permissions and roles must be replaced. A PUT request overwrites the user’s existing assignments in the selected account or mailbox context.
Practical example: Update an existing custom role
An organization has expanded the responsibilities of its Contract Reviewer role. The integration retrieves the role, updates its name and permission set, and then retrieves it again to confirm the resulting configuration.
Retrieve the current role
Retrieve the role before preparing the update. Preserve the required role properties and identify the permission IDs that must be added or removed.
Update the role
Send the complete updated role object and replace the generic permission values with the required numeric IDs. The endpoint allows the role name and permission set to be changed.
A successful request returns 200 OK and the updated role object. Retrieve the role again if the integration needs to verify its final configuration before assigning it to additional users.
Delete a custom role
Delete a custom role when it is no longer required. Use the role UUID returned when the role was created or retrieved.
A successful request returns 204 No Content without a response body. Remove or replace the role in existing user permission configurations when necessary.
Related topics
Last updated
Was this helpful?
