iManage User Management API Guide

Auth method: OAuth 2.0 (authorization code flow and client credentials flow supported via iManage Control Center)

Setup steps

1. Register an application in iManage Control Center under Security > Applications.
2. Obtain a client_id and client_secret for the registered application.
3. For user-delegated access, use the authorization code flow: redirect user to /auth/oauth2/authorize with response_type=code and required scopes.
4. Exchange the authorization code for an access token at /auth/oauth2/token.
5. For server-to-server access, use the client credentials flow: POST to /auth/oauth2/token with grant_type=client_credentials, client_id, and client_secret.
6. Include the returned Bearer token in the Authorization header for all API requests.

Required scopes

List Users

• Method: GET
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/users
• Watch out for: The customer_id path segment corresponds to the iManage library/database identifier, not a global tenant ID.

Request example

GET /api/v1/customers/acme/users?max_results=50&start_index=0
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id": "usr_001", "login_name": "jdoe", "email": "jdoe@acme.com", "active": true}
  ],
  "total_results": 120
}

Get User

• Method: GET
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/users/{user_id}
• Watch out for: User IDs are scoped to a specific customer/database context; the same person may have different IDs across databases.

Request example

GET /api/v1/customers/acme/users/usr_001
Authorization: Bearer {access_token}

Response example

{
  "data": {
    "id": "usr_001",
    "login_name": "jdoe",
    "email": "jdoe@acme.com",
    "first_name": "John",
    "last_name": "Doe",
    "active": true
  }
}

Create User

• Method: POST
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/users
• Watch out for: Requires admin scope. User is created within the specified customer/database only.

Request example

POST /api/v1/customers/acme/users
Authorization: Bearer {access_token}
Content-Type: application/json

{"login_name":"jsmith","email":"jsmith@acme.com","first_name":"Jane","last_name":"Smith"}

Response example

{
  "data": {
    "id": "usr_002",
    "login_name": "jsmith",
    "email": "jsmith@acme.com",
    "active": true
  }
}

Update User

• Method: PATCH
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/users/{user_id}
• Watch out for: Partial updates are supported via PATCH; only supplied fields are modified.

Request example

PATCH /api/v1/customers/acme/users/usr_002
Authorization: Bearer {access_token}
Content-Type: application/json

{"active": false, "title": "Senior Associate"}

Response example

{
  "data": {
    "id": "usr_002",
    "active": false,
    "title": "Senior Associate"
  }
}

Delete User

• Method: DELETE
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/users/{user_id}
• Watch out for: Deletion is permanent. Consider setting active=false to deactivate without data loss.

Request example

DELETE /api/v1/customers/acme/users/usr_002
Authorization: Bearer {access_token}

Response example

HTTP 204 No Content

List Groups

• Method: GET
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/groups
• Watch out for: Groups control document-level access in iManage; group membership changes take effect immediately.

Request example

GET /api/v1/customers/acme/groups
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id": "grp_001", "name": "Litigation", "member_count": 12}
  ]
}

Add User to Group

• Method: POST
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/groups/{group_id}/members
• Watch out for: Adding a user to a group grants them access to all workspaces and folders shared with that group.

Request example

POST /api/v1/customers/acme/groups/grp_001/members
Authorization: Bearer {access_token}
Content-Type: application/json

{"user_id": "usr_001"}

Response example

HTTP 201 Created
{
  "data": {"group_id": "grp_001", "user_id": "usr_001"}
}

Remove User from Group

• Method: DELETE
• URL: https://{tenant}.imanage.work/api/v1/customers/{customer_id}/groups/{group_id}/members/{user_id}
• Watch out for: Removing a user from a group immediately revokes their access to group-shared content.

Request example

DELETE /api/v1/customers/acme/groups/grp_001/members/usr_001
Authorization: Bearer {access_token}

Response example

HTTP 204 No Content

• Rate limits: iManage does not publicly document specific rate limit thresholds in available developer documentation.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No explicit rate limit values, headers, or retry behavior documented in publicly available official sources. Contact iManage support for deployment-specific limits.

• Pagination method: offset

• Default page size: 100

• Max page size: 1000

• Pagination pointer: start_index and max_results (query parameters)

• Webhooks available: No

• Webhook notes: iManage Work does not publicly document a native webhook system for user management events in available official documentation.

• Alternative event strategy: iManage offers an event-driven integration via iManage Share and iManage Cloud platform events; polling the user list endpoint is the documented approach for sync scenarios.

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• No native SCIM 2.0 endpoint is documented in official iManage developer documentation.
• User provisioning from IdPs (Okta, Entra ID) is typically handled via iManage Control Center SSO configuration, not SCIM.
• Third-party middleware or custom connectors may be required for automated SCIM-style provisioning.

Three core automation scenarios are supported by the API.

To provision a new employee, obtain an admin-scoped token via client credentials, POST to /api/v1/customers/{customer_id}/users with login_name, email, first_name, and last_name, capture the returned id, then POST to /groups/{group_id}/members to assign group membership.

For firms with multiple databases, this sequence must be repeated for each relevant customer_id.

To deactivate a departing employee, resolve the user's id via GET with a login_name filter, then PATCH with {"active": false}.

Prefer deactivation over DELETE - the DELETE endpoint is permanent and eliminates audit trail and document ownership history.

Follow up with explicit DELETE calls to remove the user from each group, as deactivation does not cascade to group membership records.

For directory sync, retrieve current group membership via GET on each group's members endpoint, diff against the authoritative source, then POST additions and DELETE removals one user at a time.

There is no bulk membership update endpoint;

every change is a discrete API call.

Provision a new employee and assign to a practice group

1. Obtain an admin-scoped access token via client credentials flow from /auth/oauth2/token.
2. POST to /api/v1/customers/{customer_id}/users with login_name, email, first_name, last_name.
3. Capture the returned user id from the response.
4. POST to /api/v1/customers/{customer_id}/groups/{group_id}/members with the new user_id to assign group membership.

Watch out for: If the firm uses multiple iManage databases (e.g., separate libraries per office), repeat the provisioning steps for each relevant customer_id.

Deactivate a departing employee

1. GET /api/v1/customers/{customer_id}/users?login_name={login_name} to resolve the user's id.
2. PATCH /api/v1/customers/{customer_id}/users/{user_id} with {"active": false} to disable the account.
3. Optionally, DELETE the user from all groups via DELETE /api/v1/customers/{customer_id}/groups/{group_id}/members/{user_id} for each group.

Watch out for: Prefer deactivation (active=false) over deletion to preserve audit trails and document ownership history.

Sync group membership from an external directory

1. GET /api/v1/customers/{customer_id}/groups to retrieve all iManage groups.
2. For each group, GET /api/v1/customers/{customer_id}/groups/{group_id}/members to retrieve current membership.
3. Compare against the authoritative directory source.
4. POST new members to /groups/{group_id}/members and DELETE removed members from /groups/{group_id}/members/{user_id} as needed.

Watch out for: There is no bulk membership update endpoint; additions and removals must be made one user at a time per group.

The multi-database scoping model is the most common integration trap: building an identity graph against iManage requires resolving the same person across multiple customer_id contexts, each returning a different user_id. Any pipeline that assumes a single canonical user identifier will produce incomplete or duplicated identity records.

The login_name field is the most reliable cross-database correlation key, but it must be queried per database - there is no global user lookup endpoint.

iManage does not expose a native SCIM 2.0 endpoint; IdP-driven provisioning (Okta, Entra ID) relies on Control Center SSO configuration, not a standards-based SCIM connector. Webhooks for user management events are also undocumented, so sync pipelines must poll the user list endpoint on a schedule.

API versioning is tied to the server version (e.g., 10.3, 10.4), meaning endpoint availability and field names may differ between iManage Cloud and on-premises deployments - confirm the correct base URL and API version with the iManage administrator before building against any endpoint.