SCORM Cloud v2 API Documentation


Core Concepts

SCORM Cloud has a few core concepts that are helpful to understand when building an integration against it.

Realms are the billing accounts of SCORM Cloud. Each realm either has a billing plan that determines its usage limits and monthly cost, or it is linked to another realm that has a billing plan. The API does not have any operations that work at the realm level. (There is no API to create or delete realms, for example.)

Applications are logically-separate containers within realms. The SCORM Cloud API operates within the context of an application: API credentials are an application ID (app ID for short) and a secret key.

Courses (or packages) are the unit of standardized learning content: a SCORM, AICC, cmi5, or Tin Can package. These are stored on a per-application basis.

Registrations are the logical association of a learner with a course. When an integrating system “assigns” a course to a learner, it will often create a registration in SCORM Cloud. Since courses are stored on a per-application basis, so too are registrations.

The relationship between these objects is shown in this graph:



Note that learners are not a distinct object in SCORM Cloud; there is neither an API to manage learners nor a learner repository in SCORM Cloud itself that tracks different learners. SCORM Cloud only knows about learners through the registration API, which includes the learner ID, first name, and last name.

User accounts do exist in SCORM Cloud, but these are strictly accounts used to access the management UI at There is no public API to manage them.

New Realms

To demonstrate the above concepts: When a user signs up for a SCORM Cloud account at, the system creates a default realm for them. By default, new realms are created with two applications in them. One application (named “SCORM Cloud”) is used internally by the website, and the other application (named “Initial Application for …”) is left empty. No courses or registrations are in a new account by default.

The user might select “Add Content” on the website and import a SCORM package. This package (course) will be added to the SCORM Cloud application. The user can then launch the package in the testing sandbox (the course info page) – this will create a no-charge sandbox registration within the SCORM Cloud application, then launch that registration.

API Quick Start

This document contains information on Getting Started with the SCORM Cloud API.

Signing Up

The first step is to sign up for a SCORM Cloud account. As explained in Core Concepts, this will create a single realm with two applications by default. The Trial billing plan is free, albeit with some restrictions:

  • You may only have 10 active registrations at one time.
  • You may only have 100 MB of course content.

While developing an integration with SCORM Cloud, we recommend deleting courses and registrations once you’re finished using them, so as to stay below the trial limits. Alternately, you can upgrade your account to a paid level. See SCORM Cloud Pricing for more information.

API Credentials

Once you’ve got a SCORM Cloud account, log into it and go to the Apps / API page. The API exposes and allows the management of information inside each of these applications.

Your API credentials are an Application ID (App ID) and a Secret Key. Click “Details” on one of your applications. The App ID for that application is at the top of the page. The secret keys are under Authorization Keys. Any of the secret keys will work for the API.

Take note of an app ID and secret key; we’ll use them later.

Client Libraries

We provide API client libraries for some common programming languages:

If you’re using one of these languages, we strongly recommend using these libraries as at least a starting point. If not, see Communication Format for the communication format of the SCORM Cloud API. (We recommend using the client libraries as a reference when implementing your own client.)


The client libraries do not necessarily have every API call implemented, although we’ve tried to implement the most common, and we’re adding missing API calls as people report them.

Fortunately, adding new API calls to the libraries is fairly straightforward.


For starters, the base path of the v2 api is:

As an example, probably the simplest call to test would be /ping. As a simple curl from the command line, that’d be:

curl -X GET

The rest of the documentation will omit the base path for brevity.


Now if you tested the /ping from the previous section, you saw that you got a 401 status code with the following response:

{ "error": "Authorization Required." }

There are no calls in the v2 api which are unauthenticated. This is where the app ID and secret key you noted earlier come into play. The SCORM Cloud v2 api offers two types of authentication schemes:

HTTP basic auth

You’ll see this referred to as APP_NORMAL or APP_MANAGEMENT in our API specification. Your app ID will be your username and your password is your secret key.


You’ll see this as, you guessed it OAUTH, and it will be accompanied by a scope which is specific to the operation and endpoint you’re attempting to call. For instance, if you were looking to get a list of courses in your application, you’d request an OAuth token with the scope read:course.

We have two possible endpoints from which you can obtain authentication tokens. They are functionally exactly the same, with some small variance in what is returned. They are:

  • POST /oauth/authenticate/application/token - Found here
  • POST /appManagement/token - Found here

Full SCORM Cloud API Documentation

If you have any questions, just send us a message at

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request
Powered by Zendesk