Connectors

Source systems we connect

The platform is built around the reality that learning data lives in many places and each exposes it differently. Connectors exist for the categories below, and new sources are added as part of an engagement rather than waiting on a roadmap.

• Learning management systems: corporate and academic platforms, legacy and current versions
• HR information systems: employee master data, roles, org units, managers, start and end dates
• Student information systems: enrolment, programmes, terms, credits, transcripts
• Content libraries and vendors: catalogue metadata, licences, usage
• Assessment and certification engines: attempts, scores, certificates, expiry
• Business systems: CRM, finance, ticketing and compliance tools that consume or produce learning events

Connection methods

We use whatever a source supports, and often more than one method for the same system to fill gaps.

• File exports (CSV, XLSX, XML, JSON) on a schedule or as one-off drops
• REST and GraphQL APIs with scoped, rotatable credentials
• Direct database connections through read-only roles
• xAPI statement streams from learning record stores or directly from content
• SFTP with key-based authentication for batch transfers
• Cloud storage buckets (S3-compatible, Azure Blob, Google Cloud Storage)

How a connector is set up

Discovery identifies the record classes available and the best method for each. A mapping is written and versioned. A first extraction runs into a staging area, where the quality report is reviewed with your team before anything is promoted into the governed layer. Credentials are stored encrypted and never shared between customers.

Legacy and decommissioned sources

When a platform is already gone, we work from whatever survived: archived exports, database backups, spreadsheets, even PDF transcripts. These are brought into the same model with lineage that clearly marks them as recovered records.