xAPI (Tin Can API)

xAPI — formally called the Experience API, and sometimes referred to by its development codename "Tin Can API" — is an e-learning technical standard developed by Rustici Software under contract from the US Department of Defense's Advanced Distributed Learning (ADL) initiative. Published in 2013, xAPI was designed to address the fundamental limitations of SCORM that had accumulated over more than a decade: browser dependency, synchronous communication, completion-centric data, and the inability to track learning that happens outside an LMS-delivered course.

The central innovation is the statement structure: any learning activity is expressed as a subject-verb-object sentence, stored in a Learning Record Store (LRS) rather than in an LMS. "Alice completed Introduction to Safety" and "Bob scored 85% on the Objection Handling Assessment" are SCORM-compatible. "Charlie practiced the welding procedure on the simulation for 23 minutes," "Dana watched the product demo video on her phone during her commute," and "Evan received a 4/5 peer rating on his presentation" are not — but all of them are valid xAPI statements.

#The statement structure

An xAPI statement has three required components:

Actor: The person (or system) performing the activity. Typically identified by name and email address, or by a unique identifier from an HR system.

Verb: What the actor did, expressed as a URI pointing to a defined verb from a vocabulary (for example, http://adlnet.gov/expapi/verbs/completed for "completed", or http://adlnet.gov/expapi/verbs/scored for "scored"). Using standard vocabulary URIs ensures that statements from different sources can be compared and aggregated meaningfully.

Object: What the actor acted upon — a course, a video, a simulation, a physical object tracked by a sensor, a URL, or any other defined learning resource.

Beyond these three required fields, statements support a rich set of optional extensions: context (the learning activity's relationship to other activities, the platform it occurred on, the instructor present), result (score, completion, success, duration), and arbitrary extensions for domain-specific data.

#How xAPI differs from SCORM

The architectural differences are significant:

Storage: SCORM data lives in the LMS. xAPI data lives in a Learning Record Store (LRS), which can be a standalone system, integrated into an LMS, or a third-party service. The LRS is the system of record; the LMS becomes one consumer of that data among potentially many.

Communication: SCORM requires an active browser session and a live connection to the LMS. xAPI statements can be sent asynchronously, queued offline and synced when connectivity is restored, and generated by any system — not just browser-based courses.

Data richness: SCORM tracks completion, score, and time. xAPI can track any activity, with any data attached to it, as long as someone defines the statement structure. The limitation is design, not the standard itself.

Platform independence: A SCORM course runs in a browser within an LMS. An xAPI statement can be generated by a mobile app, a physical sensor, a game engine, a CRM system, a manager's performance review form, or any other system that can make an HTTP call.

#Adoption challenges

Despite its technical advantages, xAPI adoption has been slower than anticipated for several reasons:

LRS requirement: To receive and store xAPI statements, you need an LRS — either as a standalone product (Learning Locker, SCORM Cloud's LRS, Watershed) or as a module within a modern LMS. Many organizations already have an LMS but not an LRS, and the additional infrastructure represents cost and complexity.

Authoring tool support: SCORM export is a standard feature in virtually every authoring tool. Full xAPI support — including custom statement definitions, context extensions, and agent profile support — is less consistently implemented. Many tools export basic xAPI statements, but leveraging the standard's full capability requires more deliberate configuration.

Analytics gap: xAPI generates richer data, but that data has value only if someone can analyze it and act on it. Many organizations lack the analytics infrastructure or the data literacy to derive insight from xAPI logs. Richer data without better decisions is sunk cost.

#Real use cases where xAPI delivers genuine value

Simulation tracking: A medical procedure simulation, a customer conversation roleplay, or a technical troubleshooting scenario can generate detailed behavioral data — which decision paths learners took, where they hesitated, how many attempts they needed — that SCORM's completion/score model cannot capture. xAPI makes this data portable and aggregatable.

Blended learning programs: In a program that combines e-learning, virtual instructor-led sessions, physical workshops, and on-the-job practice activities, xAPI provides a single data layer for tracking progress across all formats. Without it, each modality's data lives in a separate silo.

Performance support tracking: If employees use a job aid, reference document, or embedded help system, xAPI can record those interactions — enabling analysis of whether performance support is actually being used and whether usage correlates with performance outcomes.

Informal and social learning: Activity in enterprise social tools, peer ratings, completions in consumer learning apps — any of these can be captured as xAPI statements if the systems support it, building a richer picture of where learning actually happens in an organization.