How Open edX LTI integration works in both directions
LTI covers both directions. Open edX can act as the platform that embeds external tools inside its courses, and it can act as the provider that makes its own course content available to another LMS. The two directions need different configuration, so a team should decide which direction each use case needs before anyone touches settings. An external tool in a course needs a registered tool, launch and key details entered into Studio and the LMS. Open edX content offered to another LMS needs the other platform registered with the keys and launch endpoints that Open edX issues. Treating these as one task is the most common reason a pilot works in one direction and fails in the other.
The work is harder than it looks because LTI depends on several things that break quietly. Both platforms must reach each other over public HTTPS URLs, so internal hostnames, certificate problems and firewall rules will stop a launch before any learner sees it. Shared keys must be generated, stored and rotated on both sides. Roles must map correctly, so that an instructor in one system does not arrive as a learner in the other. The grade model is the hardest part: the external tool or destination LMS must accept scores in the format Open edX sends, and course teams must agree on which assessments pass grades back and how partial credit is handled. Open edX third-party authentication also lists LTI as a supported identity option, which is a separate use from tool launches. Teams should confirm which of these they need before designing the flow.
Before committing to a design, confirm two things with the vendor and your own environment. First, check the certification scope of the Open edX release you plan to run. The Verawood release notes list LTI Advantage Complete certification as a feature of that release, but the notes do not replace your own testing of each tool. Ask which LTI Advantage services the certification covers and which are outside it. Second, confirm the LTI version each external tool or destination LMS supports. A tool that supports only an older version may need a different launch path, and it may not support the grade services your course design assumes. Put both answers in the written scope so the quote covers the integration you actually need.
A practical first step is an inventory. List each external tool or destination LMS, the direction of the integration, the roles that will launch it, whether it needs grade passback, and who owns its keys and URLs. Then build one integration per direction in a staging environment, using a test course and test learner accounts for each role. Verify that the launch succeeds from a clean browser session, that roles arrive as expected, and that a graded assessment sends a score the destination accepts. Record the results in a short test log. This evidence shows course teams and the security owner which combinations work, and it gives the next release upgrade a concrete regression list.
Which Open edX components carry LTI traffic
LTI traffic passes through several Open edX parts, and each one has its own settings and failure modes. Use these cards to map which parts your deployment uses before you design the launches, grade return and sign-in flows.
The LMS as launching platform
The LMS is where learners open a course unit and where an LTI launch starts when a learner selects an external tool. It sends the tool a signed launch request that carries identity, role and context data. Confirm which LTI versions and Advantage services your Open edX release supports, including deep linking and grade return. Check these against the release notes for the named release you run, because LTI support has changed between releases.
Studio places LTI components in units
Instructors add LTI components to course units in Studio, and that placement decides which tool, launch address and settings a learner sees. Authoring and delivery are separate steps, so a component that works in a test course can still fail after course content is exported and imported into production. Confirm which LTI options your Studio offers, how components are copied between courses, and how tool settings travel with course content between environments.
The LTI consumer component
The LTI consumer component is the Open edX piece that embeds an external tool inside a course. It holds the tool's launch address and the credentials the tool uses to trust Open edX, and it controls whether grades flow back for graded items. Confirm with your Open edX release which LTI versions the component supports, how it handles deep linking, and which fields the tool vendor must receive from you before the first launch.
The LTI provider path to another LMS
This path lets another LMS launch Open edX content, so Open edX acts as the tool provider. Configuration defines which content is exposed, which consumer keys and secrets the other platform holds, and which learner attributes leave your platform with each launch. Confirm with your privacy team which attributes may be sent, and confirm in your release whether this provider path is available and which LTI versions it accepts.
Third-party authentication for LTI sign-in
Open edX third-party authentication supports LTI as one provider type, alongside OAuth2, SAML 2.0 and Shibboleth. When an LTI launch identifies a learner, the platform must match that identity to an existing account or create one, so matching rules decide whether a learner ends up with one account or two. Test with a dedicated test learner before go-live, and confirm which provider types your release enables by default.
Tutor configuration for keys, URLs and plugins
Tutor is the official Docker-based Open edX distribution, and it holds the configuration for LTI keys, URLs and any plugin that adds LTI behavior. Its plugin and hooks system is licensed under Apache 2.0, so custom LTI plugins can be maintained separately from the platform. Keep consumer secrets out of version control and shared files. Confirm which Tutor version matches your Open edX release and where your version expects LTI settings to be placed.
Which LTI direction and version to build first
This table compares the main LTI decisions for an Open edX project: which direction to build, which LTI version to target, whether LTI handles sign-in, and whether grade passback is turned on. Read each row against the destination LMS or tool vendor, because their support often settles the choice before your own preferences do.
| Decision | When it fits | Operating cost to plan for | Confirm before committing |
|---|---|---|---|
| Embed external tools in Open edX courses | Course teams need an existing external tool, such as a lab, assessment or publisher resource, inside a course unit | Each tool needs its launch URL, keys and a named owner who checks it after Open edX upgrades; tools that change vendors or endpoints need reconfiguration | The tool vendor supports LTI launches from Open edX and documents the LTI version it accepts |
| Publish Open edX content to another LMS | Another LMS must host or launch Open edX course content for its own learners and the platform owner accepts that the other LMS controls the learner session | Keys and registrations must be rotated on both sides, and content changes in Open edX may need checks on the receiving side | The destination LMS supports LTI Advantage or the version you choose, and states which grade and roster services it offers |
| LTI Advantage (1.3) versus earlier LTI versions | Advantage is the default for new work because Open edX Verawood lists LTI Advantage Complete certification; earlier versions fit only when a partner still requires them | Earlier versions usually depend on shared secrets that must be rotated by hand; Advantage uses public key registration and needs tracking of key sets and signing keys | Whether the partner tool supports LTI 1.3 and the Advantage services you need, such as assignment and grade services or names and roles |
| Use LTI for sign-in | A partner tool must identify learners it cannot match to Open edX accounts, or sign-in must flow through a single external hub | Open edX must map LTI identities to accounts and handle account linking, which adds support work for duplicate or changed learner IDs | Your identity policy allows the external tool to act as an identity source for learners and staff |
| Separate SSO for the Open edX site | Learners sign in to Open edX itself through SAML 2.0, Shibboleth or OAuth2 providers, and LTI is used only for tool launches | Two integration paths to test and maintain, but each has a clearer owner and failure mode | Your identity provider supports the chosen protocol and the tool accepts the Open edX-issued launch context |
| Grade passback on | Assessments inside an external tool must appear in Open edX gradebooks or the destination LMS gradebook | Scores need a tested mapping to Open edX grading, plus monitoring for failed submissions and retries after outages | The tool and the receiving LMS both support the grade service you plan to use, and they agree on score scales and maximum values |
| Grade passback off | Tools only display content and learners do not need scores synced, or grades are kept in the tool and reviewed manually | Lower integration effort, but instructors must reconcile grades by hand and explain the gap to learners | Course policies accept that external results are not in the gradebook and that reports must come from the tool |
| Start with one direction and one version | A first pilot with one tool or one partner LMS keeps key management, testing and support scope small | Each added tool or partner adds keys, endpoints, test cases and support contacts; plan for this before expanding | The pilot tool and partner have a named technical contact and an agreed test environment |
How to configure LTI in Open edX step by step
This sequence takes an Open edX instance from a release check to a tested LTI connection with an external tool, including launches, role mapping and grade passback. Each step closes with a check the team can observe, so faults surface in a test environment before any learner or grade depends on the integration.
Confirm the release and LTI support
Your team records which named Open edX release the platform runs and which LTI version and services the external tool requires. Open edX supports only its latest named release, and the Verawood release notes list LTI Advantage Complete certification, so confirm that the release you plan to run includes the LTI behavior you need. Ask the tool vendor to confirm its LTI version, launch types, deep linking and grade services in writing. The step is done when the release, LTI version and each required service are recorded in the design notes and both parties have acknowledged them.
Build a test environment with Tutor
Deploy a non-production Open edX instance with Tutor, the official Docker-based distribution that the platform maintainers recommend for production and local development. Place the test LMS and Studio behind HTTPS on stable public hostnames, because the tool stores the platform URLs and validates tokens against them. Choose a dedicated test domain and avoid changing it later, since every registration depends on it. The step is done when both sites load over HTTPS with valid certificates and the platform's public key set endpoint returns a response from outside your network.
Exchange issuer, client ID and keys
Share the platform's issuer, the public key set URL and the tool's launch endpoints with the vendor, then receive the client ID and deployment ID for this placement. Each side registers the other's keys so that signed launch messages can be verified. Keep the client ID and deployment ID in your configuration records, and store any shared secrets in your secrets management, not in a document. The step is done when the tool confirms it has loaded the platform's keys and a signed test message validates on both sides. A message signed with an unregistered key should be rejected.
Configure launch and deep linking settings
Set the tool's launch URL and, if the tool supports it, the deep linking URL that lets instructors choose content from the tool's catalog. Define which course locations can host the tool, such as a unit or a problem component, so instructors can find it without exposing it everywhere. Confirm which launch parameters the platform sends, and document them for the vendor. The step is done when a test launch from a course unit opens the tool with a valid token, a deep linking selection returns a content item into the course, and a launch with an altered or wrongly addressed token is refused.
Map roles and learner identity
Map the LTI roles the platform sends, such as learner, instructor and administrator, to the access the tool should grant. Decide which user identifiers and profile fields leave the platform, and send only what the tool needs for its function. Confirm how the tool treats an account that changes role during a course. The step is done when test accounts for a learner, an instructor and an administrator each reach the expected screens in the tool, and the learner account cannot reach instructor or administrator views. Record the mapping table for audit review.
Enable grade passback and confirm the gradebook
Enable the assignment and grade services in the tool and in the platform's LTI configuration, then define the maximum score and how the tool's result maps to the Open edX grade. Decide whether the tool sends scores on each submission or when a learner completes the activity, and confirm how retries are handled. Check the destination gradebook settings on the platform side. The step is done when a graded test submission posts a score that appears in the Open edX gradebook with the same value the tool recorded, and a repeated submission updates the score as designed.
Run sign-off checks and document results
Run a negative test set that includes an expired token, a wrong client ID, an altered signature and a launch from an unregistered deployment, and record the outcome of every case. Repeat the positive launch, deep linking and grade checks after any configuration change. Ask the tool vendor and your security team to review the results before production, and confirm with your assessor which evidence they need if the integration falls under a compliance program. The step is done when every check has a recorded result and the sponsor signs off the test environment.
How to test LTI launches, grades and failure paths
Test every LTI path in a non-production course before any learner sees it. Start with a successful launch for each role the tool will serve: a learner enrolled in the course, an instructor or course staff member, and an administrator. For each one, confirm the tool opens inside the unit, the user lands on the screen the tool vendor expects, and the name and roles shown in the tool match what Open edX sends. Record each launch in the tool's own logs as well as in the Open edX logs so you can compare them later. Use a fresh browser session for each role, because a session left over from a previous role can hide a provisioning problem. Confirm the expected result for each role against your own environment and the other party's documentation, since role mapping is configured on both sides.
Next, test deep-link selection and grade return, since these fail in different ways. For deep linking, an instructor should choose content in the tool's selection screen, return to Studio, and see the item placed in the intended unit. Check that the placement survives a page reload and a course republish, and that a learner sees the same item. For grades, add a graded component that uses the tool, submit a score as a learner, then find that score in the destination gradebook and in the Open edX gradebook for the same learner. Compare the score, the maximum points and the attempt count. If the launch works but the grade is missing, the outcome or assignment service configuration is the first place to look, so test those settings as a separate step.
Failure paths matter as much as the happy path. Register a test tool with a deliberately wrong consumer key or secret, then confirm the launch is refused before any learner or instructor session is created. Next, replay a launch request that has expired or reuse one whose nonce has already been consumed, and expect the same refusal. In both cases, check that no account was provisioned, no course role was granted and no grade was written. Read the LMS logs for a clear rejection reason, and confirm the error shown to the user does not reveal which check failed. Clock differences between the Open edX servers and the tool host are a common cause of false refusals, so verify time synchronization on both sides and confirm the timestamp tolerance each party allows before you treat a failed launch as a security result.
Finally, test what happens when the external tool is down. Stop or block the tool in staging, then launch it from a unit and confirm the learner sees a clear message instead of a blank frame or a stalled course page. Check whether the rest of the course remains usable, and whether any grade submitted during the outage is queued, retried or lost. Ask the tool vendor how long unsent scores are kept and how duplicate submissions are handled. Run the logging checks on both sides in the same test cycle: the Open edX logs, the tool logs and the timestamps for each event, so a learner's report can be traced from end to end. Write down the expected result for every case before testing, and have the owners of both systems sign off on it.
How LTI changes on single node, HA and Kubernetes
On one Docker host managed by Tutor, the LMS and Studio share one network identity, so LTI launches and grade returns use the same hostname for the life of each course. The main work is making that hostname stable and publicly reachable before any external tool is registered.
- Hostname: Choose the LMS and Studio domains first, because tools record the issuer and redirect URIs you give them.
- TLS: One certificate covers the host. Confirm renewal is automated, since an expired certificate can break launches for every tool at once.
- Cache and sessions: A single node does not need a shared cache for LTI, but confirm how cache and session settings change if you add a second node later.
- Key material: Confirm where your Tutor version stores the LTI key pair on the host, restrict file permissions, and include the key in encrypted backups.
- Outbound access: Check that the host can reach each tool's launch, keyset and token endpoints over HTTPS.
Check the hostname, certificate renewal and outbound rules on a staging instance before you register the first production tool.
When several LMS and worker nodes sit behind a load balancer, every node must present the same hostname, issuer and LTI keys. State used during a launch must also be visible to whichever node handles the next request. The full build belongs to the high availability topic, so this tab covers only the LTI-specific changes.
- Stable hostname: The public name, not a node name, must appear in launch URLs and in every tool registration.
- TLS termination: Decide whether TLS ends at the load balancer or on each node, and use one certificate chain for all of them.
- Shared cache: Multi-node deployments need a shared Django cache backend such as Redis or Memcached, so launch state created on one node is visible to another.
- Key distribution: Every node must use the same LTI key pair. Plan rotation as one change, keeping the old public key published during the overlap.
- Outbound paths: Confirm that egress from each node, including any proxy or NAT in front, is allowed to reach tool endpoints.
Test a launch and a grade return while one node is drained from the load balancer, and confirm the sibling high availability topic covers the database, media and cache builds.
With tutor k8s, the ingress controller, certificate manager and secrets store take over much of the work a single host did by hand. LTI behaviour depends on the ingress keeping the public hostname and certificate stable across rollouts, and on key material being managed as secrets instead of being copied into images.
- Ingress hostname: Define the LMS and Studio hosts in the ingress configuration and keep them identical to the names registered with each tool.
- Certificates: Use a certificate manager or managed certificates, and confirm renewal does not restart pods in a way that interrupts in-flight launches.
- Shared cache: Pods scale across nodes, so a shared cache service is required. Confirm whether it runs as a managed service or inside the cluster with persistence.
- Key material: Store the LTI private key in a Kubernetes secret or an external secrets manager, restrict access with role-based access control, and rotate it as a rollout after the new public key is published.
- Egress: Network policies and egress gateways can block tool endpoints, so allow outbound HTTPS to each registered tool explicitly.
Confirm with your Tutor version how LTI keys are mounted, and read the sibling Kubernetes deployment topic before you set ingress and secrets.
In an air-gapped or tightly restricted network, the usual LTI Advantage assumption that the platform can reach external tools over the internet often does not hold. The design depends on where each tool runs, which egress paths are approved, and how trust and keys are managed inside your own boundary.
- Internal hostnames: Use internal DNS names with certificates from your internal certificate authority, and confirm every tool trusts that authority.
- Tool location: Tools must be reachable on the internal network. Externally hosted tools need an approved egress path or a proxy, which is a decision for your security team.
- Shared cache and sessions: Keep Redis or Memcached inside the boundary and verify it is not reachable from outside.
- Key material: Generate and rotate LTI keys under your own key custody process. If tools fetch the public key from an internal endpoint, no internet-facing key discovery is needed.
- Images and updates: Mirror container images and plugin packages internally before go-live, since offline updates can change rotation and upgrade timing.
Confirm which tools can reach the platform and which need egress approval before you commit to an LTI design, because this determines whether the design is workable inside the boundary.
What drives LTI integration effort and cost
This table lists the factors that change how much work an Open edX LTI integration takes, and how to keep each one contained. Read each row as a lever: the left-hand driver is what grows the scope, and the right-hand column is the decision that holds it down. The main takeaway is that a small, named set of tools, roles and test cases makes both the quote and the ongoing cost predictable.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of external tools and destination LMSs | Each tool needs its own LTI registration, launch configuration, tested deep-linking flow and support contact. Offering Open edX content to another LMS adds a second set of registrations in the other direction. | Start with one pilot tool or one destination LMS, then add others through the same pattern once it is tested. |
| LTI version and certification requirements | LTI 1.1 and LTI Advantage use different launch and service models. Open edX Verawood lists LTI Advantage Complete certification, but your tool vendors may certify against different profiles, so confirm which profile each partner needs. | Name the LTI version and certification profile per tool in the scope, and ask each vendor to confirm its conformance status in writing. |
| Grade passback requirement | Returning grades to the tool requires the Assignment and Grade Services, mapping of graded components, and reconciliation when learners retake or grades change. This is the most test-heavy part of the work. | Limit passback to named graded components, and agree the expected grade values and failure behavior before build. |
| Role and organization mapping | Each external role, institution or course context must map to an Open edX role or organization. Every extra role or exception adds rules, tests and support questions. | Fix a short role map (for example learner, instructor, and course staff) and agree how unknown roles are handled. |
| Number of environments | Development, staging and production each need their own keys, registrations, URLs and test accounts. Environment drift between them is a common cause of late defects. | Agree the environments to be built in the quote and keep configuration in version-controlled Tutor settings. |
| Custom development in the tool or an XBlock | If an external tool needs a change, or an XBlock must pass data to a tool, the work moves beyond configuration into code owned by someone who must maintain it. | Prefer standard LTI settings and existing XBlocks, and name any custom code as a separate line item with its own tests. |
| Network and firewall approvals | Launches, JWKS key retrieval, token endpoints and grade callbacks all cross network boundaries. Approval queues in your organization often take longer than the technical build. | Submit a list of required hostnames, ports and directions to the network team early, and ask the partner to confirm the traffic pattern. |
| Compliance evidence for data sharing | Sending names, emails or grades to an external party may require data processing terms, records of what is shared, and retention rules. DeployOpen prepares evidence for assessors but does not issue audit reports. | Document the data fields shared per tool, and confirm with your privacy and compliance owners before the scope is signed. |
| Recurring work after go-live | Tools change their endpoints, keys and certificates, and each Open edX named release moves the supported baseline forward. LTI code and integrations then need regression testing again. | Ask for the agreed test cases to be kept as a regression set, and name who pays for retesting in any support retainer. |
How to protect LTI keys, launches and grade data
LTI connects Open edX to external tools at two points that carry risk: the launch, where a learner's session is handed to a tool, and grade passback, where scores move back into the gradebook. The controls below protect the credentials, the trust relationships and the data on both paths. TLS, cookies and admin access are covered in the hardening topic.
Store and rotate keys
LTI client secrets, tool private keys and any signing material belong in Tutor configuration fed from a secrets manager, kept out of Git repositories and plugin code. Scan the configuration repository for values before each commit. Set a rotation schedule for each tool registration, and record who holds each credential, who can issue a replacement and how a compromised key is revoked. Agree the rotation steps with each tool provider before go-live.
Restrict launch hosts and tools
Keep an explicit list of the tool domains, client IDs and deployment IDs that the LMS may launch and accept launches from. Tie each entry to a named course owner and a documented approval. Review the list when a course closes or a vendor changes its domain, and remove any entry that no longer has an owner. Confirm with your LTI plugin or Open edX release how registrations are scoped across organizations and courses.
Validate launch tokens and nonces
In an LTI 1.3 launch, the platform receives a signed ID token from the tool and must check its signature, issuer, audience, expiry and deployment ID before it creates a session. Nonces must be accepted once within their validity window so that a replayed message fails. Test these checks in staging with altered and replayed tokens. Confirm which checks your Open edX version and LTI plugin enforce by default and which need configuration.
Limit roles and data sent
A launch carries role claims and user attributes such as name and email address. Send each tool only the roles and fields its course function requires, and map Open edX roles to tool roles deliberately. Do not pass staff or administrator roles through by default. Where a tool supports pseudonymous user identifiers, use them. Ask each tool vendor what it stores, where, and for how long.
Protect grade endpoints
Grade passback lets a tool write scores to the gradebook through an access token with granted scopes. Limit each tool to the scopes it needs, verify the token and its audience on every request, and confirm that a tool can write only to line items and users within its own course. Check how retries behave so a failing tool cannot silently overwrite corrected grades. Test with a sandbox tool before connecting production courses.
Log launches and grade exchanges
Record each launch with its timestamp, tool, course, deployment, user identifier and outcome, and record each grade write with its line item, score and result. Store these logs with restricted access and a retention period set by your policy. Review failed launches and unexpected grade changes on a fixed schedule. Confirm which events the Open edX logs capture by default and which require the analytics pipeline or a plugin.
What to monitor, back up, upgrade and document after go-live
After go-live, LTI problems usually appear as learners who cannot launch a tool or as scores that never reach the gradebook, so monitoring should focus on those two failure points. Review LMS logs for launch failures and check the reports course teams raise each week. Separate launch errors, such as a mismatched deployment identifier or a signing key the tool no longer trusts, from grade passback errors, where the score is sent back to the platform but not recorded. Agree a review cadence with course teams so missing grades are found in the first week of a course rather than at the end of a term. The log fields, alert thresholds and retention periods depend on your logging stack and hosting setup, so confirm them with your operations team before the first course opens.
Certificate and key expiry is the most predictable post-go-live failure, and it is easy to miss because nothing breaks until the date passes. Build a register that lists each TLS certificate on the LMS and Studio domains, the platform key pair used for LTI messages, and the keys or client credentials each external tool holds for your platform. For every item, record the expiry date and a named owner on both your side and the vendor's side. Ask each tool vendor how they rotate keys and how much notice they give, because their process sets how far ahead you must start. Schedule reminders well before the earliest expiry date in the register and test a rotation in staging before it is needed in production.
Backups for an LTI integration must cover more than the database. The MySQL and MongoDB data hold course structure, learner progress and grades, but the LTI setup is split between platform settings, the Tutor configuration and the external tool. A restore that brings back the database without those references can give you a running site that cannot launch any tool. Back up the Tutor configuration and the secrets it references, the tool registrations with their client and deployment identifiers, and a record of where each private key is stored. Keep the key material in your secrets store and out of the general backup archive. Restore the set into a staging environment at least once to confirm that the references still match.
Re-test LTI after every Open edX release upgrade and after every change on the external tool side, including a new tool version, a changed launch URL or a key rotation. Only the latest named release is supported, so you will move through releases on a regular schedule. Verawood is the current named release, published on 30 July 2026, and Willow and Xylon are listed for December 2026 and June 2027. The Verawood release notes list LTI Advantage Complete certification among its additions, so confirm how it affects your existing tool registrations before you upgrade. The upgrade path and general post-go-live support are covered in the upgrades and support topic. Ongoing LTI testing against each release and tool change can be scoped as a retainer.
Keep a runbook that a second engineer can follow at 2 a.m. without contacting the person who built the integration. It should list each external tool with its vendor contact and support route, the owner of each key and certificate on both sides, and the steps to disable a single tool launch without taking the whole course offline. Include rollback steps for a failed upgrade or tool change, with the location of the last known-good configuration backup and the order in which to restore it. Review the runbook after each release upgrade, after each tool change and whenever the people named in it change roles, so the document stays accurate when it is needed.
Questions teams ask before building Open edX LTI integration
Can our team build an Open edX LTI integration ourselves?
Yes, if your engineers already know Django, LTI 1.3 security and how your LMS administration works, but the deciding factor is who owns the integration after go-live. Open edX is licensed under the AGPL, so the code is available to inspect, and the maintainers recommend running the platform through Tutor or a service provider instead of a bare-metal install. The hard part is less the handshake itself than keeping tool registrations, keys and grade mappings correct on both sides across releases. Before you decide, confirm whether your team has launched a live external tool before, whether it can test against a sandbox tool provider, and who will repeat those tests at each upgrade.
What does our side need to provide for an LTI project?
The work depends on your people and networks as much as on the platform, so expect to supply the following:
- Tool owners: a named contact for each external tool and for the Open edX instance, with authority to approve registration changes.
- Key exchange: a documented process for sharing client IDs, deployment IDs, public keys and endpoint URLs between the two systems.
- Network changes: firewall or proxy rules so the platform can reach tool endpoints and tools can reach the LMS for launches and grade calls.
- Test accounts: instructor and learner accounts in both systems, plus access to the vendor's sandbox.
Approvals often set the pace more than the code does, so ask your security and vendor management teams for their lead times before a schedule is agreed.
How long does an Open edX LTI integration take?
The duration depends on scope and dependencies, not on a general rule. Embedding an external tool in courses is a different job from offering Open edX content to another LMS, because the second requires your platform to act as the tool provider, with its own registration, deep linking and grade handling. The main drivers are the number of tools, whether grade passback is required, whether deep linking or roster provisioning is included, custom roles and data mapping, the availability of each vendor's test environment, and how many environments you need (development, staging and production). DeployOpen agrees the duration in the written scope, so ask for a schedule that lists each dependency and who owns it.
Can LTI replace SSO on our Open edX site?
No, LTI and SSO solve different problems. LTI launches an external tool from a course context and passes a signed identity message for that launch, while SSO governs how learners and staff sign in to the platform itself. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, so LTI is one identity option among several. Using it for everyday sign-in ties every session to the launching platform, which most identity teams will not want for primary access. A common pattern keeps a primary SSO for platform login and uses LTI for tool launches. Confirm with your identity team which sign-in paths learners and staff need, and how accounts will be linked and provisioned.
Can grades from an external tool pass back to any LMS?
Not automatically. Grade passback works only when both sides implement the grade services defined in the LTI Advantage specifications, and when the tool sends scores to the correct line item. Open edX can receive grades through its LTI setup when the tool and platform both support the relevant services, but the exact LTI version, services and mapping must be confirmed for each tool. In the other direction, offering Open edX content to another LMS, the receiving LMS must be able to return grades to the Open edX side. Verify this with a test course: launch the tool, submit a score, check the gradebook on both sides, and confirm how resubmissions and partial credit are handled.
What changes in an LTI integration after an Open edX upgrade?
Upgrades can change launch and grade behavior, so every integration path needs regression testing after each upgrade. Open edX states that only the latest named release is supported, which makes upgrades a recurring cost of ownership rather than a one-time event. Verawood, the current named release published on 30 July 2026, added LTI Advantage Complete certification along with a new Studio sidebar and frontend plugin slots. Areas that deserve checks include authentication settings, LTI registration handling, library versions and any custom plugin that touches launches or grade submission. Read the release notes for your target release, test on a staging copy with each tool's sandbox, and record each tool's configuration so it can be reapplied.
What should a fixed-scope quote for LTI include?
A fixed-scope quote should name every tool, the LTI direction and version, the services in scope and what is excluded. Ask for:
- Tool list: each tool, its owner and whether launch, deep linking, provisioning or grade passback is included.
- Process: the key and registration steps, environments covered and the test plan, including accounts and sandbox access.
- Handover: documentation, runbooks and a training session for your administrators.
- Post-go-live terms: what support or upgrade testing is covered, and what triggers a change order.
The build is a one-time cost, while upgrade testing and tool changes recur. Vendor test access may carry its own fees, and your team's approval time is an internal cost. DeployOpen provides a quote from the written scope and does not publish a price list.
How DeployOpen scopes, builds and hands over LTI work
DeployOpen plans, implements, tests, documents and supports Open edX LTI integration inside your own infrastructure, whether you embed external tools in courses or offer Open edX content to another LMS. Engagements are fixed-scope, with the written scope setting deliverables before work starts.
How we scope
- Confirm which direction the integration runs: external tools inside Open edX courses, or Open edX content offered to another LMS.
- Record the LTI version and the tool or platform list, including whether LTI Advantage services such as deep linking and grade return are needed.
- Agree in writing which authentication, launch and grade passback flows are in scope, and which named Open edX release the work targets.
How we build
- Configure the LTI tool or platform registrations, keys and endpoints in a Tutor-based or Kubernetes Open edX environment you control.
- Set up the authentication and user mapping so launched learners reach the right course, and document each claim or identity field used.
- Test launches, deep linking, and grade passback end to end in a staging environment before any change reaches production learners.
How we hand over
- Deliver configuration records, registration details and runbooks that name each tool, endpoint and secret location, without exposing secret values.
- Provide test scripts and expected results for launch, role mapping and grade return so your team can repeat checks after changes.
- Walk your administrators and course teams through troubleshooting steps for failed launches and missing grades.
How we support
- Review LTI configuration again when you upgrade Open edX, since the platform supports only its latest named release and each upgrade may affect integrations.
- Retest launches and grade passback after changes to tool providers, certificates or Tutor configuration.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing separately from the initial build.
