The short answer
Strictly, no. The xAPI specification defines statements, the learning record store and its HTTP API; it defines no package format, no manifest and no launch method. What tools export as an "xAPI package" is a zip of the content plus a tincan.xml launch descriptor — a Tin Can era convention many LMSs support, but the specification never mentions.
That distinction sounds academic until an LMS rejects the zip, or imports it and never receives a statement. Both failures come from treating a convention as if it were a standard. The rest of this article explains what the convention is, what an LMS actually does with it, and why cmi5 exists.
What xAPI does and does not define
xAPI is a specification about data in transit. It says what a statement looks like (an actor, a verb, an object, and optional result and context), how statements are sent and retrieved over HTTP, and what a learning record store must do to be conformant: accept statements, validate them, store them, and return them on query. It also defines the State, Agent Profile and Activity Profile resources for storing arbitrary documents against a learner or activity.
It is silent on everything upstream of that first HTTP request. In particular, xAPI does not say:
- how content is bundled or delivered — there is no zip, no manifest, no required file at the root;
- how content is launched, or how it is told which LRS to talk to and who the learner is;
- which statements content must send, in what order, to count as started, completed or passed;
- what an LMS should do with any of the above.
Compare SCORM, where imsmanifest.xml, the API object and the cmi.* data model are all part of the same specification. xAPI deliberately dropped that layer so the same statement format could come from a simulator, a mobile app or a web page that is never imported anywhere. The consequence is that "an xAPI package" has no definition to point at, and two tools can both say "xAPI export" and mean different things.
What is inside a tincan.xml zip?
Open an "xAPI package" or "Tin Can package" from most authoring tools and you will find ordinary HTML5 content plus one small file at the root: tincan.xml. It is a launch descriptor, not a manifest in the SCORM sense. It does not list resources or define a course structure; it tells an importing system what the activity is called and which file to open.
<?xml version="1.0" encoding="utf-8"?>
<tincan xmlns="http://projecttincan.com/tincan.xsd">
<activities>
<activity id="https://example.org/courses/fire-safety/v3"
type="http://adlnet.gov/expapi/activities/course">
<name>Fire Safety Essentials</name>
<description lang="en-US">Annual fire safety refresher.</description>
<launch lang="en-US">index.html</launch>
</activity>
</activities>
</tincan>
Four things matter in that file. The activity id is the IRI every statement from the content will use as its object, so the LMS can match incoming statements to the imported course. The type tells reporting tools what kind of thing it is. The name and description populate the catalogue entry. The launch element names the file the LMS opens. Nothing else in the zip is interpreted; the content is served as static files exactly as a SCORM package's content is.
tincan.xml format and its namespace come from the Tin Can API project that preceded the xAPI 1.0 release in 2013. It was carried forward as a de-facto convention because tools and LMSs had already implemented it, but it has never been adopted into the specification, and a conformant LRS has no idea it exists. An LMS that does not recognise it is not out of compliance with anything.How an LMS launches it
An LMS that supports the convention imports the zip, reads tincan.xml, stores the activity id, and shows the course in its catalogue. When a learner launches it, the LMS opens the launch file with a set of query-string parameters appended, following the launch guidelines that came out of the same Tin Can project:
https://lms.example.org/content/fire-safety/index.html ?endpoint=https%3A%2F%2Flms.example.org%2Flrs%2F &auth=Basic%20dXNlcjpwYXNz &actor=%7B%22mbox%22%3A%22mailto%3Adana%40example.org%22%2C%22name%22%3A%22Dana%20Whitfield%22%7D &activity_id=https%3A%2F%2Fexample.org%2Fcourses%2Ffire-safety%2Fv3 ®istration=3b1f8c6e-5a2d-4f0b-9c7e-1d2e3f4a5b6c
Those parameters are the entire handshake. endpoint is the LRS base URL the content should POST statements to. auth is the Authorization header value to use, usually HTTP Basic credentials scoped to that learner and session. actor is a JSON agent object identifying the learner. activity_id repeats the id from tincan.xml so the content uses the same object IRI the LMS is tracking. registration is a UUID the LMS mints for this enrolment, so that attempts can be told apart.
The content's JavaScript reads these from window.location, builds statements, and sends them straight to the endpoint. There is no API object to discover, no Initialize and no Commit: every statement is its own HTTP request. The LMS learns what happened by querying its LRS for statements with that registration and activity id, and decides for itself what "completed" means — typically by looking for a completed or passed verb against the course activity. Because nothing in the convention requires the content to send those verbs, a course can run perfectly, log hundreds of statements, and still show as not started.
Because this is a convention rather than a requirement, support varies. Some LMSs import the zip and launch it as above. Some will not import a zip at all but let you register a launch URL and will append the same parameters to it. Some accept neither and only expose an LRS endpoint for content hosted elsewhere. The checks in Does my LMS support xAPI? are the way to find out which you have before you build.
cmi5: the package xAPI was missing
cmi5 is ADL's answer to exactly this gap. It is an xAPI profile that standardises the three things tincan.xml only approximates: a package, a launch handshake and a required set of statements.
| Concern | tincan.xml convention | cmi5 |
|---|---|---|
| Descriptor file | tincan.xml — activity id, name, launch file | cmi5.xml — course structure with blocks and assignable units, launch URL per AU, moveOn criteria, mastery score |
| Launch parameters | endpoint, auth, actor, activity_id, registration | endpoint, fetch, actor, registration, activityId |
| Credentials | Passed in the URL | Content POSTs to the fetch URL once to obtain a token |
| Required statements | None | launched and initialized by the LMS and content, terminated at exit, and completed, passed or failed as the moveOn rule requires |
| Who defines "done" | Each LMS, its own way | The specification |
| Status | De-facto, never standardised | Published ADL specification (2016), maintained |
The practical effect is that a cmi5 package behaves like a SCORM package from the LMS's point of view: import it, launch it, and completion appears in the gradebook without anyone agreeing on verbs by email. Underneath, every record is still an xAPI statement in an LRS, so nothing about the data is lost. If you are choosing an export today and the destination LMS lists cmi5, it is the better choice; What is cmi5? walks through the structure file and the launch sequence, and cmi5 vs xAPI sets out when plain xAPI is still the right call.
Three meanings of 'supports xAPI'
When a platform says it supports xAPI, it may mean any of three different things, and the difference decides whether your zip will work.
- It has an LRS. The platform can receive and store statements. That says nothing about importing content: you would host the course elsewhere, point it at the endpoint with credentials, and the LMS may or may not surface the results in its own reports.
- It accepts tincan.xml zips. The platform imports the convention described above, launches with the five query parameters, and decides completion by its own rule. Most "xAPI export" packages from authoring tools target this.
- It supports cmi5. The platform reads
cmi5.xml, runs the fetch handshake, and reports completion according to the specification. Atincan.xmlzip will usually not import here unless the platform also supports meaning two.
Ask which one before exporting, and if the answer is vague, test with a one-page package whose only job is to send one completed statement and check that the LMS shows it. A platform in category one will show nothing; a platform in category two will show whatever its rule derives; a platform in category three will reject the zip and ask for cmi5. Each of those is a useful answer, and each takes less time to get than a support ticket after launch day.
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.