K-12 LMS Integration: What EdTech Vendors Must Know

When does a school decide whether your product deserves a place in the classroom? For many EdTech vendors, the answer comes long before a teacher launches the first lesson.

65% of U.S. school districts now require a review by IT staff before any new software reaches a classroom, according to CoSN’s 2026 State of EdTech report. Eighty-six percent have a formal process for vetting tools before teachers can use them at all, including free ones. 

Choosing an app on instinct has stopped being how most software gets into a classroom. IT staff decide most of that before a demo is ever scheduled, working from a written specification the vendor submits in advance. 

The specification asks whether a product connects to the school’s learning management system without custom engineering on the district’s side, whether it can pass grades back automatically, and whether it handles student data in a way the district can defend if a parent or an auditor asks about it later.

This guide covers what that specification actually requires for K-12 LMS integration in 2026: which platforms to build for, which standards satisfy which requirement, and where vendors lose deals by treating integration as a technical detail instead of the reason the deal gets approved.

The K-12 market continues to revolve around three major platforms: Canvas, Google Classroom, and Schoology. Which one leads shifts from year to year, and market trackers rarely agree on the exact split at any given moment. What doesn’t shift is the trio itself, and the scale each percentage point represents. 

The U.S. runs close to 18,000 public school districts across roughly 100,000 public schools, according to NCES. A platform holding even a quarter of that market covers thousands of individual districts, each running its own procurement process and its own IT review.

Canvas

Canvas remains one of the most widely adopted LMS platforms across K-12 districts, particularly in larger school systems and districts with established digital learning programs. Its mature implementation of the LTI 1.3 standard gives vendors a predictable path for launching external tools, supporting single sign-on, sharing content, and returning grades to the LMS.

For vendors building standards-based integrations, Canvas often becomes the first platform on the roadmap because the engineering work transfers well to other LTI-compatible systems.

Google Classroom

Google Classroom follows a different path. It doesn’t support LTI, which means every integration relies on Google’s APIs instead of an industry standard. Teams planning only around LTI usually discover this constraint after development has already started.

That extra engineering effort pays off with access to a large share of K-12 schools, especially districts that rely on Google Workspace across teaching, collaboration, and device management. 

Many vendors reuse parts of their existing integration architecture to reduce the amount of platform-specific development, though Classroom still requires its own implementation and ongoing maintenance.

Schoology

Schoology remains a key platform for districts working within the PowerSchool ecosystem. Schools using PowerSchool SIS often look for products that connect smoothly with both systems, reducing the amount of manual setup for teachers and administrators.

From an engineering perspective, Schoology supports the same standards-based approach as other LTI 1.3 platforms. From a commercial perspective, supporting Schoology gives vendors access to districts where PowerSchool already plays a central role in daily operations.

Here’s where the comparison stops being background trivia:

Most vendors treat this as a one-time decision: build LTI, or build an API integration, then move on. That choice works fine until a product needs to do something LTI wasn’t designed for, and the team building it finds out mid-project instead of during planning.

What LTI actually handles

LTI works as a single, standardized handshake between your product and an LMS. A student clicks into your tool from inside Canvas or Schoology, gets authenticated automatically, and any grade your product generates flows back into the school’s gradebook without a teacher copying numbers by hand. 

Build that handshake once, following the LTI 1.3 and LTI Advantage specifications, and it works across every LMS that’s certified against the same standard. That’s the entire appeal: one integration, many districts, no rebuilding per platform.

• Launch and authentication – a student opens your tool from inside the LMS, already signed in
• Grade passback – scores sync to the gradebook automatically through LTI’s Assignment and Grade Services
• Content selection – teachers pick specific content from your tool and drop it into a course through Deep Linking

Where LTI runs out of road

LTI covers launch, identity, and scores cleanly. It wasn’t built for file submissions, multi-part responses, or pulling data across multiple courses at once. A tool that needs a student to upload a video project, or needs to read enrollment data across an entire school rather than one course session, hits a wall LTI simply doesn’t address. 

Vendors who discover this after committing to LTI-only tend to bolt on a custom API later, at a worse time and a higher cost than if they’d planned for both from the start.

Custom API integration

An API integration works the opposite way: no shared standard, no certification body, and no default behavior to lean on. Every capability, from authentication to data sync, gets built and maintained against that platform’s specific API. Google Classroom requires this route entirely, since it has no LTI support to fall back on. 

The tradeoff is real: an API integration can reach into places LTI can’t (file handling, deep data access, cross-course queries), and every one of those capabilities costs engineering time that LTI would have delivered for free on a certified LMS.

Why vendors often run both

The choice between LTI and API isn’t binary in practice. A product handling straightforward launch, SSO, and grade sync gets there faster and cheaper through LTI on any certified LMS. The same product handling file submissions or building features Google Classroom doesn’t expose through LTI needs a custom API layer regardless. 

Mature EdTech platforms frequently run LTI for the parts LTI covers well and a custom API for the rest, rather than picking one approach and forcing every feature through it.

That split matters directly for the LMS and SIS integration work most vendors underestimate at the proposal stage: teams that scope LTI alone often discover the API requirement three months into a build, not during the estimate that won the contract.

LTI 1.1 still exists in older integrations, but most new K-12 implementations have moved toward LTI 1.3. Canvas and Schoology support the newer standard, and vendors entering district procurement conversations increasingly need to show that their integrations follow current security expectations.

The reason behind the shift goes beyond a version update. Districts connect external applications to systems that store student identities, course information, and academic records. 

As more EdTech products enter school environments, IT teams have less tolerance for authentication methods that were designed before current security requirements became common.

What changed between LTI 1.1 and LTI 1.3?

The biggest change happened around authentication and trust between systems.

LTI 1.3 introduced a security model based on modern web standards, including OAuth 2.0, OpenID Connect, and JSON Web Tokens (JWT). These technologies give LMS platforms and external tools a more controlled way to verify users, exchange information, and manage access permissions.

For vendors, the practical impact appears in three areas:

• More secure authentication: users can launch tools through the LMS without relying on older authentication methods.
• Better control over access: districts gain clearer visibility into which applications can access specific data.
• Stronger alignment with IT requirements: security teams can evaluate integrations against current technical expectations.

The protocol details matter to developers, but the business consequence matters to everyone involved: fewer security concerns during vendor review.

What happens if you stay on LTI 1.1?

The challenge usually appears during procurement rather than development.

A product running on LTI 1.1 may still function technically, yet district reviewers may ask why the vendor has not moved to the newer standard. That question can lead to additional security reviews, implementation discussions, and timeline delays.

For a district comparing several EdTech products, an integration that already meets current LMS requirements removes one more obstacle from the evaluation process.

Staying on LTI 1.1 also creates a longer-term maintenance issue. Engineering teams continue supporting an older integration path while LMS providers, certification processes, and district expectations move forward.

When should vendors upgrade?

The best timing depends on where the product sits today.

For a new EdTech product entering K-12, building with LTI 1.3 from the beginning avoids creating a migration project later. For products already supporting LTI 1.1, the upgrade often makes sense before expanding into new districts or pursuing larger contracts.

A useful question for product teams is simple:

Will this integration still satisfy a district’s technical review two or three years from now?

For vendors targeting long-term growth in K-12, LTI 1.3 provides the foundation districts increasingly expect when evaluating new software.

Classroom still has no LTI support, and none of LTI Advantage either. That hasn’t changed heading into 2026, and nothing in Google’s own developer documentation signals it’s coming. 

Worth one distinction here, since Google does ship something called Google Workspace LTI: it lets Workspace apps plug into Canvas or Schoology through LTI. That’s Google building an LTI bridge into other platforms, not Classroom accepting LTI tools itself. 

The two get confused often enough that it’s worth stating plainly: Classroom’s own integration path runs through the Google Classroom API and the Workspace Admin SDK, full stop.

The real cost isn’t just “more engineering”

Every vendor guide mentions that Classroom requires custom API work instead of LTI. Fewer mention the specific friction point inside that work: Google requires apps requesting sensitive or restricted data scopes to go through its own verification process before shipping. 

A vendor pulling roster data, grade information, or Drive file access has to justify why the app needs each scope, submit to a security assessment, and wait on Google’s review before the integration goes live. LTI integrations never face an equivalent gate. That review adds real time to a Classroom launch that a Canvas or Schoology launch simply doesn’t carry.

Reusing what LTI already solved

None of this means starting from zero. The architecture built for LTI still does useful work here:

• Authentication logic built for LTI’s launch flow maps onto OAuth 2.0, which Classroom’s API also uses, cutting the identity layer down to adaptation rather than a rebuild
• Grade-sync logic written against LTI’s Assignment and Grade Services translates conceptually to Classroom’s own grading endpoints, even though the API calls themselves differ
• Data models built to handle rosters and course structures for LTI-certified platforms need remapping to Classroom’s schema, not a redesign from scratch

Vendors who plan for this reuse from the start absorb Classroom’s API cost as an extension of work already budgeted for LTI. Vendors who treat Classroom as a separate project, scoped and built in isolation, end up paying for the same authentication and data-mapping logic twice. 

That distinction shows up directly in eLearning app development timelines: the same integration scoped with reuse in mind ships in a fraction of the time of one built as its own standalone effort.

LTI handles launch, SSO, and grade passback for a single course session. It says nothing about where the roster data came from before that session started, or how a student got enrolled in the right section in the first place. That’s a separate layer, and it runs through a different standard: OneRoster.

What OneRoster actually covers

OneRoster manages the flow of enrollment data between a school’s Student Information System (SIS) and any tool that needs to know who’s in which class, taught by whom, on what schedule. 

A district’s SIS holds the source of truth: student rosters, course sections, teacher assignments, term dates. OneRoster syncs that data into your product automatically, instead of a school administrator exporting a spreadsheet and a vendor importing it by hand every semester.

OneRoster 1.2, the current version, folded gradebook pass-back into the rostering service itself. A product built against OneRoster 1.2 can satisfy grade-sync requirements through OneRoster directly, without a separate LTI Assignment and Grade Services connection layered on top. Vendors who built their grade sync exclusively through LTI AGS and never touched OneRoster are running a narrower integration than what current SIS platforms expect.

Where vendors stop short

Most vendors treat LTI certification as the finish line. It covers what happens once a student is already inside a course and already knows their login. It says nothing about how that student’s account, section, and roster got created in your system in the first place. 

Without OneRoster, that step falls to someone typing names into a spreadsheet, or a district staff member re-uploading a CSV every time a class roster changes.

What breaks without it

• Manual rostering – a school’s IT staff or teacher has to add every student to your product by hand, then repeat that work each term as enrollment changes
• Roster drift – a student who transfers sections, drops a class, or a new student added mid-semester never gets reflected automatically, so your product’s roster and the school’s actual roster fall out of sync
• Broken grade passback – grades computed for a student who was never properly rostered through OneroSter have nowhere correct to land, generating support tickets that read as a grading bug but trace back to a missing rostering connection

Each of these becomes a support ticket category, not a hypothetical risk. A district running a manual rostering workaround for one semester tends to treat it as a reason not to renew, not a temporary inconvenience to tolerate.

How OneRoster and LTI fit together

Both standards come from the same certifying body, 1EdTech, and they’re designed to work as a pair rather than substitutes for each other. 

• OneRoster answers who’s enrolled in what. 
• LTI answers what happens once that enrolled student launches your tool. 

A vendor building for K-12 in 2026 needs both to clear certification cleanly, which is the same certification path covered under LMS and SIS integration work rather than two separate efforts run in parallel.

Most districts already run Clever or ClassLink across every building, trusting that provider with login data, MFA enforcement, and Google or Microsoft account sync. 

Building a custom SSO layer means asking that same district to vet a second identity system from scratch. Few take that trade when the one they’ve already approved does the job.

Edlink has carved out a third path worth naming: instead of acting as an identity provider itself, it works as an integration layer connecting a vendor’s product to whatever SIS or LMS a district runs, handling much of the OneRoster and LTI plumbing underneath. Which of the three a vendor builds against usually comes down to what the district in front of them has already standardized on.

District RFPs tend to expect the same things from this layer, regardless of provider:

• Multi-factor authentication, enforced district-wide rather than optional per user
• Native Google and Microsoft integration, matching whichever ecosystem the district standardized on
• Usage analytics, so IT staff can see what’s actually being used
• Provisioning tied to enrollment, so access starts and ends automatically as OneRoster data updates

A gap in any one of these stalls a deal at the same stage. A vendor with working SSO but manual provisioning hits the same wall as one with no SSO, because a district’s checklist treats identity and provisioning as a single requirement.

Once identity, provisioning, and LMS connectivity are in place, districts turn to another question: how does your product handle student data?

FERPA shapes much of that conversation. Districts expect vendors to collect only the information required for the product to function, protect it throughout its lifecycle, and give administrators clear control over who can access it. The review usually extends beyond policy documents into the technical design of the integration itself.

What districts ask for

FERPA doesn’t specify technical requirements, which is exactly why districts stopped relying on FERPA alone to evaluate a vendor. In its place, most now request a specific set of evidence before signing:

• A completed security questionnaire, covering encryption in transit and at rest, access controls, and data retention practices
• Audit logs, showing who accessed student data and when, stored in a way that can’t be edited after the fact
• Data minimization practices, meaning a vendor collects only the fields an integration actually requires, not every field an API happens to expose
• A SOC 2 Type II report, increasingly requested at the district level and close to standard for any vendor selling beyond a single-school pilot

None of these replace each other. A vendor with strong encryption and no audit logging still fails the review, because districts evaluate the full set rather than picking one control as sufficient proof of the rest.

Where FERPA applies specifically

At the exact point where an LMS or SIS hands student data to a third-party tool, FERPA treats that vendor as a “school official” only if the district keeps direct control over how the data gets used and maintained. That control has to be explicit in a contract, not assumed because the integration runs through a certified standard like LTI or OneRoster. 

FERPA also blocks the vendor from redisclosing that data to another party without consent, and it requires the district to be able to say, on request, exactly what data a given tool holds and why.

 A vendor whose integration pulls more fields than the product actually uses creates a FERPA exposure regardless of how secure the storage is, because the violation sits in the scope of access, not the quality of the encryption.

Why this gate comes before implementation

A vendor that passes LTI certification and builds a working OneRoster sync can still stall at this stage, because district procurement teams run the security and compliance review as its own step, separate from technical testing. Fixing a gap here after a contract is already in motion costs a vendor the deal timeline it built the rest of the integration to protect.

A technically complete integration can still fail during implementation if it creates extra work for the people using it. Districts evaluate integrations from several angles: deployment effort, daily classroom workflows, security requirements, and long-term maintenance.

Manual Roster management

Many districts still spend time creating classes, updating enrollment lists, and fixing account mismatches when data does not move automatically between systems.

Supporting OneRoster helps vendors automate student, teacher, and course data exchange between SIS platforms, LMSs, and their applications.

Users managing multiple accounts

A product that requires separate credentials creates additional support requests for district IT teams and confusion for students and teachers.

Connecting with identity providers such as Clever, ClassLink, Google Workspace, or Microsoft Entra ID allows districts to manage access through systems they already use.

Missing grade synchronization

Teachers expect assessment results to appear in the LMS without manual entry. When grades stay inside an external application, adoption often suffers because the workflow breaks after the lesson ends.

Supporting LTI Advantage Assignment and Grade Services allows grades to return directly to the LMS gradebook.

Integration documentation that does not match district review needs

District IT teams often review technical details before implementation begins. Missing information about data flows, permissions, security controls, or supported standards can slow down approval.

Clear documentation covering LTI, OneRoster, SSO, FERPA practices, and data handling gives different stakeholders the information they need during evaluation.

Multiple stakeholders involved in approval

An LMS integration affects different teams in different ways. IT focuses on security and administration, while teachers focus on classroom workflows and administrators look at adoption and reporting.

Vendors that prepare answers for each stakeholder reduce repeated questions and help districts move from technical review to implementation faster.

Everything in this guide so far describes what a compliant integration needs to do. This section is about who inside a vendor’s organization actually builds it, and that decision carries its own set of trade-offs separate from the technical requirements themselves.

Path 1: Building integrations in-house

An internal integration team makes sense for vendors that view integrations as a long-term product capability. This approach works especially well when a company has strong engineering resources, a clear K-12 strategy, and a limited number of platforms to support.

When building internally makes sense

Choose this path when:

• LMS and SIS integrations are a major part of your product strategy.
• Your engineering team can maintain connectors after launch.
• You need full control over the integration architecture.
• You have enough time to develop, test, and certify each connection.

Path 2: Partnering with an integration specialist

Working with an integration specialist can help vendors reach more districts without building every connector from the ground up. This approach often fits companies that need broad platform coverage, faster deployment, or additional expertise with education standards.

When partnering makes sense

Consider this approach when:

• Your product needs to support several LMS and SIS platforms.
• Your engineering team needs to focus on product features.
• You need integrations ready for upcoming district opportunities.
• Your team has limited experience with LTI, OneRoster, or education-specific requirements.

Advantages

• Faster access to multiple integrations
  Specialists often already have connectors, implementation experience, and knowledge of common LMS and SIS requirements. This can reduce development time compared with starting each integration independently.
• Lower maintenance burden
  A partner can handle platform updates, API changes, testing, and connector maintenance depending on the engagement model.
• Experience with district requirements
  Teams that regularly work with education integrations usually understand certification processes, security reviews, and common implementation issues.

Challenges

• Less direct control
  Your team depends on the partner’s architecture, release process, and prioritization decisions.
• Long-term cost considerations
  A partnership reduces internal engineering effort, though it introduces ongoing service costs that should be evaluated against the cost of building and maintaining the same capabilities internally.
• Vendor selection matters
  The quality of integration partners varies. Vendors should review platform coverage, certification status, security practices, support model, and experience with similar EdTech products before choosing one.

Build vs. partner: comparing the two approaches

Building an LTI 1.3 or OneRoster integration is only part of the process. Many districts also ask whether those integrations have been certified by 1EdTech Consortium (formerly IMS Global). Certification confirms that an implementation follows the specification and works as expected with other certified platforms.

For vendors, certification demonstrates that the integration has been tested against the standard rather than only within an internal development environment.

A 1EdTech certification typically validates:

• Correct implementation of the LTI 1.3 or OneRoster specification.
• Interoperability with other certified platforms.
• Compliance with required technical behaviors defined by the standard.

Certification does not replace a district’s security or compliance review. Schools still evaluate how a product stores student data, manages access, supports FERPA requirements, and fits into their existing technology environment.

Even so, certification helps remove one question from the procurement process. Instead of asking whether an integration follows the standard correctly, district IT teams can focus on evaluating the product itself.