Make Your Courses Show Up Inside Canvas and Moodle

A university, a corporate training department, or a school district almost never runs one single learning system in isolation. They have a primary LMS, Canvas, Moodle, Blackboard, that’s the institutional system of record, where grades get recorded and administrators run reports. When they want to bring in outside content, a specialized course built somewhere else, the realistic ask isn’t “replace your Canvas instance with ours.” It’s “let our content show up inside the Canvas your students already use, and let the grade flow back automatically.” That specific, narrower integration is what LTI actually solves, and it’s worth looking at exactly how a real implementation of it works.

What LTI actually is, and why it exists

LTI, Learning Tools Interoperability, is an open standard, maintained by 1EdTech (formerly IMS Global), that lets one learning platform (a “tool,” in LTI’s own terminology) launch content inside another learning platform (a “platform,” confusingly, in the same terminology) with a secure, standardized handshake. A student clicks a link inside Canvas, gets securely authenticated and passed through to the external tool without a separate login, works through that content, and, critically, the external tool can pass a grade back to Canvas’s own gradebook automatically, through a piece of the standard called AGS (Assignment and Grade Services).

This is precisely why LTI matters for the institutional world in a way that goes beyond typical course-platform interoperability. A university’s Canvas instance is the system a registrar, an accreditation body, and an instructor’s own gradebook all depend on. Content that can’t report a grade back into that system of record is effectively invisible to the institution’s actual processes, no matter how good the content itself is.

Coexistence, not replacement, the opposite instinct from migration

It’s worth contrasting this directly against the LMS migration wizard covered earlier in this series, because the two features solve genuinely opposite problems, and confusing them leads to the wrong expectation about what LTI actually does. The migration wizard exists to move a course off LearnDash, Tutor LMS, or LifterLMS and onto Learnomy entirely, the old platform stops being the system of record, and Learnomy becomes the new home for that content permanently.

LTI does the reverse: it lets Learnomy content stay exactly where it is, on Learnomy’s own infrastructure, while being launched from inside an institution’s existing, permanent system of record, their Canvas, their Moodle, with no expectation that the institution will ever migrate away from that system. Nobody’s replacing Canvas with Learnomy in this scenario; Canvas keeps being the registrar’s system of truth indefinitely, and Learnomy is a specialized content provider plugged into it through a standardized door.

Recognizing which of these two situations you’re actually in matters practically. A course creator building a standalone academy, competing directly with LearnDash or Tutor LMS for course creators who want to run their own independent platform, is squarely in migration-wizard territory. A course creator or content provider trying to sell specialized content into institutions that already have, and will keep, their own LMS is squarely in LTI territory. Building for the wrong one wastes effort: an institution isn’t going to migrate their entire Canvas deployment to adopt your content, and an independent course creator building their own academy from scratch has no institutional Canvas to integrate with in the first place.

The real tool-registration screen

Here’s the actual LTI 1.3 Platforms screen from a working Learnomy install, showing exactly what a site owner sees when setting this up:

The page splits cleanly into two halves, and the structure itself tells you this was built by someone who understood the actual LTI 1.3 handshake, not just the marketing concept of “LTI support.” The top half, “Tool Details (Give These to the Platform),” shows the URLs Learnomy exposes as an LTI tool: a real OIDC Login URL, Launch (Redirect) URL, and Public Keyset (JWKS) URL, each a genuine, working endpoint on this specific install (/wp-json/learnomy-pro/v1/lti/login, /lti/launch, and /lti/jwks), plus an actual RSA or Ed25519 public key in PEM format. These are the exact values an institution’s Canvas or Moodle administrator needs to paste into their own system when registering Learnomy as an external tool.

Why the terminology-translation detail is the real proof of quality

The bottom half of that same screen, “Add a Platform”, is where things get genuinely impressive, in a way that’s easy to miss unless you’ve actually tried to configure LTI between two real systems before. Look at the help text under each field:

“Client ID, Identifies this tool to the platform. The platform generates it when you register Learnomy - Moodle shows it as ‘Client ID’, Canvas as the developer key ID.”

“OIDC Auth Login URL, Where we send the learner to start the login handshake. Moodle calls this the ‘Initiate login URL’; Canvas calls it the ‘OIDC Initiation URL’.”

“Platform JWKS URL, The platform’s public keys, used to verify that a launch really came from it. In Moodle it is the ‘Public keyset URL’; in Canvas, the ‘Public JWK URL’. Usually ends in /certs or /jwks.”

This is the single most telling detail in the entire feature. LTI 1.3 is a genuine open standard, but every major platform that implements it, Canvas, Moodle, Blackboard, Schoology, uses its own internal terminology for the exact same underlying concept, because each platform’s admin UI was built by a different team with its own naming conventions. A site owner setting up LTI for the first time, staring at a field labeled “OIDC Auth Login URL,” has no way of knowing that’s the same thing Canvas’s own admin screen calls the “OIDC Initiation URL,” unless someone has already done the work of mapping every field across every major platform’s actual UI labels.

That mapping only exists in the interface if the team building it actually configured this integration against real Canvas and real Moodle instances, hit the naming confusion firsthand, and wrote the fix directly into the help text, not something you’d get from reading the LTI specification document alone, which defines the technical field names, not what Canvas or Moodle happen to call them in their own admin screens.

Demo data, so you can see it work before configuring anything real

There’s a further detail confirming this was built and tested against real integrations: the underlying system includes a seeded demo platform with its own cleanup routine for tearing it down. That’s infrastructure built specifically to let a developer or a curious admin see a working LTI launch end-to-end without first configuring a real Canvas or Moodle connection, evidence that the team building this actually exercised the full launch flow themselves during development, rather than only ever testing the tool-details half of the page in isolation.

Grade passback: the feature that makes this an institutional integration, not a novelty

The module’s own metadata states its scope precisely: “Let an LMS (Canvas, Moodle, Blackboard) launch Learnomy courses as an LTI 1.3 tool, with AGS grade passback.” That last piece, AGS, Assignment and Grade Services, is what elevates this from “students can click through to our content” to “our content participates in the institution’s actual grading system.”

Without grade passback, an instructor using Learnomy content inside their Canvas course would have to manually check a separate Learnomy report and hand-enter each student’s score into the Canvas gradebook, exactly the kind of duplicated, error-prone manual process that makes an integration not worth using in practice, no matter how good the underlying content is. With grade passback, a student completes a quiz inside the Learnomy-hosted content, launched from within Canvas, and their score flows automatically into the Canvas gradebook column the instructor already set up, the same gradebook column every other assignment in that Canvas course reports to.

The “Resource link to Course map”, solving the real one-platform-many-courses problem

One more field on that real registration form deserves attention, because it solves a genuinely non-obvious problem: “Resource link to Course map, Optional. One mapping per line as ‘resourcelinkid = course_id’, so one platform can launch different courses per LMS module. Checked before the default course.”

Think through why this matters. A single institution’s Canvas instance might have several different Canvas courses, each wanting to launch a different Learnomy course through the same LTI tool registration, a Biology 101 Canvas course launching one Learnomy course, a Chemistry 201 Canvas course launching a different one, both through the same underlying LTI connection between the two institutions. Without a way to distinguish which specific Canvas assignment link should route to which specific Learnomy course, you’d need a completely separate LTI tool registration for every single course pairing, a maintenance nightmare for any institution using more than one Learnomy course. The resource-link mapping solves this with a simple lookup table: this specific resource link goes to this specific course, checked before falling back to a single default course for anything not explicitly mapped.

Why “no platforms registered yet” is the right thing to see

On this particular install, the Registered Platforms table at the bottom reads plainly: “No platforms registered yet.” That’s not a bug or an incomplete feature, it’s the honest state of a genuinely fresh install where no institution has actually been connected yet. The value of showing this empty state clearly, rather than something vague or broken-looking, is the same principle seen elsewhere in this series (the honest “Not configured” messaging on push notifications, the honest “$0.00, no revenue recorded” messaging on the analytics dashboard): a feature that’s correctly built but not yet configured should say so plainly, not present a confusing or misleading screen that leaves an admin wondering whether something is broken.

Why LTI 1.3’s security model is a genuine improvement, not just a version bump

It’s worth explaining why the fact that this is built on LTI 1.3 specifically, rather than the older LTI 1.1, is a meaningful security claim and not just a marketing detail. LTI 1.1 authenticated launches using OAuth 1.0a with a shared secret, a single string, configured on both sides, that if ever leaked or intercepted, could be used to forge a launch claiming to be any student or instructor. LTI 1.3 replaced that with OIDC (OpenID Connect) and public-key cryptography: the JWKS URL and public key visible on the real screen above are exactly this mechanism in action. Instead of a shared secret both sides have to protect equally, the platform verifies every launch’s signature against Learnomy’s published public key, and Learnomy verifies the platform’s own launches the same way in reverse. Neither side ever needs to transmit or store the other’s private signing key.

This matters concretely for the kind of institution likely to be on the other end of this integration. A university’s IT security team evaluating whether to connect an external tool to their Canvas instance is going to ask specifically which LTI version is in use, precisely because the 1.1-versus-1.3 distinction is a known, meaningful security upgrade in this space, an institution with any real security review process is likely to require 1.3 or reject the integration outright. Building on 1.3 from the start, rather than the older and simpler-to-implement 1.1, is a sign this was built to actually pass that institutional security review, not just to demo working.

How a refused launch actually gets surfaced

The webhook system covered elsewhere in this series includes a dedicated event category for this integration: “LTI, Lti Link Refused.” That’s a specific, real signal worth understanding, because a refused launch is exactly the kind of failure an institution’s IT team will ask about the first time a student reports “the link from Canvas didn’t work.” Rather than that failure disappearing into a server log an admin would have to go dig through manually, it’s available as a webhook event, meaning a site owner can route “LTI Link Refused” straight to a Slack channel or a support ticket system, the same way any other operational event in this platform can be, and get an active heads-up the moment an institutional connection starts failing rather than discovering it only when the institution’s own users start complaining.

That’s a small detail with an outsized practical value for exactly the audience LTI serves: institutional IT relationships where “our integration silently broke and nobody noticed for two weeks” is a genuinely damaging outcome, both for the immediate students affected and for the credibility of the whole partnership going forward.

Three real situations where LTI is the actual requirement, not a nice-to-have

The university department licensing specialized content into an institutional Canvas. A computer science department wants to offer a specific, specialized course, say, a cybersecurity certification track, built and maintained by an outside content provider, but the university’s registrar and academic records only recognize grades that land in the institution’s own Canvas gradebook. LTI with grade passback is the only integration model that satisfies both requirements at once: specialized outside content, institutional-grade-of-record compliance, a scenario our guide to the best WordPress LMS for universities and higher education covers in more depth.

The corporate training team whose compliance system already runs on an existing LMS. A large employer might run mandatory compliance training through an established corporate LMS for audit and reporting reasons, while wanting to license better, more specific content from an outside vendor for one particular training topic. LTI lets that specific content launch from inside the existing corporate LMS, with completion and scores flowing back to the system HR and compliance already report from, rather than requiring employees to juggle two separate logins and two separate completion records.

The multi-institution consortium sharing one content library. A group of schools or training providers that share access to a common content library, each running their own separate LMS, is exactly the scenario LTI as an open standard was designed for, the content provider builds once, registers as an LTI tool, and each member institution connects their own Canvas, Moodle, or Blackboard instance independently, using the same tool-details values but their own separate platform registration.

Common questions before you set this up

Do I need a separate LTI registration for every institution I work with? Based on the structure of this screen, no, you register Learnomy once as an LTI tool (the Tool Details half never changes), and then add a separate platform entry, with its own issuer, client ID, and keys, for each institution that wants to connect. The tool side is a single, stable configuration; the platform side grows by one row per institutional relationship.

What happens if a student launches a resource link with no matching course mapping? Per the field description, “Checked before the default course”, an unmapped resource link falls back to whatever course is set as the Default Course ID for that platform, rather than failing outright. That’s a sensible default: a missing mapping degrades to a single fallback course rather than breaking the launch entirely.

Is LTI 1.3 backward-compatible with older LTI 1.1 integrations some institutions might still use? The module is explicitly versioned as LTI 1.3, the current major version of the standard, and marked BETA in the module catalog covered elsewhere in this series. If an institution you’re working with is still on an older LTI version, that’s worth confirming directly rather than assuming compatibility, since 1.3 introduced a meaningfully different security model (OIDC-based) from earlier LTI versions.

Does a grade passback failure block the student’s access to the content? Nothing in what’s described suggests grade passback is a gate on content access, it reads as a reporting mechanism running alongside the actual content launch, meaning a temporary grade-sync issue shouldn’t be expected to lock a student out of content they’re otherwise entitled to launch.

Can I test this without a real Canvas or Moodle account? The seeded demo platform mentioned in the underlying build notes exists specifically for this, confirming the module includes infrastructure for testing a full launch cycle without first securing access to a real institutional Canvas or Moodle instance to register against.

What to verify before committing to an institutional LTI relationship

• Register a real test platform end-to-end before promising an institution anything. Use the demo platform infrastructure, or set up a free Canvas or Moodle sandbox instance, and walk through the actual registration and launch flow yourself before an institutional partner is depending on it working.
• Confirm grade passback lands in the exact gradebook column expected. This is the single most valuable and most failure-prone part of the integration, test it directly with a real assignment and a real test student score, don’t assume it from the feature description alone.
• Plan your resource-link-to-course mapping before an institution asks for multiple course connections. If you know from the start that an institutional partner will want several different Canvas courses each launching different Learnomy content, set up that mapping table deliberately rather than improvising it after the first course is already live.
• Ask your institutional partner directly which LTI version and which platform (Canvas, Moodle, Blackboard, or another) they run, and confirm that specific combination against your own registration, since the terminology-mapping help text covered above shows real, platform-specific differences that are worth double-checking for whichever platform you’re actually connecting to.

The genuinely convincing detail in this whole feature isn’t the existence of an “LTI support” checkbox, plenty of platforms claim that. It’s the field-by-field terminology translation between what Learnomy calls something and what Canvas or Moodle calls the exact same field in their own admin screens. That detail only exists in a product built by a team that actually sat down and configured this against real institutional systems, hit the confusion a first-time integrator would hit, and fixed it directly in the help text rather than leaving that discovery to every single site owner who tries this afterward.

Integrations like this live or die on the API surface underneath them, which is why our comparison of the best LMS platforms with REST API and developer features looks specifically at what each plugin actually exposes rather than what its features page claims.

Why “BETA” here is honesty, not a red flag

One label worth addressing directly: the Modules screen covered elsewhere in this series marks LTI 1.3 with both a PRO and a BETA tag, side by side. It would be reasonable to read “BETA” as a reason for caution, and to some degree it should prompt exactly that, a beta label on any feature means test it thoroughly on your own before an institutional partner depends on it, which is precisely the advice given throughout this article regardless of the label.

But it’s worth reading that label the other way too: a vendor willing to mark a real, functioning, security-conscientious integration as “BETA” rather than quietly shipping it as a fully mature, unqualified feature is making an honest claim about its maturity level, not hiding a weaker feature behind confident marketing language. Given everything else demonstrated here, the correct security model, the seeded test infrastructure, the platform-specific terminology mapping, the dedicated failure-event webhook, this reads as a genuinely capable integration that simply hasn’t yet accumulated the track record across enough real institutional deployments to drop the beta qualifier, not a feature that’s fundamentally unfinished. The honest labeling is, if anything, more reassuring than a feature this new and this specific to institutional integration claiming full production maturity on day one.

The bigger pattern: interoperability as a genuine strategy, not a checkbox

Zoom out, and LTI takes its place alongside SCORM, QTI, and xAPI, all covered in the “Standards & interop” category referenced in the SCORM article elsewhere in this series, as part of a deliberate pattern rather than an isolated feature. A platform that takes interoperability seriously as a strategy builds each of these standards with the same underlying discipline: real security models, real test infrastructure, and integration deep enough to actually satisfy the institutions and organizations that live by these standards, rather than a shallow, checkbox-level implementation of each one built just to claim compatibility on a features page.

That pattern matters because it’s predictive. A vendor that got the platform-terminology mapping right for LTI, and the zip-bomb defense right for SCORM, is more likely to have gotten the equivalent hard edge cases right for QTI and xAPI too, even without walking through each of those in the same level of detail here. Consistency of engineering discipline across a whole category of related features is a stronger signal of quality than any single feature examined in isolation, and it’s exactly the kind of signal you can only see by actually looking closely at more than one of a platform’s claimed integrations, the way this series has done across exam engines, certificates, payments, and now standards interoperability.