Contact Us Support Forum Get Email Updates

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Tin Can questions:


Developer Overview

Getting started with Tin Can is quite simple, and many developers comment on how easy Tin Can is to work with compared to other learning specifications. There’s a lot of detail you can get into though, and this section of the site takes you through that detail step by step.

Commonly asked questions for developers starting out

Here’s some of the questions developers first starting out with Tin Can often ask (and the answers):

Tin Can Statements

You’ve been introduced to statements in the answers to the questions above. They’re the bread and butter of Tin Can and dictate the format for the specific moments in a stream of activity. As a developer working with Tin Can, you’ll get very familiar with statements.

We’ve produced the following resources to help you get there.

  • Statements 101 takes you through the basics of statements that you need to know in order to get going with Tin Can.
  • Statement Explorer is an interactive example statement that explains the high level structure of the statement.
  • Tin Can Lab is a tool that supports you to build your a statement and send it to an LRS.
  • Statements Deep Dive takes you beyond the basics to help you get the most out of Tin Can.


Tin Can also enables the storage and retrieval of Documents. Documents can be anything from a video recording of the experience, to a JSON document containing bookmarking data. Read more here:


Tin Can defines a query API that’s used to get statements out of a Learning Record Store (LRS). This API is primarily designed for transfer of statements between LRSs, though it can be used for simple reporting. It’s envisaged that for more complex queries and reporting, systems will fetch all relevant statements from the LRS and then store and aggregate them in an appropriate format for reporting. Explore reporting more here.


For learning experiences to be tracked against a learner to that learner’s LRS, the activity provider providing that experience needs to know who the learner is and what LRS to send the data to. There are three ways it can get that information:

  • The learner logs into the activity provider; LRS details are configured within the activity provider.
  • The learner is logged on by single sign on. LRS details may be passed as part of this process or configured within the activity provider.
  • The activity provider is a piece of content that is launched; learner and LRS details are sent by the launching system to the activity provider with the learner.

User authentication and single sign on are concepts that are not exclusive to Tin Can, and you’ll find plenty of information on the internet. We won’t say any more about them here. The launch model is the least modern and least secure, but it’s similar to SCORM which many learning technologists are used to. Read about how to launch Tin Can content here.


The systems, platforms and tools that make up a Tin Can powered learning ecosystem are different from those used with previous learning interoperability specifications. We covered the Enterprise Learning Ecosystem as part of the Understand section of the site. If you’ve not dug into that section yet, you should!

SCORM to Tin Can

Many developers are coming to Tin Can from SCORM. If you’ve got existing SCORM content or templates, take some time to explore three different approaches to migrating existing SCORM content to Tin Can.

As you start to develop with Tin Can, you’ll see that there are a number of technical differences between SCORM and Tin Can. These are outlined below.

Used to track an particular style of e-learning course uploaded to an LMS. Used to track any learning experience, many of which happen outside the LMS.
Includes run time communication, content aggregation and sequencing and navigation. Only covers communication. Content aggregation is less important in the modern connected world; sequencing and navigation are left to the content to manage and do not need to be standardized.
Uses a JavaScript API with either frames or pop-ups. Uses RESTful HTTP requests.
Limited to JavaScript based content. Can be used with any programming language.
Strict definition of data that’s communicated with restrictive limits on length. Very flexible with fewer limitations.

Read more about the differences between SCORM and Tin Can.


Got questions about any of the concepts covered on this page? You can ask us anything!

Contact us

Tin Can API Email Updates

* indicates required

Tin Can API Email Updates

Thanks for signing up for the Tin Can API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Tin Can API.