TalentLMS User Management API Guide

Auth method: HTTP Basic Auth (API key as username, empty password)

Setup steps

1. Log in to TalentLMS as an Administrator.
2. Navigate to Account & Settings > Basic Settings.
3. Locate the API key field and copy your API key.
4. When making requests, use HTTP Basic Auth: set the API key as the username and leave the password blank.
5. Encode credentials as Base64 for the Authorization header: Authorization: Basic base64(apikey:)

List all users

• Method: GET
• URL: https://[domain].talentlms.com/api/v1/users
• Watch out for: Returns a flat array; use page and per_page for pagination. Default page_size is 20.

Request example

GET /api/v1/users?page=1&per_page=20
Authorization: Basic base64(apikey:)

Response example

[
  {
    "id": 1,
    "login": "jdoe",
    "first_name": "John",
    "last_name": "Doe",
    "email": "jdoe@example.com",
    "role": "learner",
    "status": "active"
  }
]

Get a single user by ID

• Method: GET
• URL: https://[domain].talentlms.com/api/v1/users/:id
• Watch out for: Can also look up by email using /users/email:[email] instead of numeric ID.

Request example

GET /api/v1/users/42
Authorization: Basic base64(apikey:)

Response example

{
  "id": 42,
  "login": "jdoe",
  "first_name": "John",
  "last_name": "Doe",
  "email": "jdoe@example.com",
  "role": "learner",
  "status": "active"
}

Create a user

• Method: POST
• URL: https://[domain].talentlms.com/api/v1/users
• Watch out for: Request body must be form-encoded, not JSON. login and email must be unique across the account.

Request example

POST /api/v1/users
Content-Type: application/x-www-form-urlencoded

first_name=John&last_name=Doe&email=jdoe@example.com&login=jdoe&password=Secret123

Response example

{
  "id": 43,
  "login": "jdoe",
  "first_name": "John",
  "last_name": "Doe",
  "email": "jdoe@example.com",
  "role": "learner",
  "status": "active"
}

Update a user

• Method: PUT
• URL: https://[domain].talentlms.com/api/v1/users/:id
• Watch out for: Uses PUT, not PATCH; only fields included in the body are updated. Omitting a field does not clear it.

Request example

PUT /api/v1/users/43
Content-Type: application/x-www-form-urlencoded

first_name=Jonathan&status=inactive

Response example

{
  "id": 43,
  "login": "jdoe",
  "first_name": "Jonathan",
  "status": "inactive"
}

Delete a user

• Method: DELETE
• URL: https://[domain].talentlms.com/api/v1/users/:id
• Watch out for: Deletion is permanent and removes all user data including course progress. Consider deactivating (status=inactive) instead.

Request example

DELETE /api/v1/users/43
Authorization: Basic base64(apikey:)

Response example

{
  "id": "43",
  "message": "Operation completed successfully"
}

Enroll user in a course

• Method: POST
• URL: https://[domain].talentlms.com/api/v1/addusertocourse
• Watch out for: This is a separate endpoint, not nested under /users. Role in course defaults to learner unless role parameter is specified.

Request example

POST /api/v1/addusertocourse
Content-Type: application/x-www-form-urlencoded

user_id=43&course_id=7

Response example

{
  "user_id": "43",
  "course_id": "7",
  "message": "Operation completed successfully"
}

Get user's course status

• Method: GET
• URL: https://[domain].talentlms.com/api/v1/getuserstatusincourse
• Watch out for: Returns null fields if user has not yet accessed the course after enrollment.

Request example

GET /api/v1/getuserstatusincourse?user_id=43&course_id=7
Authorization: Basic base64(apikey:)

Response example

{
  "user_id": "43",
  "course_id": "7",
  "completion_status": "completed",
  "completion_percentage": 100
}

Get user by email (lookup)

• Method: GET
• URL: https://[domain].talentlms.com/api/v1/users/email::email
• Watch out for: The colon-prefixed email syntax is specific to TalentLMS. URL-encode the email address to avoid parsing issues.

Request example

GET /api/v1/users/email:jdoe@example.com
Authorization: Basic base64(apikey:)

Response example

{
  "id": 43,
  "login": "jdoe",
  "email": "jdoe@example.com",
  "status": "active"
}

• Rate limits: TalentLMS does not publicly document specific rate limit thresholds or per-plan tiers in its official API docs.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate limit figures, headers, or Retry-After behavior documented. Contact TalentLMS support for enterprise-level guidance.

• Pagination method: offset

• Default page size: 20

• Max page size: 1000

• Pagination pointer: page, per_page

• Webhooks available: No

• Webhook notes: TalentLMS does not offer native outbound webhooks in its official documentation. Event-driven integrations are typically handled via polling the REST API or using third-party automation platforms (e.g., Zapier, Make).

• Alternative event strategy: Poll the REST API for user and course status changes, or use the TalentLMS Zapier integration for event-triggered workflows.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: All paid plans (Core and above); SSO must be configured as a prerequisite

• Endpoint: Tenant-specific SCIM endpoint provided within the TalentLMS SSO/SCIM settings UI after enabling SCIM for the configured IdP

• Supported operations: Create users (POST /Users), Update users (PUT /Users/:id), Deactivate users (PATCH /Users/:id with active=false), List users (GET /Users), Get user by ID (GET /Users/:id)

Limitations:

• SCIM endpoint URL is IdP-specific and generated within the TalentLMS admin UI; it is not a static public endpoint.
• SSO (SAML 2.0) must be configured before SCIM provisioning can be enabled.
• Supported IdPs documented: Okta, Microsoft Entra ID (Azure AD), OneLogin.
• Group/branch provisioning support may vary by IdP connector.
• Hard deletion via SCIM may not be supported; deactivation (active=false) is the documented deprovisioning action.

Provision and enroll a new employee: POST /api/v1/users with form-encoded first_name, last_name, email, login, password, and role=learner;

capture the returned id;

then POST /api/v1/addusertocourse with user_id and course_id.

Check for duplicate login or email first via GET /api/v1/users/email:[address] - the create call returns an error on collision with no upsert behavior.

Deactivate a departing employee: GET /api/v1/users/email:[address] to resolve the numeric id, then PUT /api/v1/users/:id with status=inactive.

Prefer this over DELETE - deletion is irreversible and removes all course completion records.

Via SCIM, send PATCH /Users/:id with {"op":"replace","path":"active","value":false} through the IdP connector;

SCIM deprovisioning requires an active SSO configuration.

Bulk-sync from an HR system: paginate GET /api/v1/users?page=1&per_page=1000 to build a local email-to-id map, then create, update, or deactivate per record.

No batch endpoint exists - every operation is a discrete HTTP call.

With no documented rate limits, implement deliberate pacing;

silent throttling is possible.

Provision a new employee and enroll in onboarding course

1. POST /api/v1/users with first_name, last_name, email, login, password, and role=learner to create the user account.
2. Capture the returned user id from the response.
3. POST /api/v1/addusertocourse with user_id and the target onboarding course_id to enroll the user.
4. Optionally GET /api/v1/getuserstatusincourse to confirm enrollment status.

Watch out for: Request bodies must be form-encoded. If login or email already exists, the create call returns an error - check for duplicates first using GET /api/v1/users/email:[address].

Deactivate a departing employee

1. GET /api/v1/users/email:[employee_email] to retrieve the user's numeric id.
2. PUT /api/v1/users/:id with status=inactive to deactivate the account without deleting learning history.
3. If using SCIM, send a PATCH /Users/:id with {"op":"replace","path":"active","value":false} via the IdP-managed SCIM connector.

Watch out for: Prefer deactivation over DELETE to preserve course completion records. SCIM deprovisioning requires SSO to be active.

Bulk-sync users from an external HR system

1. Paginate GET /api/v1/users?page=1&per_page=1000 to retrieve all existing TalentLMS users and build a local email-to-id map.
2. For each HR record, check if the email exists in the map.
3. If not found, POST /api/v1/users to create the user.
4. If found and attributes differ, PUT /api/v1/users/:id with changed fields.
5. For users present in TalentLMS but absent from HR, PUT /api/v1/users/:id with status=inactive.

Watch out for: No bulk/batch endpoint exists; each create or update is a separate HTTP call. No documented rate limits, so implement conservative request pacing to avoid throttling.

The account-wide API key is the single credential for all API access; there is no scope restriction or rotation mechanism documented, which means a leaked key exposes full admin operations across the entire tenant.

The non-standard email lookup syntax (/users/email:[address] with a colon separator, not a query parameter) is a parsing edge case - URL-encode the address to avoid silent misroutes.

The PUT /api/v1/users/:id endpoint behaves as a partial update in practice (omitting a field does not clear it), but it is declared as PUT, not PATCH - callers building idempotent sync logic should verify field behavior against their target fields rather than assuming full-replacement semantics. Custom user profile fields are account-specific;

field keys must be retrieved from the admin UI before use in API calls, and there is no endpoint to enumerate them programmatically.

SCIM's dependency on a pre-configured SSO connection means that any identity graph integration path through SCIM carries an implicit prerequisite: SSO must be live and stable before provisioning automation can be trusted. Teams that configure SCIM before validating their SSO setup will encounter provisioning failures that surface at the IdP layer, not within TalentLMS itself.