For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Method
Endpoint
Purpose

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

Method
Endpoint
Purpose

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:

Property
Type
Description

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 account role contains permissions that apply to account-level administration.

  • A mailbox role 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:

Parameter
Type
Required
Description

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.

Last updated

Was this helpful?