Commvault User Management API Guide

Auth method: Token-based authentication (Commvault QSDK token via Login endpoint); also supports username/password exchange for token. OAuth 2.0 is not explicitly named in official docs.

Setup steps

1. POST to /Login with JSON body containing username and password to receive an authtoken.
2. Include the returned authtoken value in the Authtoken request header for all subsequent API calls.
3. Tokens expire after a configurable idle timeout (default 30 minutes); re-authenticate to obtain a new token.
4. For SCIM provisioning, generate a dedicated SCIM token from the Commvault Command Center under Identity Providers > SCIM.

Required scopes

Authenticate / Get Token

• Method: POST
• URL: https://<host>/webconsole/api/Login
• Watch out for: Token is returned as 'token' in v4 API and 'authtoken' in older versions. Use the Authtoken header (not Authorization: Bearer) for subsequent calls.

Request example

POST /webconsole/api/Login
Content-Type: application/json
{
  "username": "admin",
  "password": "secret"
}

Response example

{
  "token": "QSDK <token_string>",
  "userName": "admin",
  "userId": 1
}

List Users

• Method: GET
• URL: https://<host>/webconsole/api/User
• Watch out for: Returns all users visible to the authenticated account's role. Tenant admins only see users within their company.

Request example

GET /webconsole/api/User
Authtoken: QSDK <token>

Response example

{
  "users": [
    {"userEntity": {"userId": 5, "userName": "jdoe"},
     "email": "jdoe@example.com",
     "enableUser": true}
  ]
}

Get User by ID

• Method: GET
• URL: https://<host>/webconsole/api/User/{userId}
• Watch out for: Response wraps single user in a 'users' array, not a single object.

Request example

GET /webconsole/api/User/5
Authtoken: QSDK <token>

Response example

{
  "users": [
    {"userEntity": {"userId": 5, "userName": "jdoe"},
     "email": "jdoe@example.com",
     "fullName": "Jane Doe",
     "enableUser": true}
  ]
}

Create User

• Method: POST
• URL: https://<host>/webconsole/api/User
• Watch out for: Request body must wrap user(s) in a 'users' array. errorCode 0 indicates success.

Request example

POST /webconsole/api/User
Authtoken: QSDK <token>
Content-Type: application/json
{
  "users": [{
    "userEntity": {"userName": "newuser"},
    "email": "newuser@example.com",
    "password": "P@ssw0rd!"
  }]
}

Response example

{
  "response": [
    {"errorCode": 0,
     "entity": {"userId": 42, "userName": "newuser"}}
  ]
}

Update User

• Method: PUT
• URL: https://<host>/webconsole/api/User/{userId}
• Watch out for: Full PUT semantics; omitting optional fields may reset them. Confirm field behavior in your Commvault version.

Request example

PUT /webconsole/api/User/42
Authtoken: QSDK <token>
Content-Type: application/json
{
  "users": [{
    "userEntity": {"userId": 42},
    "email": "updated@example.com",
    "enableUser": true
  }]
}

Response example

{
  "response": [
    {"errorCode": 0,
     "entity": {"userId": 42}}
  ]
}

Delete User

• Method: DELETE
• URL: https://<host>/webconsole/api/User/{userId}
• Watch out for: Deleting a user is irreversible. Ensure data ownership is transferred before deletion.

Request example

DELETE /webconsole/api/User/42
Authtoken: QSDK <token>

Response example

{
  "response": [
    {"errorCode": 0,
     "entity": {"userId": 42}}
  ]
}

List User Groups

• Method: GET
• URL: https://<host>/webconsole/api/UserGroup
• Watch out for: External (AD/LDAP) groups appear alongside local groups; check 'localUserGroup' flag to distinguish.

Request example

GET /webconsole/api/UserGroup
Authtoken: QSDK <token>

Response example

{
  "userGroups": [
    {"userGroupEntity": {"userGroupId": 3, "userGroupName": "BackupAdmins"}}
  ]
}

Logout / Invalidate Token

• Method: POST
• URL: https://<host>/webconsole/api/Logout
• Watch out for: Always call Logout to invalidate tokens in automated workflows to avoid session exhaustion on the CommServe.

Request example

POST /webconsole/api/Logout
Authtoken: QSDK <token>

Response example

{
  "errorCode": 0,
  "errorMessage": ""
}

• Rate limits: Commvault official documentation does not explicitly publish rate limit thresholds or tier-based limits for the REST API.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No rate limit headers or Retry-After behavior documented officially. Practical limits are governed by the CommServe server capacity and concurrent session settings configurable by the administrator.

• Pagination method: offset

• Default page size: 0

• Max page size: 0

• Pagination pointer: start / limit query parameters used on some list endpoints (e.g., GET /User?start=0&limit=100); not uniformly documented across all endpoints.

• Webhooks available: No

• Webhook notes: Commvault does not expose a native outbound webhook system for user lifecycle events in its official REST API documentation.

• Alternative event strategy: Use Commvault's Workflow engine or scheduled reports to poll for user changes. Third-party SIEM/SOAR integrations can consume Commvault alerts via its alert notification framework.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (Cyber Recovery tier, custom pricing from ~$25K/year per context data)

• Endpoint: https:///webconsole/api/scim/v2

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PUT /Users/{id}, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, GET /Groups/{id}, POST /Groups, PUT /Groups/{id}, PATCH /Groups/{id}, DELETE /Groups/{id}

Limitations:

• SCIM token must be generated from Commvault Command Center; it is separate from the standard API authtoken.
• SCIM provisioning requires the Enterprise plan tier.
• Supported IdP connectors and attribute mappings depend on the identity provider configuration in Command Center.
• Not all SCIM schema extensions are supported; custom attributes may not map to Commvault user fields.
• Official documentation does not enumerate all unsupported SCIM filter operators.

Three core automation scenarios cover most integration needs:

• Provision a local user and assign to a group: POST /Login → GET /UserGroup to resolve the target userGroupId → POST /User with the users array wrapper including userName, email, password, and userGroups. Confirm errorCode: 0 and capture the returned userId. If inviteUser is true, verify SMTP is configured on the CommServe or the invitation will silently fail.

• Disable a user without deleting: POST /Login → GET /User to resolve userId by userName → PUT /User/{userId} with enableUser: false. PUT uses full-object semantics - omitting optional fields may reset them depending on Commvault version. Test in a non-production environment before running at scale.

• SCIM sync from an identity provider: Generate a SCIM bearer token in Command Center → Identity Providers → SCIM. Configure the IdP (e.g., Okta, Azure AD) with the SCIM base URL and token. The IdP calls POST /scim/v2/Users for new accounts and PATCH /scim/v2/Users/{id} for updates. Monitor provisioning logs in both the IdP and Command Center. The SCIM token does not expire by default but should be rotated periodically; ensure the Commvault host is network-reachable from the IdP's provisioning service.

Provision a new local user and assign to a group

1. POST /Login with admin credentials to obtain authtoken.
2. GET /UserGroup to retrieve the target userGroupId.
3. POST /User with userName, email, password, and userGroups array containing the target userGroupId.
4. Verify response errorCode is 0 and capture the returned userId.
5. Optionally POST /Logout to invalidate the session token.

Watch out for: Wrap the user object in a 'users' array in the POST body. If inviteUser is true, ensure the CommServe SMTP settings are configured or the invitation email will silently fail.

Disable (deactivate) a user account without deleting

1. POST /Login to obtain authtoken.
2. GET /User to find the target userId by userName.
3. PUT /User/{userId} with enableUser set to false in the request body.
4. Confirm response errorCode is 0.
5. POST /Logout.

Watch out for: PUT requires the full user object context; partial updates may reset unspecified fields depending on Commvault version. Test in a non-production environment first.

Sync users via SCIM from an identity provider

1. Log in to Commvault Command Center as an administrator.
2. Navigate to Identity Providers > SCIM and generate a SCIM bearer token.
3. Configure the IdP (e.g., Azure AD, Okta) with the SCIM base URL: https:///webconsole/api/scim/v2 and the generated bearer token.
4. Map IdP user attributes to Commvault SCIM schema fields (userName, emails, displayName, active).
5. Enable provisioning in the IdP; the IdP will call POST /scim/v2/Users for new users and PATCH /scim/v2/Users/{id} for updates.
6. Monitor provisioning logs in both the IdP and Commvault Command Center for errors.

Watch out for: The SCIM endpoint and token are only available on the Enterprise plan. The SCIM token does not expire by default but should be rotated periodically. Ensure the Commvault host is network-accessible from the IdP's provisioning service.

Several non-obvious behaviors create integration risk. The Authtoken header value must include the QSDK prefix (with trailing space) exactly as returned by /Login - deviating from this format will produce auth failures that are not always clearly surfaced. DELETE /User/{userId} is permanent with no soft-delete or recycle bin;

verify data ownership transfer before executing any delete call in an automated pipeline.

Multi-tenant deployments require the authenticated API user to have the correct company scope; cross-company user management requires Master Admin credentials. Tenant admins calling GET /User will only see users within their own company, which can produce incomplete results if your identity graph aggregation logic assumes a global user list.

Rate limits are not published and are governed by CommServe server capacity and concurrent session settings - there are no rate-limit headers or Retry-After responses to handle backpressure programmatically.

Pagination is inconsistent: some list endpoints accept start and limit query parameters (e.g., GET /User?start=0&limit=100), but this behavior is not uniformly documented across all endpoints. SSL certificate validation must be explicitly configured for on-premises deployments where self-signed certificates are common, or API clients will fail at the TLS handshake before any auth attempt.