Moodle LTI Advantage integration

What a Moodle LTI Advantage integration connects

LTI Advantage (LTI 1.3) is the supported method for connecting Moodle to other learning platforms in both directions. Use it to launch an external tool from inside a Moodle course, or to make Moodle courses and activities available to another platform. For the outbound case, Moodle's core Publish as LTI tool enrolment method handles publishing to platforms you have pre-registered. Legacy LTI 1.1 and 2.0 tools are deprecated, so any new work should target LTI Advantage, even if an older vendor still offers a 1.1 launch.

The first direction serves a course team that wants an external tool, such as a publisher's content, an assessment engine or a lab environment, to appear as an activity inside a Moodle course. In this case your Moodle instance is the platform and the external vendor is the tool. You will register the tool in Moodle, decide which courses and categories can add it, and confirm what grade or roster data the tool may receive. Ask the vendor which LTI Advantage services it needs, such as Names and Role Provisioning or Assignment and Grade Services, because these determine what Moodle must release.

The second direction serves a platform owner whose content lives in Moodle but whose learners sign in somewhere else. Publish as LTI tool lets you expose selected courses or activities to a partner platform that has been registered with your Moodle site. Publishing then works without changes on the partner side each time new content is published, which is the main operational benefit over manual setup per course. Decide early which content is in scope, which platform identities you will trust, and who approves each registration.

Both directions depend on the same trust relationship: each side must hold the other's keys, endpoints and deployment identifiers, and both must agree on what user and course data crosses the boundary. Before scoping, confirm your current Moodle release and its support window, since LTI behaviour and plugin compatibility are tied to the version you run. The scoping questions that follow ask you to name the tools or platforms, the data they need and the owners who will maintain each registration.

Prerequisites before enabling LTI Advantage in Moodle

LTI Advantage connects Moodle to external tools over HTTPS, so the platform version, server stack and trust agreements all have to be settled before any tool is registered. The cards below cover the Moodle requirements, the endpoints and accounts each side needs, and the vendor and key decisions that determine who can change a live integration.

Moodle version and server stack

Confirm the target Moodle release before choosing the server stack. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Check the release notes for the exact list before building the environment.

Upgrade starting versions

A site can only move to Moodle 5.1 from Moodle 4.2.3 or later, and to Moodle 5.3 from Moodle 4.4 or later. If your instance is older, plan intermediate upgrades first, since each step may also require a newer PHP or database version. Confirm your current version and whether an existing LTI configuration needs review during those steps.

Web server document root at /public

From Moodle 5.1, the web server document root must point to the new public directory rather than the main Moodle folder. If it does not, the site can show directory listings or errors. Check this on every web node, reverse proxy and staging copy, and confirm that LTI launch URLs resolve correctly through the same host name users will see.

HTTPS endpoints on both platforms

LTI 1.3 launches, tool keys and service calls depend on HTTPS endpoints that the other platform can reach. List the Moodle base URL, the tool's launch, login initiation, redirect and JWKS URLs, and any Advantage service endpoints the tool needs. Confirm certificates are valid and trusted by both sides, and that firewalls and proxies allow the traffic in both directions.

Accounts and admin rights on each side

Name the Moodle administrator who will create and maintain the external tool registration, and the matching administrator in the tool vendor's platform or account. Agree which roles can view, edit and delete registrations. Confirm that each account has the rights needed to create the registration and to test launches, and that shared or generic admin accounts are not used for production changes.

Vendor support for LTI 1.3 and Advantage

Before committing to a tool, confirm in writing that the vendor supports LTI 1.3 and the Advantage services you need, such as deep linking, names and roles provisioning, and assignment and grade services. Ask which of these are included for your plan and whether any legacy LTI 1.1 mode is still required. Note any vendor features that depend on other products.

Ownership of registration and key material

Agree in writing who owns the tool registration, the client ID, deployment IDs and the signing and public key material, and who can rotate them. Decide who stores private keys, how they are shared between teams, and what happens when a vendor contact leaves. Clear ownership prevents an outage when a key expires or a registration needs to change after an upgrade.

How launches and publishing differ in each direction

In the inbound direction, Moodle is the platform and an external tool is launched from inside a course. Three things must exist before a learner can open the tool: a tool registered in Moodle, a deployment that connects that registration to your Moodle site, and a placement that puts the tool into a specific course. Each one has a different owner. The tool vendor usually supplies the registration details, a Moodle administrator creates the deployment, and course designers add the placement. Confirm the exact administration menu for your Moodle version before you write the runbook, because the screens and settings differ between releases.

For each inbound tool, decide which roles may launch it and which course areas may hold a placement. Decide what identity data Moodle sends at launch, such as name, email address or course membership, and check that the tool's privacy terms allow it. Decide whether grades return to the Moodle gradebook. That depends on the tool supporting the LTI Advantage services for grades and on how you configure them in Moodle, so ask the vendor to confirm it in writing. Each decision changes what the tool can see, so record it before the first course uses the tool.

In the outbound direction, Moodle is the tool. Courses and activities are offered to other platforms through the core Publish as LTI tool enrolment, which supports LTI Advantage. The plugin's language strings state that content can be published to pre-registered platforms and that no change is needed on the platform each time new content is published. They also state that legacy LTI 1.1 and 2.0 tools are deprecated, so do not design new publishing work around them. The decisions here are which external platforms are pre-registered, which courses or activities are offered to them, and who in your organization owns each platform relationship.

Scope the two directions as separate work items. Inbound work depends on a tool vendor's registration and on course design. Outbound work depends on a trust relationship with an external platform and on what your Moodle courses should expose to it. They have different owners, different test cases and different failure modes. An inbound launch problem appears to a learner inside a course, while an outbound problem may only surface when an external platform administrator tries to add your content. Estimating them as one piece of work hides those differences, so each direction needs its own acceptance test and its own sign-off.

Configure LTI Advantage tools and publishing in sequence

This sequence takes a Moodle site from a confirmed release and HTTPS endpoints to a working LTI Advantage link in either direction, with each step closed by a check that proves it worked. It runs the same way whether Moodle launches an external tool or publishes its own courses to another platform.

Confirm the Moodle release and HTTPS endpoints
The integration team confirms the exact Moodle version in the site administration pages and checks it against the release notes for the version in use, since LTI settings and plugin behavior can differ between releases. They also confirm that every endpoint the other platform will call is reachable over HTTPS with a valid certificate, and that the web server document root points to the correct directory for that release. For Moodle 5.1 and later, the document root must point to the new /public directory, or the site may show directory listings or errors. The step is done when the version is recorded, a plain HTTPS request to the site's base URL returns the expected page, and the platform team confirms the endpoints are reachable from outside the local network.
Enable the LTI and enrolment options for the direction
The Moodle administrator enables the LTI capabilities that match the chosen direction. For launching external tools into courses, the external tools and LTI Advantage settings are enabled under the site's plugin administration. For publishing Moodle courses to other platforms, the Publish as LTI tool enrolment method is enabled in the course enrolment plugins, and the site confirms that the legacy LTI 1.1 and 2.0 options are not used for new work, because the plugin documentation treats them as deprecated. The administrator should verify the exact setting names and their location in the plugin language strings for the installed version. The check is that the relevant plugin appears as enabled in the plugin overview and that the settings page for it loads without errors.
Register the external tool with issuer and client details
For inbound launches, the Moodle administrator creates a tool configuration using the issuer, client identifier, deployment identifier and the tool's launch, login initiation and public key endpoints supplied by the external vendor. These values must match exactly, including trailing slashes and case, because a mismatch usually produces a generic authentication failure rather than a clear message. The administrator also decides which courses or categories the tool is available in and which privacy settings control what user data is sent. Confirm each field name against the vendor's documentation, since labels vary by tool and by Moodle release. The check is that the tool shows as active in the external tools list and that the tool's configuration page saves without validation errors.
Exchange keys and endpoints with the other platform
The two sides exchange their public keys or key set endpoints, so each can verify signed messages from the other. Moodle exposes its own endpoints and key details for the platform to use, and the vendor supplies its endpoints and keys to Moodle. The integration team records which key set is in use and who owns its rotation schedule, because a stale key is a common cause of failed launches after a change on either side. Exact endpoint names and key-set locations should be confirmed in the vendor documentation and in the Moodle plugin help text for the installed version. The check is that the platform can fetch Moodle's key set over HTTPS and Moodle can retrieve the vendor's keys without an error in the logs.
Place a test launch in a sandbox course
The team creates a sandbox course with a test student account and a test teacher account, adds the tool or the platform link, and launches it. The first launch should be done from the teacher view and then as the student, because the two roles often receive different claims and permissions. The team checks that the tool opens inside Moodle, that the user is created or matched as expected, and that the returned user record shows the correct name, role and course context. If the launch fails, the team reviews the Moodle logs for the specific error before changing any configuration, to avoid undoing a correct setting. The step closes when a student launch returns the expected user record and the tool opens in the course.
Enable outbound publishing and pre-register the consumer
For outbound publishing, the team enables the Publish as LTI tool enrolment method in the sandbox course, then pre-registers the consuming platform by entering its issuer, client identifier, deployment identifier and key details as the plugin requires. Moodle's documentation states that LTI Advantage publishing allows content to be published to pre-registered platforms without changes on the platform whenever new content is published, so the registration must be complete before any test publishing. The administrator confirms the registration against the consuming platform's documentation and records the platform owner for future changes. The check is that the platform appears as registered in the enrolment method and that its saved details match what the platform owner supplied.
Publish one test activity and confirm the launch
The team publishes a single test activity from the sandbox course to the pre-registered platform, then asks the platform owner to launch it with a test user. The check is that the activity opens on the consuming platform and that the platform records the user's role and course context as expected. If grades are part of the scope, the team also confirms that a grade completed on the test activity is passed back to the platform. Publishing should remain limited to the sandbox until the team has checked the launch, the role mapping and the grade return. Only after these checks pass should the team widen publishing, and that decision belongs in a separate change record.
Record the configuration and confirm field names
Before handover, the team records every issuer, client identifier, deployment identifier, endpoint, key set location and enrolment setting in a configuration record kept with the site documentation. They confirm each field name against the vendor's documentation and the Moodle plugin language strings for the installed release, since labels can change between versions. The record names the owner of each external dependency, the key rotation process and the test accounts used. The step is complete when a second administrator can repeat the sandbox launch from the record alone and reach the same result.

How launch data maps to Moodle users, roles and courses

This table maps the identity, role, context, resource link and service data that an LTI 1.3 launch carries onto Moodle users, enrolments, courses and activities. Read each row as a decision: the owner column shows who should sign off, and the verification column shows what to test before go-live. Treat every claim name and field as a starting point to confirm against the LTI Advantage specification and your tool vendor's documentation.

Launch data	Moodle mapping and matching rule	Decision owner	What to verify in testing
User identifier (sub, issuer)	Pair the platform issuer and the sub claim to a Moodle account through the tool's user record, so the same person keeps one identity across launches. Decide whether accounts are matched by username, email or an existing auth record before enabling launches.	Moodle admin	Launch the same user twice and confirm no duplicate account is created. Test a user whose email changes.
Name and email claims	Map the optional name and email claims to Moodle profile fields only if your policy allows the tool to receive them. Missing claims should not block account creation, so confirm the fallback behaviour.	Moodle admin	Test a launch where the email claim is absent and confirm the account still resolves correctly.
Roles claim (context membership)	Translate the LTI context roles, such as learner and instructor, into Moodle enrolment roles inside the course. Confirm which LTI roles grant editing rights and which only grant view access.	Course designer	Launch as each role used in your courses and compare the Moodle role assigned in the course with the intended role.
Context claim (course)	Match the context id to a Moodle course, normally through the course’s shortname, idnumber or a stored link created on first launch. Decide who creates the course link when a course does not yet exist.	Moodle admin	Confirm the launch lands in the correct course and that a second course with a similar name is not matched by mistake.
Resource link claim	Map the resource link id to a Moodle activity or a tool-side content item placed in a section. Decide whether one resource link is shared across courses or copied per course during backup and restore.	Course designer	Duplicate the course and check whether the tool activity keeps its link or creates a new one, then launch both copies.
Deep linking content items	If the tool returns content items through deep linking, decide which Moodle activity type each item becomes and where it is placed in the course. Keep the mapping list in the tool configuration documentation.	Course designer	Select each content type the tool offers and confirm the resulting activity opens with the expected settings.
Names and roles provisioning service (membership)	If the tool calls back for the course roster, decide which Moodle roles are shared and whether suspended or unenrolled users are excluded. Confirm the service is enabled in the tool registration.	Tool vendor	Compare the roster returned by the tool with Moodle’s enrolments, including a suspended user and a teacher with extra rights.
Assignment and grade services (grade passback)	Decide which Moodle grade item receives scores, whether passback is automatic or manual, and how the maximum score is scaled. Check the line item structure the tool expects before setting up grade items.	Course designer	Submit a score from the tool, confirm the Moodle grade item and value, then test a re-grade and an overridden grade.
Platform registration and deployment ids	Record the issuer, client id and deployment id for each Moodle site or tool deployment. Keep them with the tool owner so that a Moodle upgrade or domain change does not break launches.	Tool vendor	After a test restore or domain change on a staging site, confirm the tool still accepts launches with the same registration.

Securing LTI Advantage launches and published content

LTI Advantage connects Moodle to external tools and, through the Publish as LTI tool enrolment, exposes Moodle content to other platforms. Each connection is a trust decision, so the controls below cover who may register, what keys and secrets are protected, what content leaves the site, and what data comes back. Work through them before the first production registration and again after every upgrade.

Restrict who can register tools

Dynamic registration and manual tool setup both create trust relationships with external issuers. Limit tool configuration to a small administrator group, and approve each issuer, client ID and deployment ID before it is enabled. Confirm which registration methods your Moodle version offers and whether a tool can add itself without review. Record the approver for every registration so the list stays explainable during an access review.

Protect private keys and client secrets

Moodle holds the platform private key and the tool registration details, and external tools hold their own keys. Restrict database and file system access to the Moodle server and its backups, keep backups encrypted, and avoid copying key material into course content or support tickets. Plan a key rotation procedure and confirm with the vendor how Moodle handles key changes for an existing registration before you rely on it.

Limit what courses publish outward

The Publish as LTI tool enrolment lets other platforms launch selected courses and activities, and new content can appear without any change on the other platform. Publish only courses that have a documented external purpose, and review the list of published activities each term. Keep unpublished drafts and staff-only courses out of scope, and confirm that deleting or hiding a course removes its external access.

Review roles a launch can grant

A successful LTI launch assigns a Moodle role through enrolment, so an over-broad role mapping lets an external user act as a teacher or manager. Map external roles to the least privileged Moodle role that meets the teaching need, and review the mapping whenever a tool is added. Test each mapping with a non-privileged account and confirm that the role cannot change settings, grades or other enrolments.

Apply least privilege to service accounts

Tools that call Moodle web services or read grades need an account, and that account should not be a site administrator. Create a dedicated user with a role limited to the functions the tool needs, restrict its token to the required services, and set an expiry or review date. Document which tool uses which account so that revoking one integration does not interrupt another.

Revoke a tool registration cleanly

Revocation should disable the tool, remove or invalidate its registration and deployment, and withdraw any service tokens it held. Check which existing enrolments and grades remain after revocation and decide whether they stay, are archived or are removed under your retention rules. Keep a written runbook with the steps in order and test it on a staging site before the first real revocation.

Enforce HTTPS and log registrations

Launch messages, tokens and grade data must travel over HTTPS only, so confirm the certificate chain, redirect rules and any reverse proxy headers that Moodle relies on. Log tool registrations, configuration changes, launches and service-token use, and forward those logs to a store that administrators cannot quietly edit. Review the log sample on a schedule and confirm that the retention period matches your policy.

Review returned grades and memberships

Grade passback and membership services return student names, identifiers and scores to external tools. Before enabling them, check which fields each tool receives, whether the tool is permitted to receive them under your data policy, and where the tool stores them. Confirm the lawful basis, processor terms and deletion commitments with the tool provider, and repeat the review when a tool adds a new data scope.

How to verify launches, roles and grades before go-live

Verification for a Moodle LTI Advantage integration should follow a fixed sequence, and the first step is to run every test on a copy of the production site that runs the same Moodle release. Create that copy from a recent backup, confirm the Moodle version and PHP and database versions match production, and register the tool on both sides using the same client ID, deployment ID and endpoint URLs you intend to use live. A test against a development build on a different release can pass while the live site fails, so the copy is the only environment whose results you should trust for a go-live decision.

Start with launches from each role. Log in as a student, a teacher and a manager (or whichever administrative role your design uses) and launch the same activity from each. For every launch, confirm that the external tool receives the expected role claims, that the user lands in the correct course context, and that the user sees only the permissions the design allows. Check the course identifier the tool receives against the course you opened, because a mismatch here usually points to a mapping or deployment error that would otherwise expose content across courses. Record the claims each role produces so you have a baseline for later comparison.

Next, confirm that a user who is not enrolled cannot enter. Use an account with no enrolment in the course, an account enrolled in a different course on the same site, and an account whose enrolment has been suspended or has ended. Each should be refused at Moodle or denied by the tool, and none should reach a launch page or receive a valid session. Also test a direct link to the launch URL pasted into a browser by an unenrolled user. This check confirms that enrolment rules hold at the point where Moodle hands control to the external platform, which is where access mistakes are most costly.

Then test publishing and upgrades. If you publish Moodle courses or activities to another platform with the core Publish as LTI tool enrolment, confirm that the consuming platform can still launch a published activity after the site is upgraded to a new major or minor release. Run the same launch tests after each Moodle upgrade, including minor point releases, and treat any failure as a blocker for that upgrade. Confirm the upgrade path against the release notes for your starting version before you schedule it, since server and PHP requirements change between releases. Repeat the full launch sequence every time the Moodle version changes, not only when the tool or the design changes.

Finally, confirm that grades or completion return only where the design allows. Submit a graded activity through the tool and check that the score reaches the Moodle gradebook for the correct user and course item, then check that nothing returns from activities or roles that the design excludes. Test a failed or partial score, a resubmission and a learner who has left the course. Document which data flows are permitted, who approves them, and what the retention and deletion rules are for returned results. Plan for the risk that a returned grade is wrong, and agree in writing how the reconciliation will be handled before the course opens to learners.

Common LTI Advantage failures and their causes

This table maps the failures teams most often see when Moodle launches external LTI 1.3 tools or publishes courses through the Publish as LTI tool enrolment, with the likely cause and the place to check first. Read each row by symptom, then work through the listed checks before changing registration settings. The main takeaway is that most failures trace to a mismatch between the issuer, client and deployment details on the two sides, so compare those values before anything else.

Symptom	Likely cause and fix	Where to check first
Launch rejected with an invalid issuer or client error	Platform issuer, client ID or deployment ID in the tool registration does not match what Moodle sends. Re-copy the values from the registration and confirm the issuer URL includes the exact site address and any path.	Moodle external tool registration settings, then the tool vendor console
Launch fails on signature or key validation	The tool cannot fetch Moodle's public keyset, or the keyset URL is blocked by a firewall, proxy or certificate issue. Confirm the keyset endpoint is reachable from the tool's network.	Moodle site logs and web server access logs, then network rules between tool and Moodle
User lands without the expected role	Launch claims for roles are not mapped as the tool expects, or the Moodle user is not enrolled in the course with the role the tool reads. Check the enrolment method and role assignment before changing the tool.	Course participants page in Moodle, then the tool's role mapping or claim settings
Published activity unavailable on the consuming platform	The registration on the consuming platform is missing, was removed, or points to a deployment that no longer matches the published course. Recreate the registration on the consuming side with the values issued by Moodle.	Publish as LTI tool enrolment settings in the source course, then the consuming platform's tool list
Blank or error page after a Moodle upgrade	The web server document root still points to the main Moodle folder instead of /public, or the PHP version is below the minimum for the new release. Correct the document root and check the PHP version against the release notes before retesting launches.	Web server virtual host configuration, PHP version on the server, then Moodle environment check
Tool expects LTI 1.1 credentials	The tool supports only LTI 1.1 consumer key and secret, while the integration uses LTI 1.3. LTI 1.1 and 2.0 are deprecated for Publish as LTI tool. Ask the vendor for an LTI 1.3 or Advantage configuration, or plan a replacement tool.	Tool vendor documentation and console for LTI 1.3 support, then the Moodle external tool type in use

How much effort does a Moodle LTI Advantage integration take?

What is the short answer on effort for a Moodle LTI Advantage integration?

Effort depends mostly on how many tools you connect, which directions the integration runs, and how much of the tool configuration is governed by roles and grades. A single outbound tool launched from a few courses is a small, bounded task. Publishing Moodle courses to several external platforms, each with its own registration, deployment IDs and content rules, is a larger one. Treat the answer as a scope question, not a fixed number. Ask for a written scope listing each tool, each direction, the test plan and the handover, then compare the quote against that list. DeployOpen does not publish a price list, and no duration is given here because none was supplied for this topic.

Which factors make a Moodle LTI Advantage integration take longer?

The biggest drivers are the number of tools, the number of integration directions, and the rules that decide who sees and grades each activity. Each additional tool adds registration, a test launch, and a check of how it reports grades back to the gradebook. Each direction adds its own trust setup: launching external tools from Moodle courses is different from publishing Moodle content to other platforms with the core Publish as LTI tool enrolment. Role mapping and grade passback rules add testing time, as do the vendor's LTI 1.3 support and how often the tool and Moodle are upgraded. Confirm each vendor's LTI 1.3 and Advantage feature list before scoping, because support differs between products.

Can our internal team build a Moodle LTI Advantage integration on its own?

Yes, if your team has Moodle administration skills, access to the tool vendor's developer documentation, and someone who can operate the keys and endpoints involved. The work is configuration-heavy rather than code-heavy in most cases, but it needs careful testing across roles, courses and grade items. Teams without recent LTI 1.3 experience often underestimate the registration handshake and the testing of grade return. A practical approach is to have an internal owner for Moodle and the tool, and to decide early whether a partner will do the build, the testing or only a review. Either way, a written scope makes the internal-versus-partner comparison concrete.

What do we need to provide before an LTI Advantage integration starts?

Plan for four inputs. First, administrator access to the Moodle site and any tool-side admin accounts needed to register the integration. Second, named contacts at each tool vendor who can supply client details, deployment settings and answers on LTI 1.3 behavior. Third, test accounts for each role, such as teacher, student and manager, in a non-production copy of Moodle. Fourth, decisions from data owners on which courses are published, which roles may launch tools, and which grades may be returned. Missing any of these usually extends the schedule more than the technical work does, so collect them in the scoping stage.

How does the effort for one-time setup differ from ongoing upkeep?

One-time work covers the initial design, tool registrations, deployment configuration, role and grade rules, test plan, and the handover documentation. Ongoing upkeep covers keeping each registration valid when Moodle or the tool changes, testing after each Moodle upgrade, reviewing new tool versions, and handling access or grade questions from teachers. Moodle ships major releases in April and October and minor point releases every two months, so a recurring check after each upgrade window is a realistic line item. Ask any partner to split the quote into setup, testing and recurring support so you can see which part repeats.

How should we ask for a quote for a Moodle LTI Advantage integration?

Ask for a written scope before any work begins. It should list every tool and direction in scope, the Moodle version and hosting environment, the roles and grade rules to implement, the test cases and environments, the documentation and training to be delivered, and the items the client must supply. It should also state what is excluded, such as changes to a vendor's product or support for tools you add later. Ask for the timeline as milestones tied to those inputs rather than a single date. Compare quotes on the same scope list, because two quotes for different scopes cannot be compared directly.

Which parts of the integration should we check before we sign off?

Check that each tool launches for every intended role, that grades return to the correct gradebook items, and that unpublished or hidden content does not leak through the publish path. Confirm that the published platform registrations behave as expected without manual changes each time new content is published, which is the behavior Moodle documents for Publish as LTI tool with LTI Advantage. Test a legacy tool path too, because Moodle documents LTI 1.1 and 2.0 as deprecated. Finally, confirm that the runbook covers what to do after a Moodle upgrade, since registrations and tool settings are the parts most likely to need attention.

How DeployOpen scopes and delivers the integration

DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For Moodle LTI Advantage integration, we start from a written scope that sets out which tool launches and course publishing paths are in play, then build and verify them in your environment.

How we scope

Engagements are fixed-scope, with the covered tools, courses and platforms agreed in writing before work starts.
We list which external tools will launch from Moodle courses and which courses will be published through the Publish as LTI tool enrolment.
We confirm the Moodle version and its LTI Advantage support, then record the platforms that will be registered for each direction.
Ask for a quote that separates the launch and publishing paths, the registration work and any testing or training you request.

How we build

We register each external tool or consuming platform using LTI 1.3 Advantage settings, and document the keys and endpoints exchanged.
We configure Moodle's external tool activities and placements, then map roles and enrolments so launches reach the right course context.
For publishing, we set up the Publish as LTI tool enrolment, so pre-registered platforms can receive new course content without changes on their side.
We test launches, grade return and deep-linking flows in a staging environment before any production change.

How we hand over

You receive the registration records, configuration decisions and a runbook covering each tool and each published course.
We document how to add a new tool or platform, and which steps need your Moodle administrator or the other platform's administrator.
We walk your team through the verification checklist so they can repeat launch and grade tests after future changes.
Confirm with us in advance which artifacts, access and knowledge transfer sessions are included in the written scope.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which covers LTI connections after Moodle upgrades.
Before a Moodle upgrade, we check the LTI Advantage configuration against the release notes for the target version.
We re-test launches and grade return after upgrades, platform certificate or key rotations and changes to the tools you connect.
Ask whether your retainer covers changes to registrations for new tools or new platforms, and how those requests are priced.