The learning record store is the part of xAPI that most organizations end up buying, building or hosting, and the part that is least understood. This guide explains what an LRS does, how the xAPI API moves data in and out of it, how it differs from an LMS and an analytics platform, and how to tell whether you need one at all.
xAPI in one paragraph
xAPI, the Experience API, is a specification for recording learning activity wherever it happens, as statements in the form actor, verb, object: Nurse A passed the medication safety simulation. Each statement can carry a result, context and timestamp. For a fuller introduction, see our guide to what xAPI is and why you would deploy it. This page picks up where that one stops: where the statements go, and how they get there.
What is a learning record store?
A learning record store, or LRS, is the database that receives, stores and returns xAPI statements. The xAPI specification requires one: any tool that sends statements needs somewhere to send them, and anything that reads them reads them from an LRS.
An LRS can be a standalone product, or it can be built into an LMS or an analytics platform. Either way, its job is storage and retrieval. An LRS answers "did we capture it", not "what does it mean". That distinction matters when you are buying, because a standalone LRS without a reporting layer on top leaves you with well-organized data and no easier way to answer questions about it.
How the xAPI API works
The xAPI API is the web interface every conformant LRS exposes. Tools talk to it over HTTPS, sending and receiving JSON, and every request identifies the version of the specification it uses and authenticates with credentials the LRS issues. The API is organized into a small number of resources:
| Resource | What it holds | Typical use |
|---|---|---|
| Statements | The learning records themselves | A simulation posts "passed"; a reporting tool queries every statement for a course since Monday |
| State | Temporary data for one learner in one activity | Letting a learner resume a module where they left off |
| Activity Profile | Data about an activity as a whole | Storing settings or shared information for a course or simulation |
| Agent Profile | Data about a learner across activities | Storing a learner's preferences |
| About | Information about the LRS itself | Checking which xAPI versions the LRS supports |
For analytics, the statements resource is the one that matters. Queries can filter by learner, verb, activity and time range, which is how a reporting layer pulls exactly the records it needs rather than everything at once.
What LRSs, LMSs and analytics platforms each do
| System | What it does with xAPI |
|---|---|
| Learning record store | Receives, stores and returns statements through the xAPI API. Can forward them to other stores. |
| LMS | Launches xAPI content and tracks it. Many also send and receive statements, and some include a built-in LRS. |
| Learning analytics platform | Reads statements, usually alongside LMS and other data, and turns them into reports and dashboards. |
Choosing an LRS
- Standalone or built in. If your LMS includes an LRS, start there. A standalone LRS makes sense when statements come from many tools that have no LMS in common.
- Conformance. Ask whether the LRS has been tested against the xAPI specification, and which version it supports.
- Querying and export. Check how easily statements can be filtered and exported, because that decides how much work reporting will take.
- Retention and residency. Ask how long statements are kept and where they are stored, including backups.
xAPI vs SCORM
SCORM is the older standard and is still everywhere. It tracks a learner's progress through a course launched from an LMS, and cannot see anything outside that course. xAPI removes that limit, at the cost of more setup, and the related cmi5 specification defines how xAPI content is launched from an LMS. For a fuller comparison, see the differences between SCORM, Tin Can and xAPI.
Do you need an LRS at all?
Only if meaningful learning happens outside your courses and you intend to instrument it. If nearly everything your organization needs to report on happens inside the LMS, an LRS adds a component without adding an answer, and the LMS's own data is the place to start.
If you do need one, plan the reporting layer at the same time. Most organizations need to read xAPI data alongside LMS, HR and credential data, and that is a different job from storing statements. Our buyer's reference on choosing a learning analytics platform explains where an LRS fits and how to tell which stage your organization is at.
Frequently asked questions
What is the difference between an LRS and an LMS?
An LMS delivers and manages learning: courses, enrollments, completions. An LRS only stores records of learning activity. An LMS can contain an LRS, but an LRS cannot deliver a course.
Is the xAPI API the same as xAPI?
The xAPI API is part of the xAPI specification: the web interface an LRS exposes. The specification also defines the statement format and the rules for using it.
Does every LMS support xAPI?
No. Support ranges from a full built-in LRS to plugins or nothing at all. Check separately whether an LMS can launch xAPI content, send statements and store them.
Can xAPI data be used with Power BI or Tableau?
Yes, if the LRS or analytics platform can export or expose the data. Someone still has to model it, which is the ongoing cost to plan for.
