SCORM vs Custom API: Integrating Games with Learning Management Systems

When an educational institution commissions a game, one of the first questions on the requirements document is: "Will it integrate with our LMS?" The answer is almost always "yes." The follow-up question - how - is where the real engineering decisions begin.

Our educational work ranges from The Language Conservancy (Vocab Builder) to projects delivered during previous agency tenures for institutions including Cambridge University Press, the BBC, and European university consortia through the EU Horizon 2020 programme (Navigo). Institutional projects repeatedly raise the same integration questions: where the game runs, how identity is passed in, what progress must be reported, and which system owns the learning record.

This post compares the two primary approaches to LMS integration - SCORM (the established standard) and custom APIs (the flexible alternative) - and provides practical guidance on when each approach makes sense.

What Problem Are We Solving?

Before comparing solutions, it is worth being precise about what LMS integration actually needs to accomplish:

1. Launch - the LMS needs to open the game in the right context (correct student, correct assignment, correct lesson).
2. Track progress - the LMS needs to know how far the student has progressed through the content.
3. Report scores - test results, quiz scores, and performance metrics need to flow from the game back to the LMS gradebook.
4. Record completion - the LMS needs to know when the student has finished the activity so it can unlock the next one or mark the assignment as done.
5. Resume - if the student stops mid-session, the game should pick up where they left off when they return.

These five requirements are common to virtually every educational game integration. The question is which technology best delivers them for your specific context.

SCORM: The Established Standard

SCORM (Sharable Content Object Reference Model) is the most widely adopted e-learning standard. Maintained by ADL (Advanced Distributed Learning), it defines how learning content communicates with an LMS.

SCORM 1.2

Released in 2001, SCORM 1.2 is still widely encountered in established e-learning environments. Major LMS products commonly support it, although the exact launch, reporting, and packaging behaviour varies by platform and configuration.

How it works: The LMS launches your game in an iframe. Your game communicates with the LMS via a JavaScript API (API object on the window). You set and get data model elements using standardised keys.

Key data model elements in SCORM 1.2:

Strengths of SCORM 1.2:

• Broad LMS support - SCORM 1.2 remains a common compatibility target across established LMS products
• Simple to implement - the API surface is small. A basic integration can be built in a few days.
• Proven and stable - the standard has not changed in over two decades. It will not break.
• No backend required - communication happens entirely client-side between the game and the LMS

Limitations of SCORM 1.2:

• 4096-character limit on suspend_data - this is the biggest practical constraint for games. A complex game with significant state (inventory, progress across multiple mini-games, per-question analytics) will quickly exceed this limit.
• Single score model - SCORM 1.2 supports one score per content object. If your game has multiple assessments, you must either aggregate them or package each assessment as a separate SCO (Sharable Content Object).
• No detailed interaction tracking - there is no standard way to report individual question responses, time per question, or attempt history.
• iframe dependency - the game must run inside the LMS iframe. This introduces CSP (Content Security Policy) constraints, cross-origin issues, and limits your ability to use fullscreen or certain browser APIs.

SCORM 2004 (Editions 1-4)

SCORM 2004 addresses many of SCORM 1.2's limitations with a richer data model and a sequencing engine.

Key improvements over 1.2:

• cmi.interactions - a structured array for recording individual question-level data: question type, correct response, learner response, latency, and result. This is invaluable for educational games with assessment components.
• Larger suspend_data - the 4096-character limit is increased to 64,000 characters in most SCORM 2004 implementations.
• Multiple objectives - track progress against multiple learning objectives within a single content object, each with its own score and completion status.
• Sequencing and navigation - define prerequisite relationships between content objects. The LMS can enforce that Level 1 must be completed before Level 2 unlocks.

Limitations of SCORM 2004:

• Less universal LMS support - while major platforms support it, some older or specialised LMS installations only support SCORM 1.2.
• More complex to implement - the sequencing engine is powerful but adds implementation complexity.
• Still iframe-dependent - the same hosting constraints apply.
• Overkill for simple games - if you only need a completion flag and a score, SCORM 2004's additional capabilities add complexity without proportional value.

Key Takeaway: If the target LMS is already known, test against that platform first rather than choosing a standard in the abstract. SCORM 1.2 is a strong compatibility option for simple completion/score reporting; richer tracking may justify SCORM 2004, xAPI, or a custom integration.

xAPI (Tin Can API): The Modern Alternative

Before discussing custom APIs, it is worth mentioning xAPI (also known as Tin Can API), which sits between SCORM and a fully custom approach.

xAPI uses a "statement" model: Actor + Verb + Object. For example: "Student 42 completed Level 3 with score 92%." These statements are sent to a Learning Record Store (LRS) via HTTP.

Strengths:

• Rich, flexible statement model without SCORM's small suspend-data constraint
• Works outside the browser (mobile apps, VR, offline with deferred sync)
• Excellent for analytics and learning data research

Limitations:

• Requires an LRS (not all LMS platforms include one natively; Moodle requires a plugin)
• More complex client-side implementation than SCORM
• Less institutional familiarity - IT teams at schools and universities are often less comfortable with xAPI than SCORM

xAPI is a strong choice when you need detailed learning analytics and your client's infrastructure supports it. In our experience, many institutional briefs still ask for SCORM because it is familiar to procurement and L&D teams, even when a richer integration would be technically possible.

Custom API: The Flexible Alternative

A custom API approach means building your own backend service that sits between the game and the LMS. The game communicates with your API via standard HTTP REST calls, and your API translates the data into whatever format the LMS expects.

Architecture Overview

[Game Client] <--REST/WebSocket--> [Your Backend API]
                                          |
                                   [Your Database]
                                          |
                              [LMS Integration Layer]
                                    /     |     \
                              [Moodle] [Canvas] [Blackboard]

What Your Backend Handles

1. Authentication - the LMS passes a token or session identifier when launching the game. Your backend validates it and associates the session with the correct student and assignment.

2. Data storage - all game telemetry (progress, scores, interaction logs, time-on-task, attempts) is stored in your database. No character limits. No schema constraints.

3. Score and completion reporting - your backend pushes aggregated results back to the LMS gradebook via the LMS's API (Moodle Web Services API, Canvas REST API, Blackboard REST API).

4. Analytics dashboard - because you own the data, you can build teacher-facing dashboards that provide richer insights than the LMS's built-in reporting. When we worked on educational projects, the ability to show educators which specific concepts students were struggling with - not just a percentage score - was consistently cited as the most valuable feature.

5. Resume and state management - game state is stored server-side with no size constraints. The game can resume exactly where the student left off, regardless of device or browser.

Strengths of a Custom API

• No data limits - store as much telemetry as you need. Per-question timing, hint usage, retry counts, learning path analytics.
• Platform independence - the game communicates with your API, not the LMS directly. Adding support for a new LMS means adding a new integration adapter, not rewriting the game.
• Native mobile support - Unity games deployed as native iOS/Android apps cannot use SCORM (which requires a browser runtime). A custom API works identically for web, mobile, and desktop builds.
• Richer analytics - build teacher dashboards, export data for research, generate per-student reports that go far beyond a single score.
• Real-time data - WebSocket connections allow the teacher to see student progress in real-time during a classroom session.

Limitations of a Custom API

• You build and maintain the backend - this is additional engineering cost, infrastructure cost, and ongoing maintenance. SCORM is essentially "free" at the integration layer because the LMS provides the backend.
• Per-LMS integration work - every LMS has a different API. Moodle's Web Services API is different from Canvas's REST API. Each integration must be built and maintained separately.
• Procurement friction - educational institutions have established procurement processes for SCORM content. A custom integration requires IT involvement, security reviews, and potentially custom hosting arrangements.
• Data privacy compliance - you are now a data processor handling student data. GDPR (and GDPR-K for children), COPPA (US), and FERPA (US education) all apply. Your backend must be compliant.

Decision Framework: Which Approach Should You Use?

The choice between SCORM and a custom API depends on answering four questions:

1. What platforms will the game run on?

If the game runs only in a web browser and is launched from the LMS, SCORM is the path of least resistance. If the game runs as a native mobile app (iOS/Android) or a desktop application, you need a custom API because SCORM's JavaScript API is browser-only.

2. How complex is the data you need to track?

3. How many LMS platforms must you support?

If your client uses a single, known LMS, a custom integration is manageable. If your product must work with any LMS the customer happens to use, SCORM's universality is a significant advantage.

4. What is your maintenance budget?

SCORM is a fire-and-forget standard. Once your SCORM wrapper works, it works everywhere, indefinitely. A custom API requires hosting, monitoring, security updates, and per-LMS compatibility maintenance. This is an ongoing cost.

Key Takeaway: Use SCORM when universality and low maintenance are priorities. Use a custom API when data richness, mobile deployment, or real-time analytics are requirements. In many projects, the best answer is both - SCORM for basic LMS compliance, plus a custom backend for analytics.

Integration Approach Comparison

Here is how the three main LMS integration approaches compare across the factors that matter most:

The Hybrid Approach

In practice, we often recommend a hybrid architecture that provides the best of both worlds:

1. Package the game as a SCORM object for LMS compatibility (completion, basic score, resume via suspend_data).
2. Simultaneously send detailed telemetry to your own backend for analytics, teacher dashboards, and research data.

The SCORM layer ensures the game "just works" in any LMS. The custom backend provides the rich data that SCORM cannot capture. The game client simply fires data to both endpoints.

This hybrid pattern is often worth considering in educational game development: use the LMS-facing standard for launch, completion, and core reporting, while a separate backend captures the richer telemetry needed for dashboards or research. Whether that is appropriate depends on the client's data-governance and procurement requirements.

Implementation Tips for Unity Developers

SCORM from a Unity WebGL Build

Unity WebGL builds run inside a canvas element, which the LMS wraps in an iframe. To communicate with the SCORM API:

1. Create a JavaScript plugin (.jslib file) that accesses the SCORM API on the parent window.
2. Call the JavaScript functions from C# using Unity's [DllImport("__Internal")] interop.
3. Wrap the SCORM calls in a C# class that implements a common interface (so you can swap to a custom API for non-SCORM deployments).

Key gotchas:

• Cross-origin issues - ensure the Unity build is served from the same origin as the LMS, or configure CORS headers appropriately.
• WebGL memory - educational institutions often use low-spec devices (Chromebooks). Keep your WebGL build's memory allocation conservative.
• Fullscreen - SCORM iframes may prevent fullscreen API access. Design your game's UI to work within a constrained viewport.

Custom API from a Unity Native Build

For iOS and Android deployments:

1. Use UnityWebRequest for HTTP communication with your backend.
2. Implement local queuing for offline resilience - educational environments often have unreliable Wi-Fi.
3. Authenticate via OAuth 2.0 or a signed JWT token passed from the LMS at launch.
4. Batch telemetry events and send them periodically (every 30-60 seconds) rather than on every interaction, to reduce network overhead.

Compliance and Privacy

Educational game developers handling student data must navigate several regulatory frameworks:

• GDPR (EU/UK) - requires a lawful basis for processing, data minimisation, right to erasure, and a Data Processing Agreement between you and the institution.
• GDPR-K / Age-Appropriate Design Code (UK) - additional protections for children's data, including restrictions on profiling and data sharing.
• COPPA (US) - requires verifiable parental consent for children under 13. Applies to any game used in US schools.
• FERPA (US) - protects student education records. Your backend becomes a "school official" if it accesses student data on behalf of the institution.

Privacy compliance is not optional and should be designed into the architecture from day one, not bolted on before launch. We factor compliance requirements into the initial architecture design for every educational project.

Choosing the Right Path

To summarise, here is our recommended decision path:

1. Browser-only, single LMS, simple tracking --> SCORM 1.2
2. Browser-only, multiple objectives, detailed interactions --> SCORM 2004
3. Native mobile app, any platform --> Custom API (SCORM is not available)
4. Complex analytics, teacher dashboards, research --> Custom API or xAPI
5. Universal LMS compatibility + rich analytics --> Hybrid (SCORM + Custom API)
6. Future-proofing for modern infrastructure --> xAPI with LRS

The worst outcome is choosing an approach that does not meet your requirements and having to re-engineer mid-project. Invest the time upfront to understand your client's LMS landscape, data needs, and deployment platforms.

Related Reading

• Educational Game Development Services - How we build games that teach
• Education Industry - Our work across the education sector
• Corporate Training Industry - Gamified training and L&D solutions
• Gamifying Language Learning: Lessons from EdTech Development - Our approach to turning curriculum into gameplay