Get xAPI, Or Not?

There’s been a lot of talk and some confusion about the Experience API, xAPI, and the Tin Can API – and how any or all of them are going to radically alter the eLearning process. Let’s take a closer look, and try to clarify things a little.

What’s API Stand For?

API is a term used by software engineers and developers. It stands for Application Programming Interface, which is a library of functions or things that a computer program can do.

By using an API, developers can create separate software programs (also known as applications) that are able to work together, since they share some common functions.

The Need for Standards

In 1999, U.S. President Bill Clinton – recognising the need for the Department of Defence and other federal agencies to have greater access to technology-based learning resources – launched the Advanced Distributed Learning or ADL Initiative.

As an organisation, ADL has set out a vision of the way ahead for learning technology, which it calls the Training and Learning Architecture (TLA). The architecture will focus on tracking learning experiences, setting terms and conditions for educational content, and putting infrastructure in place to monitor competency and learner profiles.

The TLA is looking to set up a standard framework to describe experiences, content, participants, and learning goals, so that Learning Management Systems (LMS) can deliver eLearning environments that are more engaging and adaptable for individual users.

SCORM Has Passed

ADL was empowered as a standards-making body, and one of its first acts was to establish the Shareable Content Object Reference Model, or SCORM. This set up a framework for software developers to write eLearning programs that could integrate well with each other.

SCORM was dedicated to the production of online training resources and tools that could be shared between different systems. SCORM tracks specific elements like test results, which lesson pages have been viewed, and which modules have been completed. It’s also based on JavaScript, a programming language that makes it hard to extend SCORM to mobile applications.

As time went on, it became apparent that a higher standard for interaction between eLearning programs was required.

Tin Can or xAPI?

In 2011, the contract to develop such a standard was awarded to Rustici Software. During its early days, the project was dubbed the Tin Can API – a reference to the children’s game where a couple of tin cans are tied together with a string, and used like a simple walkie-talkie. This image appealed to software designers and other IT professionals, whose focus was on how the various learning programs could be made to communicate with each other.

The standard was officially released on April 26, 2013, under the name Experience API or xAPI. This name change (it’s the same product, really) reflects the focus adopted by the eLearning mindset – that of the experience of learners during training, and of instructors and facilitators making the modules work.

xAPI isn’t limited to eLearning courses or LMS; any software which stores and reports on learning data (and is in compliance with the standard) can generate information for the Experience API.

Tracking the Experience

Sounds great, but what does it do? Well, with xAPI you can track just about any activity that people do with computers and related technology. Working practices, output, milestones achieved in games or simulations, interactions on social media, etc.

eLearning courses, and Learning Management Systems can connect with xAPI-compliant web resources, document and collaboration management platforms, help desks, knowledge bases, performance management systems, and so on.

xAPI uses what it calls “statements”, to describe learning activities. Each statement consists of an actor (person), an action (what they did), and an object (what was acted on).

When a learner performs an action as defined under xAPI, this completes a learning “experience”, which is sent on to a Learning Record Store or LRS.


The LRS is a database for storing each learner’s activity statements under xAPI. It may be an independent application, or a built-in part of your LMS.

A standalone LRS can track and report activities under the Experience API, but it won’t be able to do things like provide certificates, schedule training sessions, manage instructors, and allocate resources like a full-blown LMS.

Content published for xAPI can be launched from a standard Web server, while reporting back to an LRS. The same content can be run directly from an LMS, which will provide all the necessary information on the launch URL.

A Question of Application

xAPI’s aim is to store and give access to learning experiences – be they test results, simulations, mobile, informal learning, or real-world performance issues.

By analysing data from xAPI, you can determine which course modules are producing the desired results, and which training methods are working most effectively.

The Experience API is a step up from the traditional workplace LMS, which has been limited in its ability to manage learning activities that occur through professional networking, knowledge sharing, and mentoring.

xAPI has much to offer, and a reassessment of the role of “informal” learning channels, coupled with some disciplined application of established learning practices, should see a shift in work practices and the design of instructional materials in the future.

Some Resources

These standalone LRS tools are available on the web to try for free:

  • Saltbox WaxLRS allows for the reporting of xAPI statements. It’s a disconnected LRS, and doesn’t host any of its own content.
  • SCORM Cloud by Rustici Software (the developers of xAPI, itself) allows the hosting and tracking of AICC, SCORM and xAPI content. Disconnected content can report directly to its LRS.

Tags: , , ,