The Experience API, formerly referred to as the Tin Can API, is an application programming interface (API) specification for the interoperability of data produced by technology. The Experience API is considered the next generation of SCORM. These specifications, or standards, are what define how formal and informal learning activities are tracked and measured by Learning Record Stores, or LMSs.


The Experience API is a result of a Broad Agency Announcement (BAA) from the Advanced Distributed Learning Initiative (ADL), a branch of the US Department of Defense. The BAA requested research and development of an API that would make data about learning experiences interoperable. Rustici Software won this BAA, and in 2011 worked on “Project Tin Can” which was eventually opened up to community development in 2012.

The Experience API was born from the Activity Streams specification, which is an open source effort for collecting activity statements in social networks. The Experience API is somewhat differentiated in that it has select features that enable more interoperability with existing learning technology specifications, like the Sharable Content Object Reference Model (SCORM). While the Experience API doesn’t replace SCORM, it offers a way for SCORM content, and many other types of content and activity providers, to communicate in the same way. It also enables organizations to see the larger collection of activity from all these tools.


Training organizations have a fundamental need to track learning activities. Formal training activities, such as classroom training, are generally easy to track, although it requires a manual step by a training administrator to input information about attendance and participation. E-learning activities have become easier to track with the creation of SCORM standards, but do require an e-learning course creator to comply with SCORM, and to make sure the LMS complies as well.

With growth in technologies such as Learning PortalsPersonal Learning Environments and search engines, training organizations need to track the amount of informal learning that is occurring to better understand the needs of the learner. In addition, activity providers (such as mobile applications providers, gamification and simulation developers, virtual worlds, and many other systems application providers) want to understand how much learning is occurring within their systems.  All the constituents of learning, training organizations as well as systems and training service providers, long for training activities and LMSs to communicate in a consistent way.


The Experience API specification is driven by the ADL. The Experience APIs refer to a shared language for systems to communicate data about a person or a group’s formal and informal learning activities. The specification requires a Learning Record Store (LRS) to receive and distribute these statements.

All statements are in the format of: Actor: Verb: Object

Since the structure of the Experience API is open, statements don’t have to be strictly about learning experiences; they may be about any type of activity in any system. With this type of data, learning activities can be tied to performance, indicating the real business value of learning or training initiatives.


As part of the Experience API (Tin Can) specification, a Learning Record Store (LRS) collects activity statements. An LRS must accept any properly formatted data and share it with other LRSs upon proper request and authentication.

An LRS is defined as part of the Experience API specification. Most of the hard logic for dealing with the data is put in the LRS instead of in the tools making the activity statements. This makes the LRS more complex to build out than a typical database because it has to accept all the data that is received as part of a statement.


In November 2012, ADL and the AICC (Aviation Industry Computer Based Training Committee) agreed to collaborate on the development of the Experience API. This was an important milestone, because since their inception, SCORM and AICC have been considered complementary but different sets of standards for e-learning content.

Contributor(s): Megan Bowe

Related Content on