Tin Can API vs xAPI: are they the same?

The short answer

Tin Can API and xAPI are the same specification. "Tin Can" was the working name of the research project that produced SCORM's successor; the finished specification was named the Experience API, or xAPI, when version 1.0 was released in 2013. There is no technical difference between a Tin Can statement and an xAPI statement.

That is the whole answer, and if you are choosing between an "xAPI" option and a "Tin Can API" option in an authoring tool or an LMS, you are not choosing between two standards. You are choosing between two labels for the same thing, and the rest of this article explains why the second label exists and where it still turns up.

Why is xAPI called Tin Can?

SCORM's limits were well understood by the late 2000s: it only works inside an LMS, it only reports a handful of values, and it has no idea what a learner did outside the browser frame. ADL, the US Department of Defense initiative that publishes SCORM, funded a research project to define what should come next. The contract was awarded to Rustici Software, and the project ran through 2011 and 2012 under the name Project Tin Can.

The name was deliberately informal. A tin-can telephone is two cans and a piece of string: a simple way for two things to talk to each other. That was the design goal — a lightweight way for any activity (a web page, a mobile app, a simulator, a classroom session) to report what happened to a central store, without the LMS sitting in the middle.

The research produced a draft specification, and early implementations shipped against it under the Tin Can name. When ADL published the finished 1.0 specification, it was called the Experience API, because the thing it tracks is learning experiences, not tin cans. ADL's name is the official one. Rustici kept using "Tin Can" as a brand for its own products and documentation for some years afterwards, which is the main reason the term spread as far as it did. Read What is xAPI? for what the specification actually defines.

What changed between Tin Can and xAPI 1.0?

The data model did not change in kind. From the first drafts to 1.0, the unit of data has been a statement — a JSON object that says an actor did a verb to an object — sent over HTTP to a Learning Record Store. What changed was the detail, and the detail matters if you ever meet a statement produced by very early content.

• Verbs became identifiers. In the 0.9 draft, a verb was a plain string such as "completed". From 0.95 onwards a verb is an object whose id is an IRI, for example http://adlnet.gov/expapi/verbs/completed, with an optional human-readable display map. This is what lets two systems agree that they mean the same verb.
• Version negotiation was formalised. Every request to an LRS carries an X-Experience-API-Version header. An LRS can accept statements for the versions it supports and reject the rest, which is how 0.9, 0.95 and 1.0 content coexisted during the transition.
• Behaviour was pinned down. 1.0 specified what an LRS must do with voided statements, attachments, the State, Agent Profile and Activity Profile resources, and how it must validate what it receives. Drafts described many of these loosely; 1.0 made them conformance requirements.

After 1.0.0 in 2013 came the 1.0.x maintenance releases, which clarified wording without changing the format. A statement that was valid in 1.0.0 is valid in 1.0.3. Later still, IEEE standardised xAPI as a formal standard, which is where the "2.0" label comes from; the core shape of a statement is unchanged there too. The anatomy of a statement — actor, verb, object, result, context — is covered field by field in xAPI statement structure.

Where you still see Tin Can

The name lingers in three places, and each one means something slightly different.

Authoring tool export options. Some tools have offered a "Tin Can API" publish target since 2012 and have been slow to rename it, or kept the old label alongside the new one so existing users can find it. Whether a given tool still does this changes with each release, so check the current version rather than trusting a screenshot. Where the option exists, it produces an xAPI package.

The tincan.xml file. xAPI itself defines no package format — there is no manifest, no zip, and no launch procedure in the specification. That is a gap when you want an LMS to launch xAPI content the way it launches a SCORM course. Rustici's answer was a small descriptor file called tincan.xml placed at the root of a zip. It declares one or more activities, each with an activity id (the IRI the content will use as the object of its statements), a name and description, and a launch element pointing at the HTML file to open:

<tincan xmlns="http://projecttincan.com/tincan.xsd">
  <activities>
    <activity id="https://example.org/courses/fire-safety" type="http://adlnet.gov/expapi/activities/course">
      <name>Fire Safety Induction</name>
      <description lang="en-US">Annual fire safety refresher.</description>
      <launch lang="en-US">index.html</launch>
    </activity>
  </activities>
</tincan>

When the LMS opens the launch file it appends query parameters — the LRS endpoint, an auth token, the actor as JSON, the activity_id, and a registration — so the content knows where to send statements and who the learner is. This convention is not part of the xAPI specification, but it was widely adopted, and many platforms that say they "support Tin Can" mean exactly this: they can read tincan.xml and perform that launch. cmi5 was later written to standardise the same job properly.

Older documentation and forum answers. A great deal of what was written about xAPI between 2012 and 2015 uses the Tin Can name. It is still mostly accurate; just mentally substitute xAPI 1.0.

Whatever the label on the launch side, the statements end up in the same place. What is an LRS? explains what the store does with them and how it differs from an LMS.

Which name should you use?

Use xAPI. It is the name in the specification, the name ADL and IEEE use, and the name that search results, LRS vendors and conformance tests use. "Tin Can" is still understood, but it dates the speaker, and it can cause genuine confusion when a buyer assumes it is a separate, competing standard that their LMS lacks.

A few practical rules when you meet the old name:

1. If a tool offers both "xAPI" and "Tin Can API", they usually produce the same output. Pick xAPI and verify the version header in the first request the content makes.
2. If an LMS lists "Tin Can" among its supported formats, expect tincan.xml launch of xAPI 1.0.x content. Test with a small package before promising anything.
3. If you need an LMS to launch, track and roll up xAPI content without relying on a vendor convention, look at cmi5, which defines the package, the launch and the required statements.
4. If you are writing documentation or a procurement requirement today, write xAPI and state the version you require.

The name is history. The statements, the LRS and the launch convention are what you will actually be working with, and none of them care what the project was called.

Where SCORM Central fits

SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.