Moodle Integration 2026: API, LTI, Plugins & SCORM

Updated October 2026: Moodle 5.3 LTS (released 5 October 2026) and the current support windows, step-by-step web-services API setup with a first REST call, LTI Advantage dynamic registration, a compatibility warning for the xAPI log store, and an FAQ.

What Is Moodle Integration? The Short Answer

Moodle integration means connecting an outside product or system to Moodle LMS through one of four paths: an LTI 1.3 launch (your hosted tool opens inside a course), a SCORM or xAPI/H5P package (content Moodle stores and tracks), a PHP plugin (code that runs inside Moodle), or the web-services REST API (another system reads and writes Moodle data with a token). For a hosted video or interactive tool, LTI 1.3 with the LTI Advantage services is the default: you build it once, a Moodle administrator configures it in minutes, and the same code launches into Canvas, Blackboard and other LMSs. Use the API for data sync, and write a plugin only when behaviour must live inside Moodle's own screens.

Moodle API integration is the fourth path: an administrator enables web services and the REST protocol, creates a service limited to named functions such as core_user_create_users or core_completion_get_course_completion_status, and issues a token that your system sends to /webservice/rest/server.php. The choice matters at Moodle's scale: moodle.org's statistics page listed 161,020 registered sites and about 412 million users in 242 countries when we checked in October 2026, and the current Long Term Support release, Moodle 5.3, shipped on 5 October 2026.

Why This Matters

If you sell or build a learning-video product, "does it work with Moodle?" is one of the first questions a school, university, or training department will ask — Moodle runs a large share of the world's online courses, and much of it is in the public sector. This article is for the L&D director, EdTech founder, or product manager who has to decide how to integrate, brief engineers, and budget the work without over-building. The wrong path can turn a configurable LTI launch into a plugin that you re-test and patch on every Moodle release, for one LMS only. We keep each claim tied to Moodle's own developer documentation and to the named standards, but readable from the first sentence.

What "Integrating With Moodle" Actually Means

The phrase hides a real fork in the road, and teams that skip it build the wrong thing. "Integration" can mean any of four things, and they barely overlap.

It can mean launching your externally hosted tool inside a Moodle course — a learner clicks a link in their course and lands in your video player, already logged in. It can mean delivering packaged content that Moodle stores and plays — you hand Moodle a file and it tracks completion. It can mean changing how Moodle itself behaves — adding a new activity type, a new report, a new button, by writing code that runs inside Moodle. Or it can mean reading and writing Moodle's data from another system — your back-office app pulls course completions out of Moodle every night.

Each of these maps to a different technology, a different cost, and a different team. The rest of this article walks all four, then says which to pick for a video product. Hold this fork in mind: most "Moodle integration" debates are really arguments about which of these four jobs you actually need.

Moodle In One Idea: An Open-Source LMS Built To Be Extended

Before the paths, one fact shapes all of them. Moodle is an open-source learning management system — a free, self-hostable platform that schools and companies run to deliver courses, quizzes, and grades. "Open-source" means the code is public and anyone can install, modify, and extend it, which is exactly why Moodle integration has so many doors: you can plug in from the outside through standards, or reach inside and change the code.

Moodle's whole architecture is built around plugins — self-contained add-ons that extend the core. Moodle's developer documentation lists a wide range of plugin types: activity modules (a new kind of course activity), blocks, themes, authentication plugins, enrolment plugins, repository plugins, report plugins, and more. This matters because two of our four integration paths — packaged content and custom plugins — lean directly on this plugin model, while the other two — LTI and the web-services API — are Moodle's front and back doors for systems that stay outside it.

The release calendar shapes the cost of every path. Moodle ships two major releases a year, in April and October, with point releases every two months. Moodle 5.3, released on 5 October 2026, is the current LTS: bug fixes until 4 October 2027 and security fixes until 1 October 2029. Moodle 5.2 (20 April 2026) raised the minimum to PHP 8.3 and requires upgrading from 4.4 or later, and many institutions still run 4.5 LTS, which receives security fixes until 4 October 2027 (Moodle release table, checked October 2026). In 2026 a buyer's Moodle can therefore be any of three or four branches. Anything that runs inside Moodle has to be tested on each of them, while an LTI tool or an API client mostly does not care.

Figure 1. The four ways to integrate with Moodle. LTI and the web-services API connect systems that stay outside Moodle; packaged content and plugins live inside it. Pick the path that matches the job, not the most powerful one.

Path 1 — LTI: Launch Your Tool Inside Moodle (The Default For Video)

The cleanest way to put a video or interactive tool into Moodle is Learning Tools Interoperability — LTI — the education standard that lets an external tool launch securely inside any LMS without its content ever being copied in. Your tool stays on your servers; Moodle opens a trusted, signed doorway into it. If you only read one path, read this one: for a hosted video product, LTI is almost always the right default. (For the standard itself, see LTI explained.)

Moodle has supported the modern version, LTI 1.3, for years, on both sides of the relationship. When Moodle is the Platform (the LMS that hosts the learner and starts the launch), an administrator adds your tool under Site administration → Plugins → Activity modules → External tool → Manage tools, choosing "Configure a tool manually." Moodle's own documentation is explicit about what LTI 1.3 changed: instead of the old shared "consumer key and secret," the two sides now exchange a set of LTI 1.3 connection details — a client ID, a platform ID, an authentication request URL, an access-token URL, and a public keyset (JWKS) URL. Under the hood, Moodle follows the standard: a JSON Web Token (JWT) signed with asymmetric keys, OAuth 2 bearer tokens for service calls, and an OpenID Connect flow to start the launch. A teacher then drops an "External tool" activity into a course, and the learner launches straight into your player.

If your tool supports LTI Advantage dynamic registration, set-up gets much shorter. The administrator pastes your registration URL into the Tool URL field on the Manage tools page and selects "Add LTI Advantage". The tool then appears as pending until the administrator activates it, with no client IDs or keyset URLs copied by hand (Moodle 5.3 documentation). Teachers can also add a tool at course level with the "Add tool" button, if an administrator has given them that permission. For a vendor, supporting dynamic registration is the cheapest way to cut onboarding support tickets.

Moodle can also be the Tool — the thing being launched. Through the "Publish as LTI tool" enrolment plugin, a Moodle site can expose a course or a single activity so a different platform launches into it. That is how one institution shares a specialist Moodle course into another organisation's LMS. For a video vendor this matters less, but it is worth knowing Moodle plays both roles.

The reason LTI is the default for video is economic, and it is the same reason the standard exists. You implement the launch and grade passback once, certify it, and every Moodle site — moodle.org lists more than 160,000 registered ones (October 2026) — works through that single code path. Add the three LTI Advantage services and your tool can let teachers pick specific videos (Deep Linking), read the class roster (Names and Role Provisioning Services), and write scores back into Moodle's gradebook (Assignment and Grade Services). One honest caveat from Moodle's own design notes: when your tool passes grades back, the institution typically wants control over which gradebook columns are written — so plan grade passback as a negotiated, configurable thing, not an automatic firehose.

Figure 2. LTI works both directions. Moodle as Platform launches your hosted video tool into a course; Moodle as Tool publishes a course or activity into another platform. Both use the LTI 1.3 signed launch.

Path 2 — Packaged Content: SCORM, xAPI, And H5P

The second path does not connect a live tool at all. Instead you hand Moodle a self-contained package and Moodle stores, plays, and tracks it. This is the right path when the content must live inside the Moodle site — for example because the institution wants it to keep working with no dependency on your servers.

SCORM — the long-standing standard that packages a course into a zip any LMS can play and track — is a first-class Moodle activity. An administrator or teacher uploads a SCORM package (a .zip built to the SCORM 1.2 or SCORM 2004 data model), and Moodle's SCORM activity plays it and records the fixed SCORM data: completion, score, and time. Remember the limit that trips teams up: SCORM tracks a fixed data model inside the LMS launch, not "every interaction." Rich per-second video tracking needs xAPI. (See SCORM explained.)

xAPI — the Experience API, the newer standard that records learning as simple "actor–verb–object" statements like "Maria completed Module 3" — reaches Moodle in two ways. First, H5P, the open interactive-content format now built into Moodle core, emits xAPI statements from its activities; H5P's Interactive Video, for example, fires xAPI statements as a learner plays, answers in-video questions, and finishes, and Moodle uses those statements to put a grade in the gradebook. Second, Moodle's xAPI log store plugin (logstore_xapi) converts Moodle's own events into xAPI statements and forwards them, in scheduled batches, to an external Learning Record Store (LRS) — the database that holds xAPI statements — such as Learning Locker or Watershed. That is how a video tool's interaction data can leave Moodle and join cross-platform analytics. Check one thing before you depend on it: as of October 2026, the logstore_xapi listing on moodle.org gives no compatibility list for Moodle 4.5 or the 5.x branches, and users' questions about those versions are still open there. Test it on your customer's exact branch, or plan a small forwarding service that reads events through the web-services API. On the LRS side, xAPI 2.0 has been an IEEE standard (IEEE 9274.1.1-2023) since October 2023, so confirm which xAPI version your LRS expects and which one your activities emit. For video specifically, design your statements against the xAPI Video Profile so played, paused, seeked, and completed are captured consistently (see tracking video with the xAPI Video Profile). If you are still deciding which standard to package or launch with, the four-way comparison of SCORM, xAPI, cmi5, and LTI maps each to the job it does best.

Figure 3. How video interaction data flows. An H5P or video activity emits xAPI statements; Moodle grades from them and, via the xAPI log store, batches them to an external LRS for cross-platform analytics.

Path 3 — Plugins: Changing How Moodle Itself Behaves

The third path reaches inside Moodle and changes it. A plugin is a PHP add-on, installed into a Moodle site, that runs as part of Moodle and can do things no external launch can: add a brand-new activity type, a custom report, a new repository that pulls video from your CDN, or a button on a course page. Because the plugin runs inside Moodle, it has deep access — and that is both its power and its cost.

Choose a plugin only when the integration genuinely has to live inside Moodle's own interface and data model. A native video activity that behaves exactly like Moodle's built-in activities, a repository plugin that lets teachers browse your video library from inside the file picker, or a report that renders your engagement analytics on a Moodle admin screen — these are real plugin jobs. The trade-off is ownership: a plugin is code you write in PHP, test against each major Moodle release (Moodle ships large versions on a regular cadence), and update when the platform's internal APIs change. You also distribute and support it, optionally through the Moodle plugins directory.

In code terms, a plugin is a folder in a fixed place in Moodle's tree: a custom activity module lives under mod/<name>, a report under report/<name>, a repository under repository/<name> (from Moodle 5.1 these folders sit inside a public/ directory). Each has a version.php that declares its component name, its own version and the minimum Moodle version it requires, a db/ folder for its tables, capabilities and web-service functions, and a lang/ folder for its strings. An administrator installs it from a ZIP under Site administration → Plugins → Install plugins, and Moodle runs its database upgrade steps. That is what "Moodle plugin integration" means in practice: your code becomes part of the customer's site and moves with each of their upgrades.

The common mistake here is reaching for a plugin when an LTI launch would have done the job with a fraction of the maintenance. A plugin couples you to Moodle's release cycle forever; an LTI tool is hosted once and works across LMSs. Build the plugin when "inside Moodle" is a hard requirement, not a nice-to-have.

Path 4 — Moodle API Integration: Driving Moodle From Outside With Web Services

The fourth path is for when another system — your back office, a data warehouse, a corporate portal — needs to read or write Moodle data programmatically. Moodle exposes a web-services API: an administrator enables web services, defines a service with the specific functions it may call, issues a token, and external code calls a REST endpoint at https://<your-moodle>/webservice/rest/server.php with that token. Functions exist to create users, enrol them, read course completion, fetch grades, and much more.

The setup is five steps in Moodle's admin screens:

1. Enable web services on the Advanced features page in Site administration.
2. Enable the REST protocol under Site administration → Server → Web services → Manage protocols.
3. Create an external service and add only the functions your integration calls.
4. Create a dedicated integration user with just the capabilities those functions need, and authorise it for the service.
5. Create a token for that user and that service.

A first call that proves the token works:

curl -X POST https://moodle.example.edu/webservice/rest/server.php \
  -d wstoken=YOUR_TOKEN \
  -d wsfunction=core_webservice_get_site_info \
  -d moodlewsrestformat=json

Send the token in the POST body, as above, not in the query string, so it does not end up in proxy and server access logs. The functions a video or learning product usually needs are core_user_create_users and core_user_get_users_by_field for accounts, enrol_manual_enrol_users and core_enrol_get_enrolled_users for enrolment, core_course_get_courses for the catalogue, core_completion_get_course_completion_status for completion, and gradereport_user_get_grade_items for grades. The full list for a given site, with parameters, is under Site administration → Server → Web services → API Documentation. When the function you need does not exist, the fix is a small local plugin that defines a new external function, which puts part of the work on the plugin path.

This path does not launch a learner anywhere and does not change Moodle's screens; it moves data in and out. A typical use for a video product is keeping enrolment and completion in sync with an external HR or content system. Treat the token like a password: scope the service to only the functions you need, transport over HTTPS only, and rotate it. As with LTI's roster and grade data, anything you pull through the API about real learners is regulated personal data — decide what you store and why before the first call.

A Worked Example: The Integration Math

Numbers make the path choice concrete. Suppose you sell an interactive-video assessment tool and you want it working inside Moodle, with scores in the gradebook.

Imagine you choose the plugin path because it feels "more integrated." A native Moodle activity plugin, built and hardened, is a real project — call it a conservative six engineer-weeks — and then it never stops costing, because each major Moodle release can change internal APIs:

Plugin path     = 6 eng-weeks to build
                + re-test & patch against each major Moodle release, forever
                + you only support Moodle — Canvas/Blackboard need separate work

Now compare the LTI path. You implement LTI 1.3 plus Assignment and Grade Services once — one launch flow, one JWT verifier, one grade-passback client — and certify it:

LTI path        = 1 implementation (launch + AGS)   ≈ 4-6 eng-weeks
                + 1 maintenance track for the standard, not per Moodle release
New Moodle site = admin configuration                ≈ minutes, not weeks
Other LMSs      = the same code path already works (Canvas, Blackboard, ...)

The LTI build is similar up front but diverges fast afterward: the plugin binds you to one platform's release cycle and one platform only, while the LTI tool is hosted once and launches into every conformant LMS. For a hosted video product that wants more than one customer, that difference is the whole decision.

When To Use Which Path

The four paths answer four different questions, and the cleanest way to choose is to ask what the integration actually has to do.

The honest summary: launch with LTI when you are a live, hosted video tool many institutions plug into — this is the default. Package with SCORM or xAPI/H5P when the content must be self-contained inside Moodle. Write a plugin only when the integration must live inside Moodle's own screens. Use the web-services API to sync data with outside systems. Many real products combine paths — for example, an LTI launch for the live player plus the xAPI log store feeding an external LRS for analytics.

Figure 4. The four paths compared. LTI is the default for a hosted video tool; packaged content lives inside Moodle; a plugin changes Moodle itself; the web-services API syncs data with outside systems.

Common Mistakes That Cost Real Time

A handful of Moodle-integration errors recur on projects, and each is cheap to avoid up front.

The first is building a plugin when an LTI launch would do. A plugin ties you to Moodle's release cycle and to Moodle alone. If your tool is hosted and you want it across LMSs, start with LTI 1.3 and only build a plugin for what genuinely must live inside Moodle.

The second is building against LTI 1.1 in 2026. LTI 1.1's OAuth 1.0a shared-secret signing is the model LTI 1.3 was built to replace: 1EdTech ended all support for LTI 1.0 and 1.1 on 30 June 2022 and has formally deprecated OAuth 1.0a across its specifications. Target LTI 1.3 plus LTI Advantage; treat 1.1 as legacy you support only under contract.

The third is assuming "watched 100%" equals "completed" in the gradebook. Completion in Moodle is whatever the activity reports — a SCORM completed flag, an xAPI statement, or a manual rule. Decide your completion definition deliberately; do not assume the player's progress bar maps to a grade.

The fourth is "it worked in the authoring tool but not in Moodle." A SCORM package that plays in a desktop preview can fail in Moodle's SCORM player over differences in the manifest, file paths, or the data model version. Test in a real Moodle site, not just the authoring preview.

The fifth is treating roster and grade data as low-stakes. The roster (via NRPS) and grades (via AGS) and anything pulled through the web-services API are real student identities and results — personal data under the EU's GDPR (Regulation (EU) 2016/679), under FERPA where US student records are involved, and under 152-FZ for a Russian audience. Decide what you store, why, and for how long before your first call.

Moodle Integration FAQ

What is Moodle API integration?

Moodle API integration is connecting another system to Moodle through its web-services API: an administrator enables web services and the REST protocol, creates a service with the allowed functions, and issues a token that your system sends to /webservice/rest/server.php to create users, enrol them, and read completions and grades.

How do I integrate a plugin with Moodle?

You write the plugin in PHP in the folder for its type (for example mod/<name> for an activity, under public/ from Moodle 5.1), declare the supported Moodle versions in version.php, and the administrator installs it under Site administration → Plugins → Install plugins. Test it on every Moodle branch your customers run.

What integrations does Moodle support?

Moodle supports four kinds of integration out of the box: LTI 1.3 and LTI Advantage external tools, SCORM 1.2/2004 and H5P packages (with xAPI), PHP plugins of many types (activities, blocks, reports, repositories, authentication, enrolment), and the web-services API over REST.

Does Moodle support xAPI?

Yes, in two ways: H5P activities in Moodle core emit xAPI statements that Moodle uses for grading, and the community logstore_xapi plugin forwards Moodle events as xAPI statements to an external LRS. Check that plugin's compatibility with your Moodle branch before relying on it.

Can Moodle be an LTI provider?

Yes. The "Publish as LTI tool" enrolment plugin lets a Moodle site publish a course or a single activity as an LTI tool that another platform launches, so Moodle can act as both the Platform and the Tool.

How do I add a SCORM package to Moodle?

Add a SCORM package activity to a course and upload the .zip built to SCORM 1.2 or SCORM 2004; Moodle plays it and records completion, score and time. Test the package in a real Moodle site, not only in the authoring tool's preview.

How do I build a custom activity module for Moodle?

A custom activity module is a plugin under mod/<name> with its own database tables, capabilities, settings form and view page. Build one only when the activity must behave like Moodle's built-in activities; for a hosted video tool, an LTI 1.3 launch usually does the same job with far less maintenance.

Which Moodle version should an integration target in 2026?

Target Moodle 5.3, the LTS released on 5 October 2026, and test on 4.5 LTS and 5.2, which many institutions still run. Moodle 5.2 and 5.3 need PHP 8.3 or later.

Build vs Buy: Where Moodle Integration Fits

Lead with the business question. "Integrating with Moodle" is rarely a buy decision and rarely a single build — it is choosing the smallest path that does the job. The expensive failure is over-building: a custom plugin where a configured LTI launch would have cost a fraction of the ongoing maintenance and served every other LMS for free.

If you are building a video or interactive tool, the bounded, well-scoped build is LTI 1.3 plus the Advantage services you need: the OIDC launch, JWT verification, key/JWKS handling, and an AGS grade-passback client. Open-source LTI libraries exist for most languages and cut the plumbing. Reserve plugin work for the parts that truly must live inside Moodle, and use the web-services API only for data sync. If you are running Moodle yourself and the question is whether to extend it or move to a custom build, that is the broader trade-off in build vs buy vs extend an LMS. To pick your path the first time, download the Moodle integration decision worksheet.

Where Fora Soft Fits In

Fora Soft has built video learning, streaming, conferencing, and interactive-player software since 2005, across 250+ shipped projects. On Moodle work, the recurring decision we help teams make is the one at the centre of this article: launch a hosted video tool with LTI 1.3 when it must serve many institutions, package with SCORM or xAPI/H5P when content has to live inside Moodle, and reach for a plugin only when behaviour must live inside Moodle's own screens. Our work usually sits at the video and interactive layer — an interactive-video tool that launches cleanly into a Moodle course, reads the roster through NRPS, and writes assessment scores back through AGS, with per-second engagement tracked via the xAPI Video Profile into an LRS. We treat the launch and grade-passback path as something that must hold up in a real institution's Moodle site at volume, not just pass a sandbox test. Our virtual classroom development team builds LTI 1.3 tools that launch into Moodle with roster sync and grade passback, and when a programme outgrows Moodle itself our custom LMS development team builds the platform it needs. When the Moodle integration is one part of a wider product, such as a training portal with live classes, recordings and analytics, our e-learning software development team scopes the whole platform, so the Moodle connection is designed in from the start.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook, 9,000+ pages, that walks the whole video stack your tool runs on once Moodle has handed the learner over: encoding, delivery, sound, and AI. Volume 3 covers the players, ABR ladders, CDNs, and WebRTC that decide what the learner actually sees inside that LTI launch; volume 1 covers the encoding behind lecture video, and volume 4 the audio, loudness, and captions that make a recorded class usable. Work through them and you can design and build the video tool an institution plugs into Moodle, not just configure one. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. IMS Global Learning Consortium (1EdTech). Learning Tools Interoperability (LTI) Core Specification, Version 1.3, IMS Final Release, 16 April 2019. https://www.imsglobal.org/spec/lti/v1p3 (Tier 1 — primary specification; the LTI 1.3 launch model, Platform/Tool roles, OIDC login, signed JWT, and the message types Moodle implements.)
2. IMS Global Learning Consortium (1EdTech). Learning Tools Interoperability (LTI) Advantage Implementation Guide, Version 1.3, IMS Final Release. https://www.imsglobal.org/spec/lti/v1p3/impl (Tier 1 — primary specification; Deep Linking, Names and Role Provisioning Services, and Assignment and Grade Services that Moodle exposes.)
3. ADL Initiative. Experience API (xAPI) Specification, Version 1.0.3 (Part 1: About; Part 2: Statements). https://github.com/adlnet/xAPI-Spec (Tier 1 — primary specification; the actor–verb–object statement model used by H5P and Moodle's xAPI log store.)
4. ADL Initiative. SCORM 2004 4th Edition (Content Aggregation Model; Run-Time Environment). https://adlnet.gov/projects/scorm/ (Tier 1 — primary specification; the SCORM data model — completion, score, time — that Moodle's SCORM activity tracks.)
5. Moodle Pty Ltd. LTI 1.3 support (Moodle Developer Documentation). https://docs.moodle.org/dev/LTI_1.3_support (Tier 4 — first-party engineering documentation; Moodle's LTI 1.3 security model, the client ID / platform ID / auth-request / access-token / public-keyset connection details, and the gradebook-column note for grade passback.)
6. Moodle Pty Ltd. LTI External tools (Moodle Documentation, 5.3). https://docs.moodle.org/503/en/LTI_External_tools (Tier 4 — first-party documentation; configuring an external tool under Site administration, manual tool configuration, and where launch details live; LTI Advantage dynamic registration through the Tool URL field and course-level "Add tool".)
7. Moodle Pty Ltd. Publish as LTI tool (Moodle Documentation, 5.x). https://docs.moodle.org/502/en/Publish_as_LTI_tool (Tier 4 — first-party documentation; Moodle acting as an LTI Tool, publishing a course or activity to a consuming platform.)
8. Moodle Pty Ltd. Plugin types (Moodle Developer Resources, 5.2). https://moodledev.io/docs/5.2/apis/plugintypes (Tier 4 — first-party documentation; the range of Moodle plugin types — activity modules, repositories, reports, enrolment, authentication — that the plugin path uses.)
9. Moodle Pty Ltd. Experience API (xAPI) subsystem (Moodle Developer Resources). https://moodledev.io/docs/apis/subsystems/xapi (Tier 4 — first-party documentation; how Moodle generates and handles xAPI statements internally.)
10. Moodle community. Logstore xAPI (Moodle plugins directory). https://moodle.org/plugins/logstore_xapi (Tier 4 — first-party plugin documentation; converting Moodle events into xAPI statements and batching them to an external LRS.)
11. H5P. H5P and xAPI (documentation). https://h5p.org/documentation/x-api (Tier 4 — first-party tooling documentation; H5P Interactive Video emitting xAPI statements for play, in-video questions, and completion.)
12. Moodle US. Using the Web Services API in Moodle. https://supportus.moodle.com/support/solutions/articles/80001016973 (Tier 4 — first-party documentation; enabling web services, defining a service, issuing a token, and the REST endpoint for external data access.)
13. Moodle HQ. Releases (Moodle Developer Resources). https://moodledev.io/general/releases (Tier 4 — first-party documentation; release dates and support windows for 4.5 LTS, 5.2 and 5.3 LTS, and the April/October release cadence. Checked October 2026.)
14. Moodle HQ. Moodle 5.2 release notes. https://moodledev.io/general/releases/5.2 (Tier 4 — first-party documentation; 20 April 2026 release, PHP 8.3 minimum, upgrade from 4.4 or later.)
15. Moodle. Moodle statistics. https://moodle.org/stats/ (Tier 4 — first-party data; 161,020 registered sites, 412 million users, 242 countries when checked in October 2026.)
16. 1EdTech. LTI Security Announcement and Deprecation Schedule. https://www.1edtech.org/lti-security-announcement-and-deprecation-schedule (Tier 1 — standards body; end of support for LTI 1.0/1.1 on 30 June 2022 and deprecation of OAuth 1.0a.)
17. ADL Initiative. xAPI Officially Becomes a Published IEEE Standard, 22 November 2023. https://adlnet.gov/news/2023/11/22/xAPI-Officially-Becomes-a-Published-IEEE-Standard (Tier 1 — standards owner; xAPI 2.0 as IEEE 9274.1.1-2023.)

Where Moodle's implementation documentation (Tier 4) could differ from the standards, the article follows the IMS/1EdTech LTI 1.3 specs and the ADL SCORM/xAPI specs for the standards claims (the signed-JWT launch, the LTI Advantage services, the SCORM fixed data model, and the xAPI statement model), and uses Moodle's docs only for "what actually ships in Moodle."