ISO/IEC/IEEE 39274-1-1:2025

International
Standard
ISO/IEC/IEEE
39274-1-1
First edition
Learning technology — JavaScript
2025-10
Object Notation (JSON) data model
format and Representational State
Transfer (RESTful) web service for
learner experience data tracking
and access —
Part 1-1:
xAPI using JSON serialization and
RESTful data transport
Technologie de l'apprentissage — Format de modèle de
données JavaScript Object Notation (JSON) et service web
Representational State Transfer (RESTful) pour le suivi des
données de l’expérience de l’apprenant et l'accès à ces données —
Partie 1-1: xAPI utilisant la sérialisation JSON et le transport de
données RESTful
Reference number
© IEEE 2023
© IEEE 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
© IEEE 2023 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO or IEC participate in the development of
International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further
maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different
approval criteria needed for the different types of document should be noted.
(see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE
Standards Association (IEEE SA) Board of Governors. IEEE develops its standards through
an accredited consensus development process, which brings together volunteers
representing varied viewpoints and interests to achieve the final product. IEEE standards
are documents developed by volunteers with scientific, academic, and industry-based
expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the
process and establishes rules to promote fairness in the consensus development process,
IEEE does not independently evaluate, test, or verify the accuracy of any of the information
or the soundness of any judgments contained in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may
involve the use of (a) patent(s). ISO and IEC take no position concerning the evidence,
validity or applicability of any claimed patent rights in respect thereof. As of the date of
publication of this document, ISO and IEC had not received notice of (a) patent(s) which
may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not
be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users
and does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms
and expressions related to conformity assessment, as well as information about ISO's
adherence to the World Trade Organization (WTO) principles in the Technical Barriers to
Trade (TBT), see www.iso.org/iso/foreword.html. In the IEC, see
www.iec.ch/understanding-standards.
ISO/IEC/IEEE 39274-1-1 was prepared by the LAN/MAN of the IEEE Computer Society (as
IEEE Std 9274.1.1™-2023) and drafted in accordance with its editorial rules. It was adopted,
under the “fast-track procedure” defined in the Partner Standards Development
Organization cooperation agreement between ISO and IEEE, by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 36, Information technology for
learning, education and training.
A list of all parts in the ISO/IEC/IEEE 39274 series can be found on the ISO and IEC
websites.
© IEEE 2023 – All rights reserved
iii
Any feedback or questions on this document should be directed to the user’s national
standards body. A complete listing of these bodies can be found at
www.iso.org/members.html and www.iec.ch/national-committees.

© IEEE 2023 – All rights reserved
iv
IEEE Std 9274.1.1™-2023
IEEE Standard for Learning
Technology—JavaScript Object
Notation (JSON) Data Model Format
and Representational State Transfer
(RESTful) Web Service for Learner
Experience Data Tracking and Access
Developed by the
Learning Technology Standards Committee
of the
IEEE Computer Society
Approved 30 March 2023
IEEE SA Standards Board
Abstract: This standard is a collaborative effort to improve and standardize the 1.0.3 version
Experience Application Programming Interface (xAPI) specification. This Standard describes a
JavaScript Object Notation (JSON) data model format and a Representational State Transfer
(RESTful) Web Service Application Programming Interface (API) for communication between
Activities experienced by an individual, group, or other entity and a Learning Record Store (LRS).
The LRS is a system that exposes the RESTful Web Service API for the purpose of tracking and
accessing experiential data, especially in learning and human performance.
Keywords: Experience API, IEEE 9274™, IEEE 9274.1.1™, JavaScript object notation, JSON,
Learning Record Provider, Learning Record Store, LRP, LRS, representational state transfer,
REST, xAPI
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 6 October 2023. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers,
Incorporated.
PDF: ISBN 979-8-8557-0031-2 STD26400
Print: ISBN 979-8-8557-0032-9 STDPD26400
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit https://www.ieee.org/about/corporate/governance/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written
permission of the publisher.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers.
These notices and disclaimers, or a reference to this page (https://standards.ieee.org/ipr/disclaimers.html),
appear in all standards and may be found under the heading “Important Notices and Disclaimers
Concerning IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE
or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
IEEE makes no warranties or representations concerning its standards, and expressly disclaims all
warranties, express or implied, concerning this standard, including but not limited to the warranties of
merchantability, fitness for a particular purpose and non-infringement IEEE Standards documents do not
guarantee safety, security, health, or environmental protection, or guarantee against interference with or
from other devices or networks. In addition, IEEE does not warrant or represent that the use of the material
contained in its standards is free from patent infringement. IEEE Standards documents are supplied “AS
IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related
to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved
and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.

vi
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity, nor is IEEE undertaking to perform any duty owed by
any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon
their own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given
IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: THE
NEED TO PROCURE SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus balloting process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English version published by IEEE is the approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, nor be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that the presenter’s views should be considered the personal views of that individual rather
than the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group. Statements
made by volunteers may not represent the formal position of their employer(s) or affiliation(s).
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations,
consulting information, or advice pertaining to IEEE Standards documents.
Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important that any responses to comments and questions also receive the concurrence of a balance of
interests. For this reason, IEEE and the members of its Societies and subcommittees of the IEEE SA Board
of Governors are not able to provide an instant response to comments, or questions except in those cases
where the matter has previously been addressed. For the same reason, IEEE does not respond to
interpretation requests. Any person who would like to participate in evaluating comments or in revisions to
an IEEE standard is welcome to join the relevant IEEE working group. You can indicate interest in a
working group using the Interests tab in the Manage Profile & Interests area of the IEEE SA myProject
system. An IEEE Account is needed to access the application.
Comments on standards should be submitted using the Contact Us form.

Available at: https://development.standards.ieee.org/myproject-web/public/view.html#landing.
Available at: https://standards.ieee.org/content/ieee-standards/en/about/contact/index.html.

vii
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not constitute compliance to any applicable
regulatory requirements. Implementers of the standard are responsible for observing or referring to the
applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action
that is not in compliance with applicable laws, and these documents may not be construed as doing so.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, neither IEEE nor its licensors waive any rights in
copyright to the documents.
Photocopies
Subject to payment of the appropriate licensing fees, IEEE will grant users a limited, non-exclusive license
to photocopy portions of any individual standard for company or organizational internal use or individual,
non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance
Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400;
https://www.copyright.com/. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10
years old and has not undergone a revision process, it is reasonable to conclude that its contents, although
still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit IEEE Xplore or contact IEEE. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.

Available at: https://ieeexplore.ieee.org/browse/standards/collection/ieee.

viii
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard
number and year of approval to access the web page of the published standard. Errata links are located
under the Additional Resources Details section. Errata are also available in IEEE Xplore. Users are
encouraged to periodically check for errata.
Patents
IEEE standards are developed in compliance with the IEEE SA Patent Policy.
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE SA Website at https://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility. Further information may be obtained from the IEEE Standards Association.
IMPORTANT NOTICE
Technologies, application of technologies, and recommended procedures in various industries evolve over
time. The IEEE standards development process allows participants to review developments in industries,
technologies, and practices, and to determine what, if any, updates should be made to the IEEE standard.
During this evolution, the technologies and recommendations in IEEE standards may be implemented in
ways not foreseen during the standard’s development. IEEE standards development activities consider
research and information presented to the standards development group in developing any safety
recommendations. Other information about safety practices, changes in technology or technology
implementation, or impact by peripheral systems also may be pertinent to safety considerations during
implementation of the standard. Implementers and users of IEEE Standards documents are responsible for
determining and complying with all appropriate safety, security, environmental, health, and interference
protection practices and all applicable laws and regulations.

Available at: https://standards.ieee.org/standard/index.html.
Available at: https://standards.ieee.org/about/sasb/patcom/materials.html.

ix
Participants
Experience API Specification documents are a product of Research and Development efforts led by the
Advanced Distributed Learning Initiative, which is a DoD program under the Office of the Deputy
Assistant Secretary of Defense (Force Education and Training).
At the time this IEEE standard was completed, the Experience API Base Standard Working Group had
the following membership:
Jonathan Poltrack, Chair
Andy Johnson, Vice Chair, Techical Editor
Nick Washburn, Secretary
Pankaj Agrawal Brandt Dargue Matthew McGuire
Anthony Altieri Deborah Decker Ryan Mizusaki
Avron Barr Tim Dickinson Alan Mustafa
Kirby Bell Burt Dillenbeck Freddie O’Connell
Tiajuana Benson-Bond Peter Dobinson Scott Powers
Shelly Blake-Plock Jonathan Dudzik Sam Rogers
Mitch Bonnett Erick Emde Hamadou Saliah-Hassane
Megan Bowe Becky Goldberg Domenic Schipani
Brenda Braitling Jason Haag Aaron Silvers
Keith Brawner Viktor Haag Charles Touron
Jessie Chuang Mike Hernandez George Vilches
Ben Clark William Hoyt Michael Weinraub
Jeffrey Clem Moges Kelklie Luis Felipe Zapata Rivera
Thomas Creighton Jonathan Kevan
Marco Dal Colle Daniel McCoy
The working group would like to acknowledge the effort of the following individuals in the creation of
the Experience API and Experience API community.
Dan Allen Joerg Boeselt Mark Davis
Catherine Allman Jeremy Brockman Jhorlin De Armas
Jonathan Archibald Jennifer Cameron Andrew Downes
Keith Bartolotta Rob Chadwick Andriy Drozdyuk
Steve Baumgartner Rich Chetwynd Brian K. Duck
Al Bejcek Lewis Cowper Russell Duhon
Marcus Birtwhistle Ingo Dahn David Ells

x
Paul Esch Dan Kuemmel Kris Rockwell
Michael Flores Richard Lenz Jennifer Rogers
Steve Flowers Jason Lewis Mike Rustici
Richard Fouchaux Robert Lowe Chris Sawwa
Walt Grata Zach Lowry Matteo Scaramuccia
Joe Gorup Bill McDonald Ángel Serrano
Doug Hagy Brian J. Miller Ali Shahrazad
Chaim-Leib Halbert Kris Miller Ryan Smith
Dennis Hall Fiona Leteney Roger Swetnam
Chris Handorf Tim Martin Greg Tatka
Luke Hickey Dave Mozealous Stephen Trevorrow
Thomas Ho Tyler Mulligan Chad Udell
Lang Holloman Mike Palmer Anto Valan
Nikolaus Hruska David Pate Melanie VanHorn
Loic Jeannin Danny Pham Yannick Warnier
David N. Johnson Jeff Place Michael Wheeler
Eric Johnson Rick Raymer Andy Whitaker
Patrick Kedziora Michael Roberts Lou Wolford
John Kleeman Paul Roberts R.J. Zaworski
The following members of the individual Standards Association balloting group voted on this standard.
Balloters may have voted for approval, disapproval, or abstention.
Robert Aiello James Goodell Linda Steedman
Charles Barest Werner Hoelzl Andreas Tsouchlaris
Avron Barr William Hoyt Lisa Ward
Shelly Blake-Plock Andy Johnson Karl Weber
Thomas Creighton Piotr Karocki Yu Yuan
David Fuschi Lakshman Raut Janusz Zalewski

xi
When the IEEE SA Standards Board approved this standard on 30 March 2023, it had the following
membership:
David J. Law, Chair
Ted Burse, Vice Chair
Gary Hoffman, Past Chair
Konstantinos Karachalios, Secretary
Sara R. Biyabani Joseph S. Levy Paul Nikolich
Doug Edwards Howard Li Annette D. Reilly
Ramy Ahmed Fathy Johnny Daozhuang Lin Robby Robson
Guido R. Hiertz Gui Lin Lei Wang
Yousef Kimiagar Xiaohui Liu F. Keith Waters
Joseph L. Koepfinger* Kevin W. Lu Karl Weber
Thomas Koshy Daleep C. Mohla Philip B. Winston
John D. Kulick Andrew Myles Don Wright
*Member Emeritus
xii
Introduction
This introduction is not part of IEEE Std 9274.1.1-2023, IEEE Standard for Learning Technology—JavaScript Object
Notation (JSON) Data Model Format and Representational State Transfer (RESTful) Web Service for Learner
Experience Data Tracking and Access.
Today’s learning ecosystems, digital applications, content, and web-based tools take advantage of large
amounts of learning data to provide learning analytics to improve curricula, to apply artificial intelligence
for the purpose of making recommendations, to visualize data in ways that leverage advances in both data
logistics and human-centered computing, and many other emerging use cases. Due to a lack of
standardized technologies for these use cases, the vendors creating these platforms are forced to create
proprietary solutions. The result is a locked-in environment where a single vendor may levy undue control
over all parts of a learning ecosystem—to the detriment of learning objectives.
In response to this modernization, an Open-Source collaborative effort resulted in the creation of the
Experience API (xAPI). This Standard is a collaborative effort involving that same community, partnered
with the IEEE to improve upon and standardize version 1.0.3 of the xAPI. Artifacts and the latest versions
of this specification can be found at https://opensource.ieee.org/xapi/xapi-base-standard-documentation.
This standard describes a JavaScript Object Notation (JSON) data model format and a Representational
State Transfer (RESTful) Web Service Application Programming Interface (API) for communication
between Activities experienced by an individual, group, or other entity and a Learning Record Store (LRS).
The LRS is a system that exposes the RESTful Web Service API for the purpose of tracking and accessing
experiential data, especially in learning and human performance.
Historical contributors
In collection of requirements for the xAPI, many people and organizations provided invaluable feedback to
the SCORM, distributed learning efforts, and learning technology efforts in general. While not an
exhaustive listing, the white papers gathered in 2008 by the Learning Education and Training Standards
Interoperability (LETSI) group, the Rustici Software UserVoice website, one-on-one interviews and
various blogs were important sources from which requirements were gathered for the xAPI specification.
ADL’s role in the Experirence API (xAPI)
The Advanced Distributed Learning (ADL) Initiative took on the roles of steward and facilitator in the
development of the xAPI. The xAPI is seen as one piece of the ADL Total Learning Architecture
(previously the Training and Learning Architecture), which facilitates learning anytime and anywhere.
ADL views the xAPI as an evolved version of Sharable Content Object Reference Model (SCORM) that
can support similar use cases but can also support many of the use cases gathered by ADL and submitted
by those involved in distributed learning that SCORM could not enable.
How to contribute
To contribute to this effort, please register to join the IEEE SA 9274.1.1 Working Group
xiii
Contents
1. Overview
1.1 Scope
1.2 Purpose
1.3 Word usage
2. Normative references
3. Definitions, acronyms, and abbreviations
3.1 Definitions
3.2 Acronyms and abbreviations
4. Learning Record Stores (LRSs)
4.1 LRS Communication
4.2 LRS Data Requirements
5. Content—Learning Record Providers (LRPs) and Learning Record Consumers (LRCs)
5.1 LRP and LRC Communication
5.2 LRP Data Requirements
Annex A (informative) xAPI Base Standard Examples
A.1 Example Statements
A.2 Examples of Statement’s Objects of different types
A.3 Example definitions for Activities of type cmi.interaction
A.4 Example Signed Statement
xiv
IEEE Standard for Learning
Technology—JavaScript Object
Notation (JSON) Data Model Format
and Representational State Transfer
(RESTful) Web Service for Learner
Experience Data Tracking and Access
1. Overview
The Experience API (xAPI) is a standard that describes an interoperable means to document and
communicate information about learning experiences. It specifies a structure to describe learning
experiences and defines how these descriptions can be exchanged electronically.
In assessing candidates’ suitability for positions or their capability for performing various tasks, there is a
need to consider a wide range of formal and informal learning experiences, both on and offline. That
information, more often than not, is scattered across a wide variety of sources.
Out of this decentralized environment, the Advanced Distributed Learning (ADL) Initiative created the
original xAPI community and specification. The working group effort was moved to the IEEE in 2019.
xAPI assumes that:
— There is a need to be able to analyze information about learning experiences and their outcomes
distributed across a wide variety of sources, platforms and technologies.
— Developing a commonly-accepted framework for gathering, storing and exchanging this
information represents the best way of achieving this.
The goals of the xAPI are:
— To make it easier to understand and compare learning experiences and their outcomes recorded
across a wide variety of contexts, platforms and technologies.
— To maximize interoperability of services which create, gather, store and process information
about learning experiences.
IEEE Std 9274.1.1-2023
IEEE Standard for Learning Technology—JavaScript Object Notation (JSON) Data Model Format and Representational
State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access
— To provide a guide to those who want to build applications that conform to and implement this
specification.
— To provide criteria against which conformance to this specification can be tested.
The xAPI Base Standard is an IEEE Open Source Project hosted on the IEEE Open Source Platform (it is
licensed under the terms of the Apache 2.0 License and copyright the IEEE XAPI Authors see xAPI About
for licensing and copyright information as well as additional information on contributing to this open
source project). You can find this document and other open source resources related to the xAPI Base
Standard at https://xapi.ieee-saopen.org.
Additional xAPI Base Standard resources are available as described below:
— xAPI Base Standard documentation
— xAPI Base Standard markdown
— xAPI Examples (See also Annex A)
1.1 Scope
This standard describes a JavaScript Object Notation (JSON) data model format and a Representational
State Transfer (RESTful) Web Service Application Programming Interface (API) for communication
between Activities experienced by an individual, group, or other entity and a Learning Record Store (LRS).
The LRS is a system that exposes the xAPI RESTful Web Service API for the purpose of tracking and
accessing experiential data, especially in learning and human performance.
1.2 Purpose
The purpose of this standard is to provide an interoperable means to store and retrieve learning experience
data as required by modern, data-intensive learning technologies.
1.3 Word usage
The word shall indicates mandatory requirements strictly to be followed in order to conform to the
6,7
standard and from which no deviation is permitted (shall equals is required to).
The word should indicates that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily
required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may
equals is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
The use of the word must is deprecated and cannot be used when stating mandatory requirements; must is used only to describe
unavoidable situations.
The use of will is deprecated and cannot be used when stating mandatory requirements; will is only used in statements of fact.
IEEE Std 9274.1.1-2023
IEEE Standard for Learning Technology—JavaScript Object Notation (JSON) Data Model Format and Representational
State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they shall
be understood and used, so each referenced document is cited in text and its relationship to this document
is explained). For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments or corrigenda) applies.
FIPS PUB 180-2, Secure Hash Signature Standard (SHA2).
™ 9,10
IEEE Std 754 , IEEE Standard for Floating-Point Arithmetic.
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
IETF RFC 2616, Hypertext Transfer Protocol – HTTP/1.1.
IETF RFC 3629, UTF-8, a transformation format of ISO 10646.
IETF RFC 3987, Internationalized Resource Identifiers (IRIs).
IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace (IRIs).
IETF RFC 5646, Tags for Identifying Languages.
IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content.
IETF RFC 7515, JSON Web Signature (JWS).
IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format.
ISO 639, Code for the Representation of Names of Languages.
ISO 3166-1, Codes for the Representation of Names of Countries and Their Subdivisions—Part 1: Country
Codes.
ISO 8601, Date and time—Representations for information interchange.
SemVer, Semantic Versioning 1.0.0.

FIPS publications are available from the National Technical Information Service (https://www.ntis.gov/).
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
IEEE publications are available from The Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (https://standards.ieee.org/).
IETF documents (i.e. RFCs) are available for download at https://www.rfc-archive.org/.
ISO publications are available from the ISO Central Secretariat (https://www.iso.org/). ISO publications are also available in the
United States from the American National Standards Institute (https://www.ansi.org/).
Available at: https://semver.org/spec/v1.0.0.html.
IEEE Std 9274.1.1-2023
IEEE Standard for Learning Technology—JavaScript Object Notation (JSON) Data Model Format and Representational
State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary Online should be consulted for terms not defined in this clause.
Activity: A type of Object making up the “this” in “I did this”; it is something with which an Actor
interacted. It can be a unit of instruction, experience, or performance that is to be tracked in meaningful
combination with a verb. Interpretation of Activity is broad, meaning that Activities can even be tangible
objects such as a chair (real or virtual). In the Statement, “Anna tried a cake recipe,” the recipe constitutes
the Activity in terms of the Experience API (xAPI) Statement. Other examples of activities include a book,
an e-learning course, a hike, or a meeting.
Activity Provider (AP): Now referred to as a Learning Record Provider (LRP). This change differentiates
that the Activity itself is not always the responsibility of software, rather just that the tracking portion is.
Actor: An individual or group representation tracked using Statements performing an action within an
Activity. The Actor is the “I” in “I did this.”
Application Programming Interface (API): A set of rules and standards created to allow access into a
software application or tool.
authentication: The concept of verifying identity. Authentication allows interactions between two
“trusted” parties.
authorization: The affordance of permissions based on role; the process of making one party “trusted” by
another.
client: Refers to any entity that might interact through requests. Some examples could be a Learning
Record Provider, a Learning Record Consumer, a Learning Record Store (LRS), or a Learning
Management System (LMS).
community of practice (CoP): A group of practitioners connected by a common cause, role or purpose,
which operates in a common modality. CoPs are focused on implementing xAPI within a specific
knowledge domain or use case. CoPs, or independent developers, can create domain-specific vocabularies,
profiles, and recipes. These practices usually involve work around defining use cases and curating the
various vocabulary terms, synonyms, and other related metadata that might be preferred within a CoP.
They can also reuse existing vocabularies, profiles, and recipes already published by other CoPs or
participants of the xAPI community.
document profile resource: A construct where information about the learner or activity is kept, typically
in name/document pairs that have meaning to an instructional system component. Not to be confused with
profile.
endpoint: An entry point in a service-oriented-architecture. xAPI mirrors this approach with document
profile resources by defining the Internationalized Resource Identifier (IRI) from which communication
takes place as an endpoint.
Experience API (xAPI): The collection of rules articulated in this document which determines how
learning experiences are defined, formatted, and exchanged so that independent software programs can
exchange and make use of this information.
immutable: Adjective used to describe things which cannot be changed. With some exceptions,
Statements in the xAPI are immutable. This helps to ensure that when Statements are shared between
Learning Record Stores (LRSs), multiple copies of the Statement remain the same.

IEEE Standards Dictionary Online is available at: http://dictionary.ieee.org. An IEEE Account is required for access to the
dictionary, and one can be created at no charge on the dictionary sign-in page.
IEEE Std 9274.1.1-2023
IEEE Standard for Learning Technology—JavaScript Object Notation (JSON) Data Model Format and Representational
State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access
Internationalized Resource Identifier (IRI): A unique identifier which could be an IRL. Used to identify
an object such as a verb, activity, or activity type. Unlike Uniform Resource Identifiers (URIs), IRIs can
contain some characters outside of the ASCII character set in order to support international languages. IRIs
always include a scheme. This is not a requirement of this standard, but part of the definition of IRIs, per
What are sometimes called “relative IRIs” are not IRIs.
RFC 3987.
Internationalized Resource Locator (IRL): In the context of this document, an IRL is an IRI that when
translated into a Uniform Resource Identifier (URI) (per the IRI to URI rules), is a Uniform Resource
Locator (URL).
Inverse Functional Identifier (IFI): An identifier which is unique to a particular persona or group.
learning experience: An event associated with learning. It is highly diverse as far as what it can be.
Examples include reading a book, taking an online course, going on a field trip, engaging in self- directed
research, or receiving a certificate for a completed course.
Learning Management System (LMS): A software package used to administer one or more courses to
one or more learners. An LMS is typically a web-based system that allows learners to authenticate
themselves, register for courses, complete courses and take assessments (Learning Systems Architecture
Laboratory definition). An LMS in this document is used as an example of how a user is identified as
“trusted” within a system and able to access its learning experiences.
Learning Record Consumer (LRC): An Experience API (xAPI) Client that accesses data from Learning
Record Store(s) (LRS(s)) with the intent of processing the data, including interpretation, analysis,
translation, dissemination, and aggregation.
Learning Record Provider (LRP): An Experience API (xAPI) Client that sends data to Learning Record
Store(s) [LRS(s)]. Often, the LRP creates learning records while monitoring a learner as a part of a learning
experience.
Learning Record Store (LRS): A server (i.e., a system capable of receiving and processing web requests)
that is responsible for receiving, storing, and providing access to learning records.
learning record: An account of a learning experience that is formatted according to the rules of xAPI. A
Learning Record takes on many forms, including Statements, documents, and their parts. This definition is
intended to be all-inclusive.
metadata consumer: A person, organization, software program or other thing that seeks to determine the
meaning represented by an Internationalized Resource Identifier (IRI) used within this specification and/or
retrieves metadata about an IRI. A Learning Record Store (LRS) might or might not be a metadata
consumer.
metadata provider: A person, organization, software program or other thing that coins Internationalized
Resource Identifiers (IRIs) to be used within this specification and/or hosts metadata about an IRI.
persona: A set of one or more representations which defines an Actor uniquely. Conceptually, this is like
having a “home email” and a “work email.” Both are the same person, but have different data, associations,
etc.
profile: A specific set of rules and documentation for implementing an Experience API (xAPI) in a
particular context. A profile provides a way to talk about vocabulary concepts, statement templates, and
patterns for xAPI data. Not to be confused with document profile resource.
registration: An instance of an Actor experiencing a particular Activity.
Representational State Transfer (REST): An architecture for designing networked web services. It relies
on hypertext transfer protocol (HTTP) methods and uses current web best practices.
service: A software component responsible for one or more aspects of the distributed learning process.

Information on references can be found in Clause 2.
IEEE Std 9274.1.1-2023
IEEE Standard for Learning Technology—JavaScript Object Notation (JSON) Data Model Format and Representational
State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access
Statement: A data structure showing evidence for any sort of experience or event which is to be tracked in
Experience (xAPI) as a learning record. A set of several Statements, each representing an event in time,
might be used to track complete details about a learning experience.
Verb: The action being done by the Actor within the Activity within a Statement. A Verb represents the
“did” in “I did this.”
3.2 Acronyms and abbreviations
AP Activity Provider
API Application Programming Interface
CoP community of practice
IFI Inverse Functional Identifier
IRI Inter
...