LTI vs SCORM: which standard do you need?

What is the difference between LTI and SCORM?

LTI vs SCORM is not a choice between two ways to do the same job. LTI is an integration standard: the LMS launches your tool, which stays on your server. SCORM is a content standard: you hand the LMS a zip file it hosts and runs itself.

Both end with a score in a learning platform, which is where the confusion starts, but they arrive from opposite directions. With SCORM you give away a package; with LTI you give away a URL and keep everything else. That difference decides who runs a server, who holds the content, and what happens when you want to change something after launch.

What LTI does

Learning Tools Interoperability is a specification from 1EdTech (formerly IMS Global). In its vocabulary the LMS is the platform and your application is the tool. An administrator registers the tool once, exchanging a client identifier and keys; after that an instructor can drop a link into a course.

When a learner clicks that link, the platform sends a signed launch message to your tool's URL. That message is the whole point of LTI. It carries:

• Who the learner is — a stable user identifier, plus name and email if the platform's privacy settings release them.
• What context they are in — the course or section id and title, so the same tool can behave differently per course.
• What role they hold — learner, instructor, administrator — so one link can show a teacher an authoring view and a student the activity.
• Where to send results — service endpoints your tool can call back on later, server to server.

In LTI 1.1 that message was a form POST signed with OAuth 1.0a. LTI 1.3, the current version, uses an OpenID Connect handshake and a JSON Web Token signed with a key the platform publishes, and adds the LTI Advantage services: Assignment and Grade Services for writing scores, Names and Role Provisioning Services for reading the roster, and Deep Linking so an instructor can pick content from inside your tool. 1EdTech has deprecated 1.1, so new integrations should target 1.3.

What LTI does not standardise is the activity. Once the launch lands, everything the learner sees is your application, built however you like. LTI has no data model for a course, no notion of a page or a module, and no opinion about what happens between launch and result.

What SCORM does

SCORM standardises exactly the part LTI leaves alone. A SCORM package is a zip containing your content and a manifest telling the LMS what to launch and in what order. The LMS unpacks it, hosts the files, and opens a page in a frame. That page finds a JavaScript object the LMS placed in the window hierarchy — API for SCORM 1.2, API_1484_11 for SCORM 2004 — and talks to it for the session. The SCORM API explained walks through the call sequence; what SCORM is covers the package layout.

The consequence worth internalising is that SCORM has no server-side identity. The content asks the LMS for cmi.learner_id and gets back a string. Nothing is signed. There is no callback URL and no shared secret, because the content runs inside the LMS's own page and the LMS already knows who is there. That is fine for a course and useless for an application that must authenticate a user against your own system.

Grade passback vs runtime reporting

Both standards move a result back to the platform, but they carry different amounts of it.

LTI's Assignment and Grade Services works at the level of a gradebook column. Your tool posts a score against a line item: a score, the maximum it was out of, an activity progress value such as Completed, a grading progress value such as FullyGraded, and optionally a comment. That is close to the whole vocabulary — a result, posted server to server, usually once, when your tool decides the learner is finished.

SCORM's runtime is a live conversation instead. Over one session the content may set a score, a completion status, a success status, a bookmark, a suspend-data blob, session time, and a list of interactions with the learner's responses — and read them all back on the next attempt so the learner resumes where they stopped.

LTI (AGS, one call at the end)
  POST .../lineitems/42/scores
  { "scoreGiven": 84, "scoreMaximum": 100,
    "activityProgress": "Completed",
    "gradingProgress": "FullyGraded" }

SCORM (runtime, many calls per session)
  SetValue("cmi.location", "sec-05")
  SetValue("cmi.suspend_data", "...")
  SetValue("cmi.score.scaled", "0.84")
  SetValue("cmi.success_status", "passed")
  SetValue("cmi.completion_status", "completed")
  Commit("")

Neither is richer in every direction. SCORM tells the LMS more about the shape of the session; LTI tells you more about who the learner is and what they are enrolled in, because the launch was signed and the roster is queryable. If you need per-interaction detail sent somewhere that is not a gradebook, that is what xAPI and a learning record store are for.

Using them together

They are not rivals, and the most common serious integration uses both. An LTI tool can be a SCORM player: the platform launches your tool, your tool authenticates the learner from the signed launch, plays a SCORM package you host, watches the runtime calls the content makes, and maps the final completion and score onto an AGS score post. The LMS never imports a package and never sees SCORM.

That gets you the useful half of each standard: a fix deployed once instead of re-imported into forty customer LMSs, a trustworthy identity from the launch, and the fine-grained runtime data — bookmarks, suspend data, interactions — kept on your side, with only the score going to the gradebook.

The lighter version of the same idea is dispatch: a small SCORM package imported as normal that contains only a launcher pointing at content you host. No LTI registration is needed, and you still update the real content centrally. SCORM dispatch explained covers the trade-offs.

Which one your integration needs

Work down this list and stop at the first line that describes you.

1. You are sending a course to someone else's LMS and do not want to run anything. Ship SCORM. It is what procurement asks for, and the customer's LMS team owns the uptime.
2. Your product is an application — a simulator, a coding environment, an adaptive practice engine — and it must run on your infrastructure. Use LTI 1.3. Packaging an application as SCORM means shipping your product to the customer.
3. You need to know who the learner is, on your own servers, with something you can trust. LTI. SCORM's cmi.learner_id is an unsigned string read inside the LMS's page and cannot be used as an authentication claim.
4. You need to fix and update content centrally across many customer platforms. LTI, or SCORM dispatch if the customers will only accept a package.
5. You need resume, bookmarking and per-question detail recorded by the platform itself. SCORM — SCORM 2004 if completion and pass must report separately, or if your state exceeds the 4 KB cmi.suspend_data cap in 1.2.
6. Your buyer's platform will only accept one of them. Then that is your answer — confirmed against the platform's current documentation, not what it supported when the contract was signed.

The failure mode to avoid is choosing LTI because it sounds more modern, then discovering you have committed to an authenticated, always-available web service with key rotation and a registration per customer platform — to deliver what was a slide deck. Modernity is not the axis. Whether you hand the content over or hold on to it is.

Where SCORM Central fits

SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.