LTI® or an LMS API?
The short answer
LTI® is a standard — published by 1EdTech Consortium, Inc. and specified here — so one implementation reaches every compliant LMS, and it starts from inside a course at the moment a user clicks. An LMS API is proprietary, so it is separate work for each vendor — and it can reach things the standard never exposes.
For nearly every product the answer is LTI® first, an API later and only where something specific demands it.
They are not the same shape
The comparison is usually framed as two ways of doing one job. They are two different jobs.
LTI® is inbound and event-driven. A user clicks; your tool is launched with a signed statement of who they are and where they came from. Nothing happens until somebody does something.
An LMS API is outbound and on demand. Your server asks the LMS for something, whenever it likes. Nobody has to be present.
That is why "which is better" has no answer, and "which does what I need" does.
| LTI® | LMS API | |
|---|---|---|
| Works across platforms | One implementation, every compliant LMS | Separate work per vendor |
| Direction | Platform launches your tool | Your server calls the platform |
| Needs a user present | Yes, for the launch | No |
| Identity | Comes with it, signed | You resolve it yourself |
| Setup per institution | Add a tool | Issue and scope credentials |
| Reach | What the specification defines | Whatever the vendor exposes |
| Breaks when the vendor changes | Rarely — it is a standard | Yes |
Decide by what you need
You need a user to open your product from a course. LTI®. There is no API equivalent — a REST endpoint cannot put a link in a course and sign a user in.
You need to write grades. LTI® covers it with Assignment and Grade Services, across every platform. An API can also do it, one vendor at a time.
You need the roster of a course somebody launched from. Names and Roles covers it.
You need data about people who have not launched, or courses nobody opened. That is beyond what LTI® defines. An API — or, for institution-wide rostering, OneRoster.
You need something vendor-specific — creating courses, reading discussion posts, manipulating modules, bulk administration. API. The standard deliberately does not cover this, because it is not standard.
You need to support many LMSes with a small team. LTI®, decisively. This is the argument that usually settles it: an API integration is not one project but one per vendor, each with its own auth, its own shapes, its own rate limits, and its own breaking changes.
The cost people underestimate
Both need the institution's cooperation, but not equally.
Adding an LTI® tool is a routine administrative task. The values are not secret, there is a standard process, and on platforms with dynamic registration it is one pasted URL.
API access generally means credentials issued by an administrator, scoped to permissions they have to approve, held by you, per institution. It is a longer conversation and a security review, and it is the reason API integrations stall in procurement more often than they fail technically.
Multiply that by the number of institutions and it is often the deciding factor rather than the code.
Why most products end up with both
A common and sensible arrangement:
- LTI® for the launch, identity, grades and roster — everything the standard covers, working everywhere at once.
- An API for one platform where a specific customer requirement needs something vendor-specific, built once, for the platform that justified it.
The order matters. Build LTI® first and you work everywhere immediately. Build the API first and you have a deep integration with one vendor and no way into any other.
Where LTIAAS fits
LTIAAS covers the LTI® half — launch, identity, grades, roster, deep linking — across every compliant platform, without you implementing the protocol or holding keys.
It also helps at the boundary. Where you do need a vendor's own API, the hard part is often getting an authorised token for the right user at the right institution. LTIAAS supports an OAuth 2.0 flow to a platform's proprietary API, so the credentials for that call can be obtained through the same integration rather than being a second system to build. The OAuth2 guide covers it.
Common questions
What is the difference between LTI® and an LMS API?
LTI® is a standard, so one implementation reaches every compliant LMS, and it works from inside a course at the moment a user clicks. An LMS API is proprietary to one vendor, needs separate work per platform, and can reach data LTI® never exposes.
Which should I build first?
LTI®, in almost every case. It is what makes your product reachable from inside a course, it works everywhere at once, and it needs no institution-specific credentials. Add an API integration when a specific requirement needs it.
Can I use both?
Yes, and mature products usually do. LTI® handles the launch, identity and grades; an API covers the vendor-specific things the standard does not define.
Does using an LMS API require the institution's cooperation?
Yes, more than LTI® does. It generally needs credentials issued by an administrator with a scope they have to approve, per institution, and the conversation is longer than adding a tool.
Next
- OneRoster vs LTI® — for institution-wide data
- LTI® 1.3 as a service — build it or buy it
- How to add LTI® 1.3 to your application
