Atlan User Management API Guide

Auth method: API Token (Bearer token) - generated per-user or service account in Atlan's admin console; passed as Authorization: Bearer

Setup steps

1. Log in to your Atlan tenant as an admin.
2. Navigate to Settings → API Tokens.
3. Click 'Generate API Token', assign a name and optional expiry.
4. Copy the generated token; it is shown only once.
5. Include the token in all API requests as the HTTP header: Authorization: Bearer .

Required scopes

List Users

• Method: GET
• URL: https://{tenant}.atlan.com/api/service/users
• Watch out for: Pagination uses limit/offset; totalRecord indicates total users for iteration.

Request example

GET /api/service/users?limit=20&offset=0
Authorization: Bearer <token>

Response example

{
  "records": [
    {"id":"uuid","username":"jdoe","email":"jdoe@example.com","enabled":true}
  ],
  "count": 1,
  "totalRecord": 50
}

Get User by ID

• Method: GET
• URL: https://{tenant}.atlan.com/api/service/users/{userId}
• Watch out for: Use the internal UUID, not the email address, as the path parameter.

Request example

GET /api/service/users/abc-123
Authorization: Bearer <token>

Response example

{
  "id": "abc-123",
  "username": "jdoe",
  "email": "jdoe@example.com",
  "enabled": true,
  "roles": ["$member"]
}

Invite / Create User

• Method: POST
• URL: https://{tenant}.atlan.com/api/service/users
• Watch out for: User creation is invitation-based; the user receives an email to complete registration. Bulk invite via the emails array.

Request example

POST /api/service/users
Authorization: Bearer <token>
Content-Type: application/json

{"emails":["newuser@example.com"],"roleName":"$member"}

Response example

{
  "createdUsers": {"newuser@example.com": "uuid-new"},
  "failedUsers": {}
}

Update User

• Method: POST
• URL: https://{tenant}.atlan.com/api/service/users/{userId}
• Watch out for: Atlan uses POST (not PATCH/PUT) for user updates on this endpoint per documented API behavior.

Request example

POST /api/service/users/abc-123
Authorization: Bearer <token>
Content-Type: application/json

{"firstName":"Jane","enabled":true}

Response example

{
  "id": "abc-123",
  "firstName": "Jane",
  "enabled": true
}

Disable / Deactivate User

• Method: POST
• URL: https://{tenant}.atlan.com/api/service/users/{userId}
• Watch out for: Setting enabled=false deactivates the account without deleting it. Deletion is not exposed via the public REST API.

Request example

POST /api/service/users/abc-123
Authorization: Bearer <token>
Content-Type: application/json

{"enabled":false}

Response example

{
  "id": "abc-123",
  "enabled": false
}

Change User Role

• Method: PUT
• URL: https://{tenant}.atlan.com/api/service/users/{userId}/roles
• Watch out for: Roles must be passed as internal role UUIDs, not display names. Fetch role UUIDs from GET /api/service/roles first.

Request example

PUT /api/service/users/abc-123/roles
Authorization: Bearer <token>
Content-Type: application/json

{"roles":["role-uuid-admin"]}

Response example

HTTP 204 No Content

List Groups

• Method: GET
• URL: https://{tenant}.atlan.com/api/service/groups
• Watch out for: Groups in Atlan map to Personas for access control; group membership affects data policy enforcement.

Request example

GET /api/service/groups?limit=20&offset=0
Authorization: Bearer <token>

Response example

{
  "records": [
    {"id":"grp-uuid","name":"Data Engineers","memberCount":5}
  ],
  "count": 1
}

Add User to Group

• Method: POST
• URL: https://{tenant}.atlan.com/api/service/groups/{groupId}/members
• Watch out for: Pass user IDs (UUIDs), not usernames or emails.

Request example

POST /api/service/groups/grp-uuid/members
Authorization: Bearer <token>
Content-Type: application/json

{"users":["abc-123"]}

Response example

HTTP 200 OK
{"added": ["abc-123"]}

• Rate limits: Atlan does not publicly document specific rate-limit thresholds or headers in its official developer docs as of the knowledge cutoff.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate-limit figures or headers documented. Contact Atlan support for tenant-specific limits.

• Pagination method: offset

• Default page size: 20

• Max page size: 100

• Pagination pointer: limit / offset

• Webhooks available: No

• Webhook notes: Atlan does not document outbound webhooks for user-management events in its official developer or help center documentation.

• Alternative event strategy: Use SCIM provisioning via your IdP for automated lifecycle events, or poll the REST API for user state changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://{tenant}.atlan.com/api/scim/v2

• Supported operations: GET /Users – list users, GET /Users/{id} – get user, POST /Users – provision user, PUT /Users/{id} – replace user, PATCH /Users/{id} – update user attributes, DELETE /Users/{id} – deprovision user, GET /Groups – list groups, POST /Groups – create group, PATCH /Groups/{id} – update group membership, DELETE /Groups/{id} – delete group

Limitations:

• Requires SSO (SAML) to be configured before SCIM can be enabled.
• Available on Enterprise plan only.
• SCIM token is generated separately from standard API tokens in the SSO/SCIM settings page.
• IdP-specific setup guides (Okta, Azure AD, etc.) are provided in the Atlan help center; the SCIM base URL format may vary by IdP connector configuration.

Provision a new user by POST /api/service/users with an emails array and roleName.

Capture the returned UUID from the createdUsers map, then POST /api/service/groups/{groupId}/members to assign group membership.

Caveat: the user cannot authenticate until the email invitation is accepted - API calls return success immediately but the account is not yet active.

Deprovision a departing user by resolving their UUID via GET /api/service/users?filter=email eq "...", then POST /api/service/users/{userId} with {"enabled":false}.

This deactivates the account but does not delete the record.

Full deletion requires SCIM DELETE /api/scim/v2/Users/{scimUserId} - only available on Enterprise with SSO active.

For bulk lifecycle sync, configure your IdP (Okta, Azure AD) against the SCIM 2.0 endpoint at https://{tenant}.atlan.com/api/scim/v2 using a SCIM-specific bearer token generated in Settings → SSO → SCIM.

The SCIM token is distinct from standard API tokens;

using the wrong token produces 401 errors.

SCIM requires both Enterprise plan and a fully configured SAML SSO setup before the first sync will succeed.

Role changes require internal role UUIDs, not display names.

Always resolve current UUIDs via GET /api/service/roles before issuing a PUT /api/service/users/{userId}/roles - hardcoding display names will fail silently or error.

Provision a new user and assign to a group

1. POST /api/service/users with {"emails":["user@example.com"],"roleName":"$member"} to invite the user.
2. Capture the returned UUID from createdUsers map.
3. POST /api/service/groups/{groupId}/members with {"users":[""]} to add to the target group.
4. Optionally PUT /api/service/users/{userId}/roles with the desired role UUID to assign a non-default role.

Watch out for: The user must accept the email invitation before their account is fully active; API calls succeed immediately but the user cannot log in until invitation is accepted.

Deprovision a departing user

1. GET /api/service/users?filter=email eq "user@example.com" to resolve the user's internal UUID.
2. POST /api/service/users/{userId} with {"enabled":false} to deactivate the account immediately.
3. If on Enterprise with SCIM, issue DELETE /api/scim/v2/Users/{scimUserId} via the IdP or directly to fully remove the account.

Watch out for: REST API deactivation (enabled=false) does not delete the user record; full deletion requires SCIM DELETE or manual admin action in the UI.

Bulk-sync users via SCIM from an IdP

1. Confirm Enterprise plan and SSO (SAML) are active on the tenant.
2. Navigate to Settings → SSO → SCIM and generate a SCIM bearer token.
3. Configure your IdP (e.g., Okta, Azure AD) with SCIM base URL https://{tenant}.atlan.com/api/scim/v2 and the generated token.
4. Map IdP user attributes to SCIM standard attributes (userName, name.givenName, name.familyName, emails).
5. Enable provisioning features: Create Users, Update User Attributes, Deactivate Users in the IdP connector.
6. Run an initial sync and verify users appear in Atlan Settings → Users.

Watch out for: SCIM token and SSO SAML configuration must both be complete before the first sync; partial configuration causes 401 errors from the SCIM endpoint.

The most disorienting API behavior is that user updates use POST on /users/{userId}, not PATCH or PUT. This is non-standard REST and will break integrations built on conventional HTTP verb assumptions without an explicit note in the client layer.

Role assignment is UUID-dependent with no display-name fallback. Any automation that skips the GET /api/service/roles resolution step will either assign the wrong role or throw an error - there is no forgiving lookup by name on the roles endpoint.

Webhooks for user-management events are not documented. There is no push notification when a user accepts an invitation, changes state, or is deactivated. Pipelines that need to react to lifecycle events must poll GET /api/service/users on a schedule, which compounds the risk of high-frequency requests against an undocumented rate-limit ceiling.

Use SCIM provisioning from your IdP as the event-driven alternative where possible.