Who publishes the xAPI specification?
The xAPI specification is the document that defines the Experience API: the format of a learning statement, and the rules a learning record store follows to receive and return it. ADL publishes it. Version 1.0.3 is free to read on GitHub in three parts, and version 2.0 is an IEEE standard, IEEE 9274.1.1-2023.
ADL is the Advanced Distributed Learning Initiative, the same body that published SCORM. The specification began as a research project called Tin Can, which is why the name "Tin Can API" still turns up in authoring tools and LMS menus. It means the same thing as xAPI. If you want the idea before the detail, start with what xAPI is and come back.
The 1.0.3 text lives in a public repository, adlnet/xAPI-Spec, as plain Markdown files. There is no login and no download form. That matters for a practical reason: when a tool and an LRS disagree about a statement, both sides can open the same paragraph and settle it.
The three parts of xAPI 1.0.3
Version 1.0.3 is not one long document. It is split into three parts, and each one has a different reader in mind.
| Part | Title | What it covers |
|---|---|---|
| Part One | About the Experience API | The overview, how to read the requirement wording, and the definitions of the terms used everywhere else |
| Part Two | Experience API Data | Statements and their properties: actor, verb, object, result, context, timestamps, attachments. Also voiding, signed statements, and data types such as IRIs, language maps and extensions |
| Part Three | Data Processing, Validation, and Security | How an LRS receives and returns data over its REST resources: the requests, the headers, concurrency, error codes, versioning and authentication |
A simple way to hold the split in your head: Part Two describes the thing being sent, and Part Three describes the conversation used to send it. A single request shows both at work.
POST https://lrs.example.com/xapi/statements
Authorization: Basic dXNlcjpwYXNz
X-Experience-API-Version: 1.0.3
Content-Type: application/json
{
"actor": { "mbox": "mailto:learner@example.com" },
"verb": { "id": "http://adlnet.gov/expapi/verbs/completed" },
"object": { "id": "https://example.com/courses/fire-safety" }
}
Everything above the blank line is Part Three territory: the statements resource being posted to, the authentication header, and the version header that every request must carry. Everything inside the braces is Part Two: which properties a statement needs and what each may contain. The address before /statements is chosen by the LRS; the specification only defines what comes after it.
What changed with xAPI 2.0
xAPI 2.0 moved the specification from an ADL document to a formal standard. It was standardised by the IEEE and published as IEEE 9274.1.1-2023.
The core model did not change. A statement is still an actor, a verb and an object, with an optional result and context, and an LRS still receives statements over REST. Someone who understands 1.0.3 can read 2.0 without relearning anything fundamental. The differences are refinements. For example, the context of a statement gained two new properties, contextAgents and contextGroups, for describing the people and groups related to an experience. And requests identify themselves with a 2.0 version number in the version header instead of a 1.0 one.
about resource that returns the list of xAPI versions it supports.In practice, a great deal of content and many record stores still work to 1.0.3, so that is usually the version to read first. If your LRS supports 2.0 and your tools send it, read the 2.0 text for the differences.
Which part answers your question
Most people open the specification with one specific question. This is where to look.
| Your question | Where to look |
|---|---|
| Which properties must a statement have? | Part Two, statement properties |
| How do I identify the learner? | Part Two, the actor |
| How do I format a score or a duration? | Part Two, the result and the data types |
| How do I correct a statement that was wrong? | Part Two, voiding |
| What does an activity ID have to look like? | Part Two, the object and IRIs |
| Which address do I send statements to, and how do I query them back? | Part Three, the statement resource |
| Where does a course keep a bookmark between sessions? | Part Three, the state resource |
| How does a request authenticate? | Part Three, authentication |
| Why did the LRS return an error code? | Part Three, error codes and concurrency |
| What does a term mean, or how strict is a "SHOULD"? | Part One |
If your question is about a field inside a statement, the worked breakdown in xAPI statement structure is a faster first stop than Part Two. If it is about what the receiving end does with a statement once it arrives, see what an LRS is.
Reading the spec without getting lost
Four habits make the specification much easier to use.
- Learn the requirement words first. The specification uses MUST, SHOULD and MAY in capitals with fixed meanings. MUST is a rule: break it and you are not conformant. SHOULD is a strong recommendation that can be set aside for a good reason. MAY is a real option. Part One explains this, and it changes how every later sentence reads.
- Check who each requirement is addressed to. Some rules bind the LRS. Others bind the software that sends statements, which the specification calls a Learning Record Provider, or the software that reads them back, a Learning Record Consumer. A rule written for the LRS is not a rule for your course, and the reverse.
- Use the examples. The appendices to Part Two include complete example statements. Comparing your own statement against one of them often finds a mistake faster than reading the requirement text.
- Search, do not read front to back. The specification is a reference. Search for the property name or the resource you are working with and read that section and the ones it points to.
It also helps to know what the specification leaves out, so that you stop looking for it.
- No package format. xAPI has no zip file and no manifest. There is nothing to import into an LMS the way a SCORM package is imported.
- No launch mechanism. The specification does not say how an LMS starts a piece of content or hands it the LRS address and credentials. cmi5 is a separate specification that adds packaging and launch on top of xAPI.
- No fixed list of verbs. The specification defines how a verb is written and reserves one,
voided, for cancelling a statement. Which verbs you use for everything else is decided by agreement between the people producing and reading the data, not by the specification.
Knowing those three gaps explains most of the confusion people have on a first read. The xAPI specification tells you exactly what a valid statement is and exactly how an LRS must behave. It does not tell you what your statements should mean. That part is a design decision, and it is yours.
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.