When a learning app enrolls the right students automatically, passes grades back to the gradebook, and signs students in without passwords, that is not luck — it is interoperability standards doing quiet work. The two standards district administrators encounter most are LTI, which lets learning tools plug into a learning management system, and OneRoster, which moves enrollment and gradebook data between systems. Both are maintained by the member nonprofit 1EdTech Consortium, formerly known as IMS Global Learning Consortium, and both have become de facto requirements in district procurement.
What is interoperability, in practical terms?
Interoperability is the ability of two education systems to exchange data and work together without custom engineering for every connection. In a district without it, a technology coordinator exports comma-separated files from the student information system, reshapes them in a spreadsheet, and uploads them into each of dozens of apps by hand, every time enrollment changes. With standards-based integration, the student information system publishes one roster feed and every compliant app consumes it. The National Center for Education Statistics has documented in its school technology surveys that districts now operate large portfolios of digital tools, which is exactly why manual rostering stopped scaling.
What does LTI actually do?
LTI, or Learning Tools Interoperability, defines how an external tool launches from within an LMS such as Canvas, Schoology, or Google Classroom and how results flow back. The current version, LTI 1.3, replaced the older shared-secret approach with a modern security model built on the open OpenID Connect protocol. For a district, the practical benefits are three: students click one link instead of managing separate accounts, teachers see scores appear in the gradebook automatically, and the district does not hand every vendor a local password file. The related Advantage suite adds services for assigning and returning coursework, deep linking to specific content, and reporting names and roles within a course context.
What is OneRoster and why does it matter?
OneRoster is a specification for the boring but essential data of school operations: students, teachers, classes, enrollments, and grades. It defines a common file format and a data-exchange API so that a student information system such as PowerSchool or Infinite Campus can feed roster data to any compliant product. Before OneRoster, every vendor defined its own import template, and a mid-sized district could easily spend hundreds of staff hours a year reformatting rosters. Certification through 1EdTech's conformance program tells a district that the vendor's implementation has actually been tested against the standard rather than merely advertised.
How do these standards compare on what they connect?
| Standard | What it moves | Typical systems involved |
|---|---|---|
| LTI 1.3 / Advantage | Tool launch, single sign-on context, scores and assignments | LMS and external learning apps |
| OneRoster | Students, staff, courses, enrollments, grades | Student information system and virtually any district app |
| QTI | Assessment content and results | Item banks and testing platforms |
| Caliper Analytics | Event-level learning activity data | District data warehouse and learning apps |
Why should a district administrator care during procurement?
The cheapest time to solve integration is before signing a contract. Districts that specify 1EdTech certification in their requests for proposals consistently report faster onboarding of new tools, because the vendor connects through an existing pattern instead of a bespoke project. The question to ask a vendor is concrete: is your product certified for LTI 1.3 and OneRoster, and can you name the student information systems you integrate with in production? A vendor that answers with generalities about flexibility is signaling months of custom work at district expense.
What does the standards landscape look like beyond 1EdTech?
1EdTech standards dominate instruction-side integration, but they sit in a wider ecosystem. The Schools Interoperability Framework, now usually called SIF, was an earlier effort led by specification bodies and still appears in some state data systems. Each state also imposes its own data collection formats for reporting, which is a different problem from vendor interoperability, and the Ed-Fi Alliance, a foundation-supported nonprofit, provides a data standard and tooling that many states and large districts use to unify operational data for analytics. A district technology director's real architecture usually mixes all of these.
What does a basic district integration architecture look like?
In a typical mid-sized district, the student information system is the source of truth. Nightly or on-demand, it publishes a OneRoster feed that flows either directly to each application or through a district-operated integration hub that adds filtering and auditing. The learning management system consumes that feed and, using LTI 1.3, launches external tools with a secure token instead of a password. Grade results flow back along the same paths. When a new tool is added, the checklist is short: roster connection tested with real enrollment changes, launch tested from inside the LMS, grade passback verified against the gradebook, and an account-deprovisioning test run for a departing student — the step most often skipped and most regretted.
What typically goes wrong with interoperability projects?
Practitioners describe a familiar failure pattern. First, a district buys a promising tool that lacks certified integration, then pays the vendor or a consultant to build one, and finally maintains fragile custom code that breaks when either system updates. Second, rostering is treated as a one-time setup rather than an ongoing service, so mid-year enrollment changes never reach the app and teachers lose trust in it. Third, districts assume a standard guarantees identical behavior across vendors, when in practice vendors implement optional parts of specifications differently. The remedy is mundane: written integration requirements, named ownership in the technology department, and a test enrollment cycle before each school year.
How has the standards picture changed recently?
Two shifts matter for districts. Security expectations tightened: LTI 1.3, published in 2019, replaced the older shared-secret model after years of concern about credential handling, and districts now routinely reject tools still running LTI 1.1. And the arrival of generative artificial intelligence tools has pushed 1EdTech to extend its work on data governance, since districts want to know what student activity leaves their environment when an AI feature is switched on. Standards bodies move slower than vendors' marketing, so a district's best protection remains contract language about data flows, not certification logos alone.
What should a small district without integration staff do?
Small districts rarely have engineers, and the realistic path is leverage rather than construction. Most student information system vendors now sell or include roster-publishing connectors that push OneRoster feeds to major apps with configuration rather than code. Regional education service agencies in many states operate integration hubs for their member districts. And limiting the number of purchased tools — the portfolio discipline many districts adopted after federal pandemic funding expired in 2024 — reduces the integration surface faster than any project could. Interoperability standards reward restraint as much as they reward engineering.
For more context, read How School Districts Plan a Learning Management System Migration.
For more context, read ai tutors evaluation.
For more context, read edtech contract red flags.