New Home

LMS Integration Guide

scheduleLast updated on November 13, 2026

Note: This page is intended primarily for Enablement and Implementation teams.

Purpose

One-stop reference for understanding what it takes to integrate a new LXP/LMS into Eightfold's Talent Management platform.

Summary

Two Scenarios:

Existing adapter (vendor already integrated) → Implementation team configures per customer. E.g., Degreed
New LXP vendor (e.g., first Docebo customer) → Engineering builds adapter from scratch

Hard Blockers:

Multi-LXP: Not supported (database limitation)
Multi-tenant: Avoid (causes delays, data issues)

Prerequisites:

4 API endpoint types required (catalog list, course fetch, user completions, eligibility tags)
OAuth 2.0 or API key auth
100-500 RPM rate limits (higher for 50K+ catalogs)
Single-tenant, single-LXP architecture

Timeline:

Backfill: ~12 hours (~36K courses), longer for 50K+
Adapter development: ~2 weeks
Skills add-ons (Degreed specific): 8-week vendor lead time

Sync Expectations:

Course catalog: Daily batch (24-hour delay)
User attendance: On-demand when user visits Career Hub (max 1/day)

Integration Overview

Scenario 1: Per-Customer Configuration (Once Adapter Exists)

When needed: Every customer using an LXP where adapter already exists

Who does this: Implementation Team

What's required:

Admin Console setup with credentials
Career Hub config deployment (lxp_sync_config)
Initial backfill
Testing and validation

Timeline: 1 day

Scenario 2: LXP Adapter Development (Required Per NEW LXP Vendor)

When needed: First time integrating with a specific LXP vendor (e.g., first Docebo customer)

What Engineering must build:

LXP Adapter
- Implement adapter to communicate with LXP's API
- Field mapping from LXP data format to Eightfold data model
- Authentication flow implementation
- Error handling
Admin Console Integration
- Add new LXP option to integration systems dropdown
- Configuration forms for integration setup
- Connectivity test setup on Admin Console

Who builds: TM Engineering Team

Timeline: ~2 weeks

What We Sync

Supported:

Course content/catalog
Course attendance (per-user completions)
Course visibility/eligibility tags (group access rules)

Phase 1: Pre-Sales Discovery & Requirements Gathering

Owner: Pre-Sales Team
Output: Feasibility Assessment

Question 1: Have we integrated with this LXP vendor before?

Question 2: Customer architecture complexity

[ ] How many LXP systems does customer use?
[ ] Is the LXP single-tenant or multi-tenant?

See FAQs: Why Multi-LXP is not supported
See FAQs: Why Multi-tenant LXPs is not supported

Requirements Checklist

Required API Endpoints

1. Course Catalog Enumeration

[ ] API endpoint to list all courses
[ ] Support for time-based filtering (modified_after/modified_since parameter)
[ ] Pagination support (at least 1000 records per page)

2. Course Fetch

[ ] API to retrieve individual course by ID

Required response fields:

course_id
title, description, duration (preferably in hours)
provider, course_type
language (preferably in locale format: en-US, zh-CN, zh-TW)
skills, course_url, image_url
modified_ts, published_ts (timestamps)
eligibility_tags (for user visibility matching)

3. User Course Completion Data

[ ] API to fetch user's completed/in-progress courses
[ ] User lookup by email OR HRIS ID

Required response fields:

course_id, title, provider, description
completion_ts, course_url, duration (preferably hours), course_type

4. Course Visibility/Eligibility Tags

How Tag-Matching Works:
- Courses have tags (e.g., Engineering, Sales, Leadership)
- Users have tags (e.g., Engineering, Marketing)
- If any tag matches, course is visible to user
- Example: Course tags (A, B, C) + User tags (B, D, E) = visible because B matches
What We Need from LXP:
- Tags on courses
- API to fetch user's tags
For more details: Targeting Courses to Specific Employees

5. Authentication Method

Preferred: OAuth 2.0 Client Credentials flow
Alternative: API key authentication

Required credentials (OAuth 2.0):

token_url - OAuth token endpoint
client_id - OAuth client ID
client_secret - OAuth client secret
scope - OAuth scope
grant_type - Set to client_credentials

Alternative: API key authentication

6. Rate Limits & Negotiation

Preferred: 100-500 RPM minimum
Callout: If the list endpoint only returns course IDs (not full course data), best to have higher RPM.

Reason: Must fetch each course individually
For example, 50K courses = 50K separate fetch calls, significantly slows initial backfill, and daily syncs if large number of course changes.

Set Customer Expectations

Sync Frequency & Latency:

Data Type	Sync Method	Frequency	Latency
Course catalog	Automated daily batch	Once per day	24-hour delay
Course attendance	On-demand per user	When user visits Career Hub	Max 1 sync/day/user
Eligibility tags	On-demand per user	When user visits Career Hub	Max 1 sync/day/user

Key points:

Course content doesn't change frequently enough to warrant real-time sync
Course attendance is near-real-time: Triggered when user visits Career Hub
24-hour sync delay from when changes occur in LXP to when they appear in Eightfold

See FAQs: Why Daily Scheduled Batch Sync

Skills Integration Requirements

Check: Does LXP provide skills data via API?

Degreed-specific requirement:

Requires "Skills+" add-on to be enabled
Skills will NOT be available without this add-on

Action required:

[ ] Verify Skills+ is enabled during discovery phase
[ ] If not enabled, customer must request it from Degreed
[ ] Lead time: ~8 weeks for Degreed to enable Skills+

⚠️ This must be identified early in sales cycle to avoid delays

Phase 2: Implementation

Scenario A: Existing Adapter Available

Owner: Implementation Team

Step 1: Gather Customer Credentials

OAuth credentials:

[ ] token_url
[ ] client_id
[ ] client_secret
[ ] scope

Identifier type decision:

[ ] Employee ID-based (recommended - requires HRIS integration)
[ ] Email-based (alternative option)

Step 2: Admin Console Configuration

Add LXP integration system in Admin Console:
- Enter OAuth credentials
- System name: [Customer Name] - [LXP Vendor]
Test connectivity:
- Use "Test Connection" feature in Admin Console
- ✅ Success: Proceed
- ❌ Failure: Troubleshoot credentials with customer
Capture System ID:
- After saving, note the system_id displayed in Admin Console
- This will be used in Career Hub config

Step 3: Career Hub Configuration

Coordinate with TM Engineering to add this config:

{
  "lxp_sync_config": {
    "sync_mode_live_enabled": false,
    "sync_mode_async_enabled": true,

    "lxp_adapter_selection_rules": [
      {
        "rule_id": "default_<lxp_name>",
        "adapter_name": "<adapter_name>",
        "system_id": "<system_id from Admin Console>",
        "condition": "{{ True }}",
        "assert_value": true
      }
    ]
  }
}

Configuration notes:

adapter_name: Name of LXP adapter (e.g., "degreed")
system_id: Must match what was configured in Admin Console
Standard single-tenant setup (multi-tenant requires custom routing - avoid)

Step 4: Initial Backfill

Enumerate all courses
Fetch detailed course data for each course
User attendance sync is not included during backfill (no simple trigger mechanism available)

Setup Steps:

Add LXP integration system in Admin Console with credentials
Test connectivity via Admin Console "Test Connection" feature
Trigger initial backfill sync via Admin Console

Scenario B: New Adapter Required (Tier 2)

Owner: TM Engineering Team

What Engineering must build:

LXP Adapter Development
- API client to communicate with LXP's REST API
- Field mapping from LXP data model to Eightfold data model
- Authentication flow implementation (OAuth or API Key)
- Error handling for LXP-specific quirks
Admin Console Integration
- Add new LXP option to integration systems dropdown
- Configuration forms for credentials
- "Test Connection" functionality

Implementation team role:

Provide LXP API access to engineering
Test integration in sandbox
Validate with first customer

FAQs

1. Why Multi-LXP is not supported

Issue: Database architecture does not support multiple LXP systems

Why:

Course attendance records NOT partitioned by system_id
No attribution of attendance record to specific LXP
Multiple LXPs = data corruption (records overwrite each other)

2. Why Multi-tenant LXPs is not supported

Issue: Multi-tenant LXP setups (e.g., Degreed GAT) create complex data attribution challenges

Recommendation: Completely avoid multi-tenant setups for future customers. Require single-tenant configuration as a prerequisite.

3. Course Visibility/Eligibility Rules

How it works:

Courses restricted to specific user groups
We ingest these as eligibility tags
Both courses and users must have matching tags for visibility

What we store:

Course eligibility tags - Groups that can access each course
User eligibility tags - Groups the user belongs to

Configuration: See Targeting Courses to Specific Employees

4. Data Quality Issues: Case-Variant Course IDs

Degreed returns unique lms_course_id with different casings (e.g., ABC123 vs abc123) (each referring to a different course)
Impact: Causes course id collisions in our DB
Resolution: We are addressing this on our end by implementing case-insensitive handling

5. Language Locale Inconsistency

Issue: Degreed does not provide language in consistent locale format
Example: Chinese courses tagged as just zh without distinguishing Simplified vs Traditional Chinese
Impact:

Cannot segregate languages that have regional variants
Affects content targeting for users with specific language preferences

Workaround: Courses grouped under generic language tag (e.g., all Chinese courses under zh)

6. Why Daily Scheduled Batch Sync

Leverages existing ATS sync framework - Well-designed pre-existing system with monitoring, retry logic, and alerting already built in
Content cadence matches sync frequency - Course content doesn't change frequently enough to warrant real-time sync
Efficient for batch ingestion - DAG-based scheduled execution handles large course catalogs efficiently
Course attendance is near-real-time - Triggered via processor operation when user visits Career Hub, with maximum of 1 successful sync per day per user (prevents excessive API calls while keeping data reasonably fresh)
Note: There is a 24-hour sync delay from when course changes occur in the LXP to when they appear in our system

Pre-Work Validation Checklist

Before starting integration:

[ ] OAuth credentials obtained and validated
- token_url, client_id, client_secret, scope provided
- Test connectivity via Admin Console "Test Connection"
[ ] Single LXP and single tenant confirmed
- Only 1 LXP per customer
- Only 1 tenant (no GAT/multi-tenant setups)
[ ] Data scope and sync delay expectations set
- Course catalog sync: Daily sync, 24-hour delay
- Course attendance sync: On-demand per user, max 1 sync/day
- Course visibility rules: On-demand per user, max 1 sync/day
- Ensure eligibility tags set correctly on courses and users
[ ] Skills+ enabled (Degreed-specific)
- Verify Skills+ add-on active in customer's Degreed instance
- If not enabled, initiate request (8-week lead time)

Appendix: Degreed Reference Implementation

Integration Architecture

API Endpoints Used:

Base URL: https://{customer-subdomain}.degreed.com/api/v2

Endpoint	Purpose	Pagination
`GET /content`	List/enumerate all courses	Yes (1000/page)
`GET /content/{course_id}`	Fetch individual course details	N/A
`GET /users/{identifier}/completions`	Pull course attendance for user	Yes (1000/page)
`GET /users/{identifier}/groups`	Pull user eligibility/group memberships	Yes (1000/page)

Key query parameters:

filter[modified_after] - Filter courses modified after date (yyyy-mm-dd format)
identifier - User lookup type: email or employee-id
limit - Results per page (we use 1000)

Authentication Method

Method: OAuth 2.0 Client Credentials Flow (only supported method by Degreed)

Required credentials:

token_url - OAuth token endpoint (e.g., https://{customer}.degreed.com/oauth/token)
client_id - OAuth client ID provided by Degreed
client_secret - OAuth client secret provided by Degreed
scope - OAuth scope (typically api/v2 or custom scope per customer)
grant_type - Set to client_credentials

Sync Approach

Frequency:

Daily automated sync (runs once per day per customer)
Uses time window sync (modified_after filter) for incremental updates
Ad-hoc manual sync available via Admin Console

Trigger logic:

Automated (Default):

Daily time window sync - Requests courses modified in last 1 day
Uses filter[modified_after] parameter
Incremental sync reduces API load

Manual:

Admin-triggered via Integrations Console
Entity ID list sync (specific courses)
Full refresh option (no time filter)

Preferred method: Daily Scheduled Batch Sync