Skip to navigation

How to create a new active user for CLM and eSignature

View as Markdown

This topic demonstrates how to use the Docusign Admin API to create a new CLM and eSignature user and activate their account automatically. Auto-activating a user’s account membership bypasses the activation email and password setup process, which is particularly useful for integrations and customers using single sign-on (SSO).

The auto-activate option is only available for users with an email address domain that has been claimed by your organization.

Run this code example from our Quickstart or launcher projects: Bash, C#, Java, Node.js, PHP, PowerShell, Python, or Ruby.

Required data

Running the code in this how-to requires this data:

Data elementDescription
Admin accessThe caller must be at least one of the following:
  • A full organization administrator
  • A delegated organization administrator
See Organization Administrators for details on Docusign Admin roles.
{API_ACCOUNT_ID}A GUID value that identifies your account. This value is automatically generated by Docusign for any account you create. Copy the value from the API Account ID field on the Apps and Keys page.
{BASE_PATH}A string value that forms the root of the URL required to make API calls. The base path value in the example code is set to target the developer environment at
https://<domain>/management
Where <domain> is api-d.docusign.net for the developer environment and api.docusign.net for production.
CLM enabled accountThe account used to call the API must have CLM enabled for their account. See Support for Docusign CLM for more information.
{CLM_PERMISSION_PROFILE}A string value that identifies your CLM permission profile. This value is automatically generated by Docusign for any permission profile you create.
{GROUP_ID}A string value that identifies a given user group. This value is automatically generated by Docusign for any user group you create.
{ORGANIZATION_ID}A GUID value that identifies the the organization that contains the account to which the user will be added. Copy the value from the Organization ID field in the Organization section of the Account Profile page.
{PERMISSION_PROFILE_ID}A string value that identifies your permission profile. This value is automatically generated by Docusign for any permission profile you create.

Step 1. Obtain your OAuth token

To make the API calls shown in this how-to, you need a valid OAuth access token. Docusign supports access tokens for three different recommended OAuth grant types: Public Authorization Code Grant, Confidential Authorization Code Grant, and JSON Web Token (JWT) Grant. Choose the OAuth grant type appropriate for your scenario.

Docusign Admin OAuth access tokens are the same ones used for our eSignature REST API, although you must request one or more Docusign Admin scopes to call the Docusign Admin API. The endpoint calls made in this how-to require that you request the Docusign Admin-specific user_write scope when obtaining your access token.

See Docusign Admin Authentication for details and the full list of Docusign Admin scopes.

Three icons that represent the three methods a user can use to obtain an OAuth token: JSON Web Token (JWT), Public Authorization Code Grant (ACG), and Confidential Authorization Code grant

Step 2. Construct your API headers

After you have a valid OAuth access token, you are ready to construct the API headers that you will pass to the API call. Construct your headers like this, but make sure to substitute your valid OAuth access token for {ACCESS_TOKEN}.

declare -a Headers=('--header' "Authorization: Bearer ${ACCESS_TOKEN}" \
'--header' "Accept: application/json" \
'--header' "Content-Type: application/json")

Step 3. Retrieve CLM and eSignature permission profiles

Make a GET request to obtain a single list containing the eSignature product ID and permission profile IDs and the CLM product ID and permission profile IDs. Here’s how you make the call, but make sure to substitute your base path for {BASE_PATH}, your API account ID for {API_ACCOUNT_ID}, and your organization ID for {ORGANIZATION_ID}. Select one of the returned eSignature permission profile IDs and one of the returned CLM permission profile IDs.

Status=$(curl -w '%{http_code}' -i --request GET ${base_path}/v2.1/organizations/${ORGANIZATION_ID}/accounts/${API_ACCOUNT_ID}/products/permission_profiles \
"${Headers[@]}" \
--output ${response})

Step 4. Select a Docusign Admin group ID

To find the Docusign Admin group to which you want to assign the user, you need to make a GET request to obtain a list of all available Docusign Admin group IDs. Select a group ID to continue through the example. Here’s how you make the call, but make sure to substitute your base path for {BASE_PATH}, your API account ID for {API_ACCOUNT_ID}, and your organization ID for {ORGANIZATION_ID}.

Status=$(curl -w '%{http_code}' -i --request GET ${base_path}/v2.1/organizations/${ORGANIZATION_ID}/accounts/${API_ACCOUNT_ID}/dsgroups \
"${Headers[@]}" \
--output ${response})

Step 5. Construct the request body

Next, construct the request body. This contains the details of the user account to be created and an optional parameter, auto_activate_memberships, that automatically enables the account if set to true. You must also include the Docusign Admin group ID and permission profile information obtained previously.

Your organization’s domain must have the Require all users to authenticate with Identity Provider option enabled to use the auto_activate_memberships parameter.

printf \
'
{
"user_name": "'${USER_NAME}'",
"first_name": "'${FIRST_NAME}'",
"last_name": "'${LAST_NAME}'",
"email": "'${EMAIL}'",
"auto_activate_memberships": true,
"product_permission_profiles": [
{
"permission_profile_id": '$ESIGN_PERMISSION_PROFILE_ID',
"product_id": '$ESIGN_PRODUCT_ID'
},
{
"permission_profile_id": '$CLM_PERMISSION_PROFILE_ID',
"product_id": '$CLM_PRODUCT_ID'
}
],
"ds_groups": [
{
"ds_group_id": "'$DS_GROUP_ID'"
}
]
}' >$request_data

Step 6. Call the Docusign Admin API

Now that you have constructed your API headers and request body, make a POST request to the MultiProductUserManagement: addOrUpdateUser endpoint and include the request body to create the user for your organization. Here’s how you make the call, but make sure to substitute your base path for {BASE_PATH}, your API account ID for {API_ACCOUNT_ID}, and your organization ID for {ORGANIZATION_ID}.

View the source code for this how-to on GitHub: Bash, C#, Java, Node.js, PHP, PowerShell, Python, Ruby.

Status=$(
curl -w '%{http_code}' -i --request POST ${base_path}/v2.1/organizations/${ORGANIZATION_ID}/accounts/${API_ACCOUNT_ID}/users/ \
"${Headers[@]}" \
--data-binary @${request_data} \
--output ${response}
)

Expected response

If you run this code example from our Quickstart or launcher projects, you should see a JSON response similar to the code shown.

Sample response
{
"id": "1e4204d5-xxxx-xxxx-xxxx-730a1d33fcea",
"site_id": x,
"user_name": "User Name",
"first_name": "User",
"last_name": "Name",
"email": "1007a@example.com",
"language_culture": "en",
"accounts": [
{
"id": "62f3f76b-xxxx-xxxx-xxxx-315e96a0d720",
"site_id": x,
"product_permission_profiles": [
{
"product_id": "f6406c68-xxxx-xxxx-xxxx-64152a26fa83",
"product_name": "ESign",
"permission_profiles": [
{
"permission_profile_id": "11xxxx73",
"permission_profile_name": "Account Administrator"
}
]
},
{
"product_id": "37f013eb-xxxx-xxxx-xxxx-357b39fdbd00",
"product_name": "CLM",
"permission_profiles": [
{
"permission_profile_id": "x",
"permission_profile_name": "CLM Admin"
}
]
}
],
"ds_groups": [
{
"ds_group_id": "917b47ad-xxxx-xxxx-xxxx-2d3b68703788",
"group_name": "Example Group",
"user_count": 0
}
]
}
]
}

Next steps