xAPI hosting, explained without jargon.

A nurse-onboarding client emailed me last spring with a screenshot and three words: "it doesn't work."The Captivate course played fine on her laptop. She uploaded it to the hospital's intranet, learners clicked through it, and the completion report came back empty. Every nurse showed zero progress. The course wasn't broken — it was talking to a Learning Record Store that, as far as the hospital's network was concerned, didn't exist.

If you're moving from SCORM to xAPI, this is the wall you hit. SCORM hid the plumbing inside the LMS, so you never had to think about where the data went. xAPI hands you the plumbing — and an empty completion report is what it looks like when one pipe isn't connected. So let's connect it, with no jargon and no LMS-vendor sales deck.

xAPI doesn't store data in the course. It mails it to an address. If the address is wrong, the mail just vanishes.— what every empty completion report is really saying

What an LRS actually does.

Strip away the acronyms and xAPI is one idea: your course sends short sentences about what a learner did to a database that knows how to store them. Each sentence is a statement, and it's shaped like actor + verb + object— "Devon completed Module 3," "Priya scored 88 on the triage quiz," "Sam launched the fire-safety sim." The database that receives and stores those statements is the LRS (Learning Record Store).

That's the whole model. The course is the sender. The LRS is the mailbox. xAPI (often still called "Tin Can") is just the agreed format of the envelope so any sender can talk to any mailbox. Where SCORM trapped completion and score inside a single course session and handed it to the LMS at the end, xAPI fires statements the moment things happen and ships them somewhere they can outlive the session entirely.

Why anyone bothers: an LRS can record things SCORM physically cannot. Activity that happens outsidea formal course — a simulation, a coaching session, a job aid someone opened on the floor. Offline learning that syncs later. And it lets you query the data back out with real filters instead of staring at an LMS's fixed completion column.

Why self-hosting bites you.

Here's the trap that produced my nurse client's empty report. An xAPI package is just static files — HTML, JavaScript, media. So it's tempting to think "I'll drop it on my own web server and I'm done." You can absolutely host the filesanywhere. But the files aren't the hard part. The mailbox is.

When you publish from Storyline, Rise, or Captivate, the authoring tool bakes three things into the package: the LRS endpoint (a URL), a username and password(Basic auth credentials), and the activity ID. Move the files to a new server and those baked-in values don't change — they still point at whatever LRS you typed into the publish dialog. If that was a test endpoint, a trial that expired, or a placeholder, every statement gets mailed into the void.

And even when the endpoint is right, the browser will often refuse to deliver the mail. The page serving your course lives on one domain; the LRS lives on another. That's a cross-origin request, and unless the LRS explicitly whitelists the course's domain via CORS, the browser blocks the POST before it leaves the building. The course runs. Nothing records. No error a learner would ever see.

// POSTed to <LRS endpoint>/statements with Basic auth.
// This is what "Devon completed Module 3" looks like on the wire.
{
  "actor": { "mbox": "mailto:devon@example.org" },
  "verb": { "id": "http://adlnet.gov/expapi/verbs/completed" },
  "object": { "id": "https://courses.example.org/onboarding/module-3" }
}

Where to put your LRS, ranked.

You don't build an LRS — you point your course at one. Here are the four real places to get one, ranked by how fast a freelance ID gets to a working pipeline that survives a client's network.

The gotchas no one mentions.

Even with a real LRS wired up, three things will quietly eat your statements. Here they are in order of how often I've had to debug them.

1. Stale endpoint and credentials baked in at publish.

Storyline and Captivate write the LRS endpoint and Basic-auth credentials intothe published package. Re-host the files and those values come along unchanged. If you switched LRS providers, or the credentials rotated, the course keeps mailing to the old address. Always re-publish (or re-enter endpoint and credentials) when the destination LRS changes — don't just copy last quarter's files.

2. CORS — the cross-origin block.

If the course is served from courses.example.org and the LRS lives on lrs.vendor.com, the browser treats the statement POSTas cross-origin and blocks it unless the LRS explicitly allows that domain. It's the single most common reason a self-hosted xAPI course records nothing. The fix is on the LRS side: whitelist the domain serving the course. Hosting both behind one platform sidesteps it entirely.

3. The actor identity mismatch.

xAPI identifies a learner by an actor — usually an email (mbox) or an account on a system. If your launch flow doesn't pass a stable identifier, every learner can come through as the same anonymous actor, or as a brand-new one each session. The statements arrive; they just can't be tied to a person. Decide how learners are identified before launch, not after the report looks scrambled.

TL;DR — the cheapest working path.

If you're a freelance ID who needs it working this week: use a host with the LRS built in. One upload, one domain, no CORS, a real endpoint handed to you. Free tiers cover a full proof-of-concept. This is the cheapest path to a pipeline that actually records.

If the whole point is analytics: a managed LRS like Watershed — just remember you still own the course-host-to-LRS CORS config.

If running servers is your idea of fun: Learning Locker on your own box. Budget a weekend and get the CORS and auth right.

If your client is SCORM-only:don't do any of this. Publish SCORM, skip the LRS, and read where to host a SCORM fileinstead. xAPI earns its complexity only when you need data the SCORM envelope can't carry — and if WordPress is the destination, the embed-in-WordPress walkthrough applies the same host-then-link logic.

Frequently asked questions.