Anaplan User Management API Guide

Auth method: OAuth 2.0 (preferred); Basic Auth (username:password Base64-encoded); Certificate-Based Auth (CA certificate). SCIM endpoints use a dedicated API key.

Setup steps

1. For OAuth 2.0: Must be a tenant security administrator. Navigate to Administration > Security > OAuth Clients. Enable OAuth if first time. Click New, select grant type (Authorization Code or Device Grant), enter callback URL(s), and click Create Client. Copy the Client ID and Client Secret.
2. For Basic Auth: Base64-encode 'email:password' and pass as 'Authorization: Basic ' header to https://auth.anaplan.com/token/authenticate to obtain an AnaplanAuthToken.
3. For Certificate Auth: Upload a CA certificate in Administration > Security. Use the certificate private key to sign requests to the auth service to obtain an AnaplanAuthToken.
4. For SCIM API key (Azure AD / Okta): In Administration, generate an API key scoped to SCIM. Provide this key as the Bearer token in the Authorization header when configuring the IdP SCIM provisioning connector.
5. All Integration API v2 calls use the obtained token as: 'Authorization: AnaplanAuthToken {token}' or 'Authorization: Bearer {oauth_access_token}'.

Required scopes

Obtain Auth Token (Basic/Certificate)

• Method: POST
• URL: https://auth.anaplan.com/token/authenticate
• Watch out for: Basic Auth passwords expire every 90 days, requiring token refresh. Certificate-based auth avoids this.

Request example

curl -X POST https://auth.anaplan.com/token/authenticate \
  -H 'Authorization: Basic <base64(email:password)>'

Response example

{
  "tokenInfo": {
    "tokenValue": "AnaplanAuthToken ...",
    "expiresAt": 1700000000000
  }
}

List Users (Financial Consolidation API)

• Method: GET
• URL: https://api.anaplan.com/2/0/workspaces/{workspaceId}/users
• Watch out for: Returns users scoped to the specified workspace. A non-Workspace Administrator can only retrieve their own user record.

Request example

curl -X GET \
  https://api.anaplan.com/2/0/workspaces/{workspaceId}/users \
  -H 'Authorization: AnaplanAuthToken {token}'

Response example

{
  "users": [
    {
      "id": "abc123",
      "userName": "user@example.com",
      "active": true,
      "roles": ["Workspace Administrator"]
    }
  ]
}

Add User to Workspace

• Method: POST
• URL: https://api.anaplan.com/2/0/workspaces/{workspaceId}/users
• Watch out for: New users added via API default to 'No Access' model role. A workspace administrator must separately assign model-level access.

Request example

curl -X POST \
  https://api.anaplan.com/2/0/workspaces/{workspaceId}/users \
  -H 'Authorization: AnaplanAuthToken {token}' \
  -H 'Content-Type: application/json' \
  -d '{"email":"user@example.com","firstName":"Jane","lastName":"Doe"}'

Response example

{
  "user": {
    "id": "abc123",
    "userName": "user@example.com",
    "active": true
  }
}

Update User (enable/disable, email)

• Method: PUT
• URL: https://api.anaplan.com/2/0/workspaces/{workspaceId}/users/{userId}
• Watch out for: Disabling a user removes platform access but does not delete the account or free a license seat.

Request example

curl -X PUT \
  https://api.anaplan.com/2/0/workspaces/{workspaceId}/users/{userId} \
  -H 'Authorization: AnaplanAuthToken {token}' \
  -H 'Content-Type: application/json' \
  -d '{"active": false}'

Response example

{
  "user": {
    "id": "abc123",
    "active": false
  }
}

Delete User from Workspace

• Method: DELETE
• URL: https://api.anaplan.com/2/0/workspaces/{workspaceId}/users/{userId}
• Watch out for: Deletes user from the specified workspace only. If user belongs to multiple workspaces, they must be removed from each individually.

Request example

curl -X DELETE \
  https://api.anaplan.com/2/0/workspaces/{workspaceId}/users/{userId} \
  -H 'Authorization: AnaplanAuthToken {token}'

Response example

{
  "status": {
    "code": 200,
    "message": "Success"
  }
}

SCIM: Create User

• Method: POST
• URL: https://api.anaplan.com/scim/1/0/v2/Users
• Watch out for: SCIM provisioning operates at the Workspace level. Model-level role assignment is not handled by SCIM and must be managed separately.

Request example

curl -X POST \
  https://api.anaplan.com/scim/1/0/v2/Users \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: application/scim+json' \
  -d '{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"user@example.com","name":{"givenName":"Jane","familyName":"Doe"},"active":true}'

Response example

{
  "id": "abc123",
  "userName": "user@example.com",
  "active": true,
  "meta": {"resourceType": "User"}
}

SCIM: Update User (PATCH)

• Method: PATCH
• URL: https://api.anaplan.com/scim/1/0/v2/Users/{userId}
• Watch out for: PATCH is the standard SCIM deprovision operation. Okta and Azure AD use PATCH active=false to deactivate users.

Request example

curl -X PATCH \
  https://api.anaplan.com/scim/1/0/v2/Users/{userId} \
  -H 'Authorization: Bearer {api_key}' \
  -H 'Content-Type: application/scim+json' \
  -d '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}'

Response example

{
  "id": "abc123",
  "active": false
}

SCIM: List Users

• Method: GET
• URL: https://api.anaplan.com/scim/1/0/v2/Users
• Watch out for: Supports SCIM filter parameter (e.g., ?filter=userName eq "user@example.com") for targeted lookups.

Request example

curl -X GET \
  'https://api.anaplan.com/scim/1/0/v2/Users?startIndex=1&count=100' \
  -H 'Authorization: Bearer {api_key}'

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 50,
  "startIndex": 1,
  "itemsPerPage": 100,
  "Resources": [{"id":"abc123","userName":"user@example.com"}]
}

• Rate limits: Anaplan enforces a per-tenant API request rate limit. Community-reported HTTP 429 errors cite a limit of 600 requests per minute. Official documentation does not publish a formal rate limit table.
• Rate-limit headers: No
• Retry-After header: No
• Rate-limit notes: HTTP 429 is returned when the limit is exceeded. Official docs do not document rate limit response headers or a Retry-After header. Retry with exponential backoff is recommended. MCP servers and certain AI services are explicitly restricted from using Anaplan APIs per official policy.
• Pagination method: offset
• Default page size: 0
• Max page size: 0
• Pagination pointer: offset

• Webhooks available: No
• Webhook notes: Anaplan does not offer native outbound webhooks for user lifecycle events. The Audit API can be polled to track user-related events and feed into SIEM systems, but there is no push-based webhook mechanism.
• Alternative event strategy: Use the Anaplan Audit API (https://api.anaplan.com) to poll for user activity and security events. CloudWorks can be used to schedule periodic integration jobs.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (SSO prerequisite required; part of Central Identity Management features)

• Endpoint: https://api.anaplan.com/scim/1/0/v2

• Supported operations: GET /Users (list users), GET /Users/{id} (get user), POST /Users (create user), PUT /Users/{id} (replace user), PATCH /Users/{id} (update user / deprovision), DELETE /Users/{id} (delete user), GET /Groups (list groups/workspaces), GET /Groups/{id} (get group), POST /Groups (create group), PATCH /Groups/{id} (update group membership), GET /ServiceProviderConfig, GET /Schemas

Limitations:

• SCIM provisioning operates at the Workspace level only; model-level role assignment must be managed separately outside SCIM.
• SSO must be configured as a prerequisite before SCIM can be enabled.
• API key rotation is not natively supported; rotation requires revoke, delete, and recreate steps.
• Supported IdPs are Okta and Azure AD (Microsoft Entra ID); Google Workspace and OneLogin are not officially listed.
• SCIM Groups in Anaplan map to Workspaces, not to model-level roles.
• Enterprise plan required; pricing is custom and not publicly listed.

Three integration patterns are documented with working endpoint references.

(1) Okta SCIM provisioning: configure SSO first, generate a SCIM API key, set the SCIM base URL to https://api.anaplan.com/scim/1/0/v2 in the Okta Anaplan app, map userName/givenName/familyName/active, and assign Okta groups to Anaplan SCIM Groups (which map to Workspaces, not model roles).

Model-level role assignment remains outside SCIM scope and must be handled separately. (2) Programmatic deactivation via SCIM PATCH: GET /Users?

filter=userName eq "user@example. com" to resolve the user ID, then PATCH /Users/{id} with active=false.

Note that PATCH deactivation removes platform access but does not delete the record or release a named license seat - DELETE is required for full removal. (3) OAuth 2.

0 device grant for headless integrations: create a Device authorization code grant client in Administration > Security > OAuth Clients, poll the token endpoint with the device_code, and use a dedicated service account - access tokens are tied to the approving user's permissions and will fail if that user's access is revoked.

Rate limits are community-reported at 600 requests/minute; no official rate limit headers or Retry-After header are returned on HTTP 429 responses, so exponential backoff is required.

Automated user provisioning via Okta SCIM

1. Ensure SSO is configured in Anaplan Administration > Security > Single Sign-On.
2. Generate a SCIM API key in Anaplan Administration (User Admin role required).
3. In Okta, add the Anaplan SCIM app and configure the SCIM base URL as https://api.anaplan.com/scim/1/0/v2 with the API key as the Bearer token.
4. Map Okta user attributes to SCIM fields: userName (email), name.givenName, name.familyName, active.
5. Assign Okta groups to Anaplan SCIM Groups (Workspaces) to control workspace membership.
6. Enable provisioning features: Create Users, Update User Attributes, Deactivate Users.
7. Test with a pilot user; verify the user appears in Anaplan Administration > Users > Internal.
8. After SCIM provisioning, a workspace administrator must assign model-level roles separately in each model.

Watch out for: SCIM only provisions at the Workspace level. Model-level access (e.g., Full Access, Read Only) must be assigned manually or via a separate integration.

Programmatic user deactivation via SCIM PATCH

1. Obtain the Anaplan SCIM user ID by calling GET https://api.anaplan.com/scim/1/0/v2/Users?filter=userName eq "user@example.com".
2. Extract the 'id' field from the response.
3. Send PATCH https://api.anaplan.com/scim/1/0/v2/Users/{id} with body: {"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}
4. Verify the user's 'active' field is false in the GET /Users/{id} response.

Watch out for: Deactivating (active=false) removes platform access but does not delete the user record or free a named license seat. Use DELETE to fully remove the user.

OAuth 2.0 device grant for headless integration

1. As a tenant security administrator, go to Administration > Security > OAuth Clients > Enable OAuth > New.
2. Select 'Device authorization code grant' as the grant type. Enter a placeholder callback URL (e.g., https://anaplan.com).
3. Copy the Client ID after creation.
4. In your integration script, POST to the device authorization endpoint to obtain a device_code and user_code.
5. Direct the user to the verification URL to approve the device.
6. Poll the token endpoint with the device_code until an access_token and refresh_token are returned.
7. Use 'Authorization: Bearer {access_token}' on all Integration API v2 calls.
8. Use the refresh_token (requires offline_access scope) to obtain new access tokens without re-prompting the user.

Watch out for: OAuth access tokens are tied to the approving user's permissions. If that user's access is revoked in Anaplan, the integration will fail. Use a dedicated service account user.

Several API behaviors create silent failure modes that are not prominently documented. API key rotation is not natively supported - the only path is revoke, delete, and recreate, which causes downtime for any active IdP sync.

Users added to a workspace via API default to No Access model role; workspace administrators must separately assign model-level permissions, meaning a technically successful provisioning call can leave a user unable to access any model.

The Integration API v2 and SCIM API can conflict with Administration UI changes on the same user record (last-write-wins); mixing API and UI provisioning paths for the same user population is explicitly inadvisable.

SCIM Groups map to Workspaces only - there is no SCIM mechanism for model-role assignment, which is the access layer that actually controls what a user can do in Anaplan.

Finally, the explicit API restriction on MCP servers means that any MCP server with ~100 deep IT/identity integrations must treat Anaplan as a policy-restricted target and document this constraint clearly for downstream implementers.