xAPI vs SCORM: what freelancers actually need to know.

A prospect reads "xAPI" on a competitor's site and forwards you a one-line email: "Should we be using xAPI instead of SCORM?" The honest answer is almost never the exciting one. It depends on their LMS, their IT change queue, and whether anyone on their side will own a Learning Record Store after you hand off. But that is not the answer that wins the gig — and it is definitely not the answer most freelance IDs give. They either reach for the newer-sounding acronym to look sharp, or freeze up in a standards rabbit hole the client never asked them to enter.

Here is the version I wish someone had handed me: SCORM and xAPI are not a fashion contest. They are two answers to two different questions, and the client is really asking a third one — who maintains this, and who owns the data? Get that straight and the recommendation writes itself.

SCORM tells you whether they finished. xAPI tells you what they did. Pick the one the client can actually maintain.— the whole comparison in one line

Why SCORM is still the default.

For most corporate work, a SCORM 1.2 or 2004 package is the currency. LMS admins already know how to ingest it, completion and score reporting are well understood, and it ships without new infrastructure. When a client asks "will it track completion?" and you can say "yes — SCORM 1.2, completion fires on a quiz pass," the conversation moves to design instead of infrastructure. That is exactly where you want it.

SCORM 1.2 is the safe bet.

When you don't know the client's platform, publish 1.2. It runs on Cornerstone, Docebo, Moodle, Absorb, TalentLMS, and practically every LMS released this century. The trade-off is thin data: completion status, a single score, and basic bookmarking. For compliance, awareness, and onboarding, that is plenty.

SCORM 2004 is for enforced structure.

Reach for 2004 when the course needssequencing — a certification where Module 2 unlocks only after Module 1 passes — or when the client's reports must distinguish "completed" from "passed" as separate fields. Storyline 360 and Captivate both export 2004 3rd and 4th Edition. Confirm which edition the LMS supports before you publish, because mismatches fail silently in sequencing.

When xAPI earns its complexity.

xAPI (the spec everyone still calls "Tin Can") shines when the learning you need to track lives outsidea single SCORM module. A mobile job aid, a Unity simulation, a video series, an in-person workshop — xAPI stitches those into one learner record. Each piece sends statements ("learner attempted scenario," "learner completed video," "learner attended workshop") to a Learning Record Store like Learning Locker, Watershed, or Yet Analytics, and the LRS becomes the single source of truth you build reports from.

The catch is governance, and it is a real one. Someone has to define the statement vocabulary, provision and maintain the LRS, own the data, and build the reports. If you pitch xAPI without naming those owners in the SOW, the client assumes you handle all of it forever — and you become unpaid infrastructure support. A clean split: you define the statement structure and instrument the authoring side; their IT team provisions and maintains the LRS; a data analyst builds the dashboards.

Start small. Instrument one module with custom statements that track decision points in a branching scenario. If the client's LMS supports it, use cmi5 — it's essentially xAPI with SCORM-like launch and completion semantics, so it feels familiar to LMS admins while giving you richer data underneath. Storyline 360 exports cmi5 natively; for anything beyond it, you're wiring JavaScript triggers that send statements through the xAPI wrapper library.

// One decision point in a branching scenario, sent to the LRS.
// This is the "what they did" SCORM can't capture.
ADL.XAPIWrapper.sendStatement({
  actor: { mbox: "mailto:learner@client.com" },
  verb: { id: "http://adlnet.gov/expapi/verbs/answered" },
  object: {
    id: "https://client.com/scenario/escalation-tier",
    definition: { name: { "en-US": "Chose escalation tier" } }
  }
});

Pick by the client in front of you.

Forget which spec is "more modern." Match the standard to the client's reality — their LMS, their IT capacity, their reporting need. Ranked by how often it's the right call for freelance work:

How to write it into a proposal.

Clients don't buy standards; they buy outcomes and they fear maintenance. So translate. Describe each option in language the client already owns, then make the call for them.

Say it in their words.

For SCORM: "We deliver a packaged module your LMS imports like any other course. It tracks who completed the training and who passed the assessment. Your admin handles upload — no new infrastructure." For xAPI: "We instrument the experience to capture which decisions learners made, where they struggled, and how long they spent practicing, then send that to a dedicated analytics platform. This requires an LRS your IT team provisions and maintains."

Name the maintenance, not just the build.

SCORM is low-maintenance: if the content and the LMS don't change, the package keeps working. xAPI carries ongoing cost — LRS hosting, statement storage that grows over time, dashboard upkeep when reporting needs shift, and someone who understands the data model when stakeholders ask new questions. Surface those upfront or the client discovers them in six months and blames you for the surprise.

End with a recommendation.

After describing both, write one paragraph: "Based on your LMS, your team's capacity, and your reporting needs, I recommend [SCORM / xAPI] because [specific reason]." Clients hire you for judgment, not a menu. Two options with no recommendation asks them to make a technical decision they're not equipped for — and they may pick wrong. Your call, backed by portfolio proof of similar work, is what justifies your rate.

Showing both in a portfolio.

The two standards demand different proof. SCORM is interactive, so let people touch it. xAPI is usually confidential, so sell the design.

For SCORM work, host the packageso reviewers click the real experience — navigation, assessment flow, completion behavior, responsive layout, all in one artifact. Label it with the version and tool: "Branching compliance scenario — Storyline 360, SCORM 2004 4th Edition." That label tells a technical reviewer you made deliberate packaging choices.

For xAPI, you usually can't share live data — so share the architecture. A one-page diagram (authoring tool → LRS → reporting), annotated with your actual verbs and objects ("attempted," "completed," plus extensions like "selected-path" or "time-on-decision") proves you understand the pipeline even when the data is sealed. Then write the case study in plain language first — "68% of learners initially chose the wrong escalation tier, which led us to add a decision-support job aid in v2" — and add the technical layer underneath for the readers who want it.

Frequently asked questions.