Update: The Output of Project Tin Can is Experience API.

next generation scorm evolution project tin can

Ready to really dive in?
View the full
Tin Can API spec.

View the Tin Can API
“quick start” guide.

Better Interoperability

The heart of e-learning specifications is interoperability. We all think that we’re perfect, but we’ve found some room for improvement. The Tin Can API looks to solve many of the remaining interoperability issues that linger with the current specs, but we’ll need your help to find the pitfalls.

User Interface Issues

LMSs all have their own user interfaces. When trying to create content that is compatible with as many LMSs as possible, it’s not always possible to take into account every variation of user interfaces that LMSs might have. The Tin Can API puts the user interface in the hands of the content/activity. This way, content/activity creators can be assured that their content will be experienced as intended.

Submitting Content

In the Tin Can API, to a learner, “submit” means “I’m done, I’m ready to turn this in, I’m ready to be evaluated.”

SCORM doesn’t offer a usable concept of “submitted” or “not submitted” (and suspending doesn’t cut it.) Using SCORM, content has to suspend itself to avoid data loss, but when content has been completed and suspended, the LMS assumes that the content is ready to be evaluated. What if a learner wants to come back and review their completed content without the LMS assuming that it’s ready to be evaluated?

The Tin Can API removes all assumptions that an LMS might make in the area of completion/submission.

This problem is solved by bringing in the concept of “submitted” or “not submitted.” This allows the LMS to know if a learner has completed the content and is ready to submit it, or if they’ve completed the content and want to come back and review it before submitting for evaluation.


With SCORM, sequencing is difficult to do and easy to be messed up by LMSs. The Tin Can API removes sequencing from the LMS altogether. There are no more interoperability issues with LMSs not handling sequencing the correct way. The content/activity lives on its own. If it works for the content creator, it should work for everyone else.

API Simplicity

In general, the Tin Can API reduces areas of confusion. There’s much less room for guessing. The LRS doesn’t have to guess about anything or assume anything. Everything is just spelled out, the way it should be.

A weakness of the Tin Can API in this area is verb variation, but we think we have a good solution planned for it. Another weakness is the increased burden on the LRS to identify users that have been reported differently but who are really the same user. This is related to the “activity definitions agreement” issue, where we also have proposed solutions.

SCORM 2.0 next generation project tin can

Your thoughts on better interoperability? Did we miss something? Are you particularly happy about one aspect of it? Talk to us in the comments below.

SCORM 2.0 next generation project tin can

Did we achieve what you wanted with this feature?