LMS exports (SCORM 1.2 and xAPI)

Two ways to bring Maketools results into your training ecosystem, included in the Pro and Enterprise plans:

SCORM 1.2 package

How it works

The package contains no game: it holds a small launcher that runs inside your LMS and a signed launch token. When the learner clicks Start the game, the launcher opens the hosted game in a new window. The game is never embedded in a frame: our security policy forbids it (frame-ancestors 'none'), which protects your learners against clickjacking.

At the end of the play, the game window sends the result computed by our server back to the launcher, which writes it to the LMS:

The launcher then calls LMSCommit and LMSFinish. The passing score is also written in the manifest (adlcp:masteryscore), so your LMS can compute the status itself.

Both sides check where messages come from: the launcher only accepts our origin, and the game only answers the window that opened it. The launch token is tied to the fork and to the package, and expires after 365 days.

Export a package

1. Deploy a release of your fork.
2. Give it Organisation or Restricted access: SCORM export is for private games only (see below).
3. On the fork's Releases page, click Export for an LMS (SCORM 1.2), choose the language of the package among those of the deployed release, and upload the zip to your LMS as a SCORM 1.2 activity.

A package opens the game in one language: to offer the game in several languages in your LMS, export one package per language (see Translate a fork). If the release deployed later no longer offers that language, the game opens in the fork's source language.

Every package is listed on the same page, with its language. Revoke a package to stop it immediately: its launcher can no longer open the game. Changing the address of the organisation or of the fork breaks existing packages: export a new one.

Learner identity and access policy

SCORM is for private games only (Organisation or Restricted access): every learner plays as a signed-in member of your organisation. They sign in to Maketools in the game window, the play also appears in your Maketools reports, and they count as a seat of your plan, like any active member. A Public game cannot be exported, and if you make an exported game Public, its packages stop opening the game until you make it private again.

Maketools does not create accounts from the LMS learner id (cmi.core.student_id): your LMS keeps the link between the learner and the result.

Recommended: Organisation with your company's single sign-on, so that learners use the account they already have. With Google, Microsoft or SSO sign-in, the browser leaves the game window for your identity provider and the link with the LMS is lost: ask learners to sign in to Maketools once before their first launch, then launch again from the LMS.

Limits

• Pop-ups must be allowed for your LMS. The launcher says so if the window is blocked.
• One result per launch: the first completed play is reported, the LMS attempt is then closed. A replay in the same window does not change the LMS result.
• Keep the game window open until the end screen.

xAPI connector

Set up

Owners and admins open Reports, then LMS connector:

1. Enter the endpoint of your LRS (HTTPS, for example https://lrs.example.com/xapi), and the key and secret of its Basic authentication. They are encrypted at rest and never shown again (only the last four characters of the key). If you later change the endpoint to another server (scheme, host or port), enter the key and secret again: saved credentials are never sent to a different server.
2. Choose whether to send one answered statement per item.
3. Save, then Test the connection. Enable the connector when the test succeeds.

Every change is recorded in the audit log. Disabling or deleting the connector empties the queue: nothing is sent without your consent.

What is sent

After each completed play of a deployed fork (never a test play from the editor, never a public catalogue game):

• Actor: in pseudonymous mode (default), mbox_sha1sum of an address derived from the player's pseudonym (never from their real email) and the name Player-XXXX; in nominative mode, mbox = the player's email and their display name, for current members of your organisation only (other players keep the pseudonymous actor); for an anonymous player of a public fork, an account anonymous-<play session id>.
• Activities: the fork (<site>/xapi/activities/forks/<forkId>, type assessment), the game in context.contextActivities.category (<site>/xapi/activities/games/<gameId>), and each item under the fork (…/forks/<forkId>/items/<itemId>). These IRIs are stable. Names (definition.name) are given in each language offered by the release that was played.
• Result: score (raw, min, max, scaled), completion, success, duration (ISO 8601).
• Context: registration = the play session id (groups the statements of one attempt), platform = Maketools, and the skills tally in the extension <site>/xapi/extensions/skills.
• Version: xAPI 1.0.3.

Delivery

Statements are sent right after the play, in batches. If the LRS is unavailable, they are retried after 1, 2, 4… minutes, up to 6 hours between attempts, 10 attempts in total; after that they are marked failed and deleted after 30 days. The page shows pending and failed statements. Each statement has a deterministic id: a retry never creates a duplicate in your LRS.

Sending is capped per organisation at 10,000 statements per hour (about 300 learners finishing in the same hour with detailed answers). Statements over the cap are not lost: they wait in the queue and leave as soon as the hourly budget allows. The queue itself holds at most 20,000 pending statements; when it is full (typically an LRS that has been unreachable for hours), the statements of new plays are not queued until it drains. Our team is alerted in both cases.

Step by step in common platforms

Menus differ between versions; these are the generic steps.

• SCORM Cloud: add the zip to your library as new content, launch it to check the result. For xAPI, create activity provider credentials for its LRS endpoint and paste the endpoint, key and secret into Maketools.
• Moodle: add an activity of type SCORM package to a course and upload the zip. Moodle reads the score and status. For xAPI, connect Maketools to the LRS your organisation uses with Moodle.
• 360Learning (or any LMS importing SCORM 1.2): create a course module from a SCORM package and upload the zip. For xAPI, use the LRS endpoint and credentials provided by your platform, if it offers one.

Data protection

The LRS and the LMS are third parties chosen by your organisation: your organisation decides what is sent and remains responsible for these data there. In pseudonymous mode, no name or email leaves Maketools; in nominative mode, the email and name of players are sent to your LRS. See Player privacy in reports.