SCORM vs xAPI comes down to direction. SCORM is a package you upload and play inside your LMS, and it reports back a finish and a score. xAPI is a stream of “who did what” statements that gets sent to a separate store called a Learning Record Store (LRS).
On a WordPress LMS, that means two different jobs. One standard is about running someone else’s course. The other is about shipping learning data out to somewhere else.
A quick note on where Learnomy stands: both are Learnomy Pro extensions. Learnomy Free ships the lesson foundation they plug into, but neither standard is in Free. The Free vs Pro page has the split.
The one-line difference
SCORM answers “did this learner finish this package, and what did they score?” xAPI answers “what did this learner do, and when?”
SCORM lives inside the LMS. The course runs in a frame on your site and talks to the page around it. xAPI doesn’t care where the activity happens. It describes an event as a short statement, roughly actor, verb and object, as laid out in the xAPI specification, and sends it to an LRS.
What SCORM tracks, and where it stops
A SCORM package is a zip file from an authoring tool. It reports completion status, a score, time spent and a bookmark so the learner can resume. That’s most of it.
It also needs a player to host it. The package reports back to the page that launched it, so it needs an LMS or another SCORM player around it.
That’s the limit. You get a finish line and a number, not a trail of what happened on the way. If you want to know which question people got wrong or what they did after the course, SCORM won’t tell you.
The version question (1.2 or 2004) is mostly about how your authoring tool exports. We cover it, and the upload steps, in how to add SCORM courses to a WordPress site, so I won’t repeat it here.
What xAPI records, and why it needs an LRS
An xAPI statement is a small record: a learner, a verb like “completed” or “answered”, and the thing it happened to. A site can send many of them for one course, so you end up with an activity history instead of a single result.
Those statements need somewhere to land. That’s the Learning Record Store. It’s a separate system that stores statements and lets you query them, and the LMS doesn’t do that job for you. Which means choosing xAPI also means choosing an LRS, running it or paying for it, and having someone who will actually read what it collects.
That last part matters more than the standard. Plenty of teams adopt xAPI and then never look at the data.
What a WordPress LMS does with each
Here’s the honest picture for Learnomy Pro, since the two standards aren’t symmetrical.
| SCORM | xAPI | |
|---|---|---|
| Learnomy Pro does | Imports, plays, tracks | Sends statements |
| Direction | Package reports to your site | Your site reports to an LRS |
| You also need | The package | An LRS |
SCORM: you upload a SCORM 1.2 or 2004 package as a lesson. Learners play it in a sandboxed runtime inside the normal lesson player, and an admin report shows status, score and time per learner. The SCORM docs have the details.
xAPI: Learnomy sends statements to whichever LRS you point it at. It’s emit-only. Learnomy doesn’t read from the LRS, query it, or act as one. If a statement fails to deliver it retries with backoff, and a statement that still can’t be sent lands in the audit log rather than disappearing. Setup is in the xAPI docs.
What it sends is Learnomy’s own activity: enrolments, lesson completions, quiz results and individual answers.
When SCORM is enough
SCORM is enough more often than people expect. If your reason for a standard is “we already have courses built in an authoring tool and need them to run and report completion,” that’s SCORM and nothing else.
It’s also enough when the question you get asked is simple. Did this learner finish the safety module, and what was their score? A tracking report with a CSV export answers that. Corporate and compliance training mostly lives here.
And if you write your own lessons directly in the course builder, you may not need either standard. The course builder tracks progress natively.
When you need xAPI
You need xAPI when the data has to go somewhere else. The usual cases: your company already runs an LRS and wants learning from every system in one place, a client’s analytics team asks for statements, or you want a record of activity that finish-and-score can’t give you.
If nobody has an LRS and nobody has asked for one, skip it. Turning it on without a destination sends nothing anyway, because the module needs an endpoint before it does anything.
One thing xAPI is not: a replacement for the progress your learners see. Their course progress and certificates run on Learnomy’s own completion, and xAPI just reports on it.
Using both without double counting completion
You can run both, and the thing worth knowing is that completion only happens once.
A finished SCORM package hands its verdict to a single shared completion path in Learnomy Pro. That path marks the lesson complete the same way a native lesson would, which updates course progress and can trigger a certificate. It won’t complete a lesson twice, and a later “incomplete” signal doesn’t un-complete it.
Because the xAPI module listens for lesson completion, that same event produces one “completed” statement for your LRS. So a SCORM lesson and a native lesson both show up in the LRS as a lesson completed, without anything counting twice. The package doesn’t send xAPI of its own through Learnomy, so there’s no second source.
For a team running mandatory training, that gives you the SCORM tracking report on the site and a full activity stream in the LRS, from one finish.
A short way to decide
Start from what you have and who’s asking for data.
If you’ve got packages to host, you need SCORM. If someone has an LRS waiting, you need xAPI. If you have neither, build lessons natively and revisit it when a client asks.
Both are Pro extensions, so check the Free vs Pro page before you plan around them.