Mindtickle User Management API Guide

Auth method: API key (token-based); OAuth 2.0 not confirmed in official docs

Setup steps

1. Contact Mindtickle support or your account team to request API access and obtain an API token.
2. Include the token in the Authorization header of each request (exact header format not publicly documented).
3. For SCIM provisioning, generate a SCIM bearer token from the Mindtickle admin console under Settings > Integrations > SCIM.

List Users (SCIM)

• Method: GET
• URL: https://<tenant>.mindtickle.com/scim/v2/Users
• Watch out for: Tenant subdomain format not publicly confirmed; obtain exact SCIM base URL from Mindtickle admin console.

Request example

GET /scim/v2/Users
Authorization: Bearer <scim_token>
Accept: application/scim+json

Response example

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

Get User (SCIM)

• Method: GET
• URL: https://<tenant>.mindtickle.com/scim/v2/Users/{id}
• Watch out for: User ID is Mindtickle-internal; map via externalId or userName for IdP correlation.

Request example

GET /scim/v2/Users/abc123
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "abc123",
  "userName": "user@example.com",
  "active": true
}

Create User (SCIM)

• Method: POST
• URL: https://<tenant>.mindtickle.com/scim/v2/Users
• Watch out for: Duplicate userName may return a 409 conflict; exact error schema not documented publicly.

Request example

POST /scim/v2/Users
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"new@example.com","name":{"givenName":"Jane","familyName":"Doe"},"active":true}

Response example

{
  "id": "xyz789",
  "userName": "new@example.com",
  "active": true
}

Update User (SCIM PATCH)

• Method: PATCH
• URL: https://<tenant>.mindtickle.com/scim/v2/Users/{id}
• Watch out for: PATCH support for all attributes not confirmed; PUT may be required for full replacement.

Request example

PATCH /scim/v2/Users/xyz789
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}

Response example

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

Deactivate / Delete User (SCIM)

• Method: DELETE
• URL: https://<tenant>.mindtickle.com/scim/v2/Users/{id}
• Watch out for: Behavior on DELETE (hard delete vs. deactivation) is not explicitly documented; test in a non-production environment.

Request example

DELETE /scim/v2/Users/xyz789
Authorization: Bearer <scim_token>

Response example

HTTP 204 No Content

• Rate limits: Not publicly documented.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No rate-limit details are published in official Mindtickle documentation.

• Pagination method: offset

• Default page size: Not documented

• Max page size: Not documented

• Pagination pointer: startIndex / count

• Webhooks available: No

• Webhook notes: No outbound webhook system for user-management events is documented in official Mindtickle sources.

• Alternative event strategy: Poll SCIM /Users endpoint or use IdP-driven SCIM push for near-real-time sync.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://.mindtickle.com/scim/v2

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

Limitations:

• Exact tenant subdomain and SCIM base URL must be retrieved from the Mindtickle admin console; not standardized in public docs.
• Group provisioning support via SCIM is not fully confirmed in public documentation.
• SCIM token generation and rotation process is not publicly documented in detail.
• Available only on Enterprise plan.
• No official IdP-specific SCIM connector guides (Okta, Entra, etc.) are publicly listed in help docs.

Provisioning a new user requires a POST to /scim/v2/Users with userName, name.givenName, name.familyName, emails, and active:true.

Before creating, run a GET /scim/v2/Users?filter=userName eq "email" check - duplicate userNames return a 409 conflict whose exact error schema is undocumented, so pre-flight deduplication is safer than handling the error response.

Deactivation is the standard offboarding path: retrieve the internal Mindtickle user id via a filtered GET, then PATCH with Operations: [{op:replace, path:active, value:false}].

If PATCH support for the active attribute is incomplete, fall back to a full PUT with active:false - PATCH coverage across all attributes is not confirmed in official documentation.

For IdP-driven sync (Okta, Entra, or similar), configure the generic SCIM 2.0 connector with the tenant-specific base URL and bearer token.

Map userName to email, and include externalId to enable reliable IdP-to-Mindtickle identity correlation during initial import and ongoing reconciliation.

No official IdP-specific connector guides are published by Mindtickle.

Provision a new user via SCIM

1. Obtain the SCIM bearer token from Mindtickle admin console (Settings > Integrations > SCIM).
2. POST to /scim/v2/Users with userName, name.givenName, name.familyName, emails, and active:true.
3. Store the returned Mindtickle user id for future PATCH/DELETE operations.

Watch out for: If the email already exists, expect a 409 conflict; check for existing users with GET /scim/v2/Users?filter=userName eq "email" before creating.

Deactivate a user when they leave the organization

1. Retrieve the Mindtickle user id via GET /scim/v2/Users?filter=userName eq "user@example.com".
2. Send PATCH /scim/v2/Users/{id} with Operations: [{op:replace, path:active, value:false}].
3. Confirm the response shows active:false.

Watch out for: If PATCH is not fully supported for the active attribute, fall back to PUT with the full user object and active:false.

Sync users from an IdP using SCIM

1. Configure your IdP (e.g., Okta, Entra) with the Mindtickle SCIM base URL and bearer token.
2. Map IdP attributes to SCIM attributes: userName→email, givenName, familyName, active.
3. Enable provisioning actions: Create Users, Update User Attributes, Deactivate Users.
4. Run an initial import to reconcile existing Mindtickle users with IdP records via externalId or userName matching.

Watch out for: No official IdP-specific connector guides are published by Mindtickle; use generic SCIM 2.0 connector in your IdP and validate attribute mapping manually.

The most significant operational risk is documentation opacity: no public rate limits, no pagination spec, and no error code reference means any automation built against Mindtickle's SCIM layer is flying partially blind. Behavior on DELETE (hard delete versus deactivation) is explicitly undocumented - test in a non-production environment before running any offboarding automation in production.

Group provisioning support via SCIM is not fully confirmed in public documentation, which limits how much of the permission model can be automated. SCIM token rotation process is also undocumented, creating a credential management gap for teams with security rotation policies.

Orgs below Enterprise tier have no documented programmatic path for user management at all. For those customers, every provisioning and deactivation action is manual, with no API fallback.