Data Interoperability Between EdTech Tools and SIS Platforms
Why most classroom tools still lack certified data connections between school systems.
Before we get into standards and middleware and all the fun acronyms, let's get two words straight. Integration and interoperability are not the same thing, and the difference matters more than it sounds.
Integration is a point connection between two specific systems. Your tool talks to this district's PowerSchool. That's it.
Interoperability is broader. It's the ability to exchange data reliably across many systems using shared standards. Your tool talks to any SIS that speaks the same language.
Most EdTech products need two things from SIS integration:
Rostering. Receiving up-to-date class lists, teacher assignments, and enrollment data so the product can provision accounts automatically. Before the school year starts. Without IT manually creating users one by one.
Gradebook pass-back. Writing assessment results or completion data back into the SIS or LMS gradebook so outcomes are visible to teachers and administrators in the system they already use.
Without these connections, every data point gets entered twice. Once in your tool, once in the SIS. And over time, the two records drift. A student transfers. A class gets split. Your tool doesn't know. Now you have a support ticket, a frustrated teacher, and a locked-out kid.
Here's the part no one puts in the sales deck: every new district an EdTech vendor onboards will run a different SIS, a different version, or a different configuration of the same SIS. What works for one district's PowerSchool instance will not work for another's. This is hardly an edge case. It is the standard experience.
The direction data flows matters too. Some integrations are read-only. Pull the roster, done. Others are bidirectional. Pull the roster, push grades back. The technical approach differs for each, and assuming one when you actually need the other is a classic way to burn a deployment before it ever gets started.
The Standards Layer: OneRoster, LTI, Ed-Fi, and How They Divide the Work
The good news is that the industry has tried to solve this. The 1EdTech Consortium (formerly IMS Global) is the primary standards body. It's a global nonprofit whose members include institutions, vendors, and government agencies, and it develops and certifies the open standards most widely used in K-12 and higher education.
The key thing to understand about the major standards is that they aren't competing with each other. They cover different layers of the same problem.
OneRoster 1.2
This is the rostering and gradebook standard. It manages the exchange of class rosters, enrollment records, courses, organizations, and, as of version 1.2, gradebook data.
OneRoster supports two exchange patterns:
CSV. Nightly batch file drops, a bundle of six files.
REST API. Real-time queries with OAuth 2.0.
Version 1.2 superseded version 1.1 in recent years, and 1.1 is no longer eligible for new certifications. Consolidating gradebook pass-back into OneRoster 1.2 was a genuinely useful move. What previously required a separate implementation can now be handled within a single standard, with less surface area to get wrong.
LTI 1.3 with LTI Advantage
This is the launch and tool-connection standard. It enables seamless launch of external tools from within an LMS. A student clicks a link in Canvas or Moodle and lands inside your EdTech tool, already authenticated, with context passed along. No separate login.
It uses OAuth 2.0, OpenID Connect, and JSON Web Tokens. Major LMS platforms (Canvas, Brightspace, Blackboard, Moodle, Open edX) and major content providers have adopted it. If your tool needs to live inside an LMS rather than alongside it, LTI 1.3 is your answer.
Ed-Fi
Ed-Fi is the data warehouse standard favored in K-12 for district-level analytics. It defines a common data model so SIS, assessment, and learning management systems can populate a shared data store. It's maintained by the Ed-Fi Alliance, a nonprofit funded by the Michael and Susan Dell Foundation.
Ed-Fi is strong for longitudinal, multi-system reporting. It's not designed for real-time transactional exchange the way OneRoster REST is. It functions as the analytics layer rather than the operational one.
Together, OneRoster 1.2, LTI 1.3 with LTI Advantage, and Ed-Fi now represent the expected baseline for any EdTech platform selling into U.S. K-12 and higher education. The same stack is being adopted in European and Latin American markets. A district will use all three for different functions: OneRoster for rostering, Ed-Fi for analytics, LTI for tool launch. An EdTech vendor needs to know which standard a district expects for which job, because getting that wrong is its own flavor of painful.
Where Standards Adoption Breaks Down in Practice
Of the most-accessed classroom technologies analyzed in Instructure's 2026 Evidence Report (based on usage data from August through December 2025), only 33% had achieved a recognized interoperability certification such as OneRoster, LTI, or Project Unicorn.
Two out of every three tools that students and teachers were actually using were not certified. Their data connections, if they existed at all, were bespoke, custom, built by someone who no longer works there. It's a bit like finding out that two-thirds of the bridges in a city were built without an engineering permit. They hold, until they don't. And when they don't, it's always mid-semester.
Why does adoption lag this badly? The reasons are unsurprising:
Standards fragmentation. OneRoster, Ed-Fi, SIF, and xAPI each have their own constituencies. A district mandates one while a vendor has certified to another. Incompatibility without anyone being the villain.
Legacy system complexity. Many SIS installations are on-premises, years behind current versions, and simply do not expose the APIs the standard requires. You can't REST-connect to a system that doesn't have a REST endpoint.
IT capacity. Smaller districts rarely have the technical staff to implement and maintain standards-based integrations, even when both systems nominally support them.
Budget. Certification and implementation carry real costs. Under-resourced public school systems defer them, often indefinitely.
The engineering reality is more granular than those bullets suggest. A district delivering a nightly OneRoster CSV bundle produces six files: users, classes, enrollments, courses, academic sessions, and organizations. The receiving platform has to validate each file, resolve identifiers against prior loads, surface anomalies, and apply changes idempotently. Getting any of that wrong causes cascading rostering failures mid-year. Students locked out of accounts. Teachers missing class lists.
Privacy concerns add another layer. High-profile education sector data breaches in 2024 and 2025 made some districts more cautious about enabling data flows at all, regardless of standards compliance. In March 2025, the Department of Education required state agencies to certify FERPA compliance by April 30, 2025, an unprecedented mandate. Districts now must ensure that any EdTech vendor receiving student data operates under a formal data processing agreement. The bar for getting data access is meaningfully higher than it was a few years ago, and it's not going back down.
How Rostering Middleware Platforms Fill the Gap Between Standard and Reality
Because the standards adoption picture is this messy, an entire category of business exists to sit between EdTech vendors and SIS platforms and normalize the messiness. Rather than building direct SIS integrations, many EdTech vendors connect to a rostering intermediary that has already done the work of normalizing data across dozens of SIS platforms.
Clever built its network by offering districts a free single sign-on dashboard in exchange for rostering data, which it wrapped in a proprietary model and charged EdTech vendors to access. It works with more than 100 SIS and MIS platforms, claims two in three connections go live within 24 hours, and reports that its data integrity tooling can reduce support tickets by up to 27% year-over-year.
ClassLink inverted the model. It charges districts for its tools while offering EdTech vendors free access to data through the open OneRoster standard. It has built an ecosystem of over 2,400 integrations and also bridges OneRoster and Ed-Fi, which is useful for districts that need both. The open-standard approach gives EdTech vendors more portability than Clever's proprietary model.
Edlink takes a developer-first approach. It offers a unified API that EdTech vendors use to connect simultaneously with multiple LMS and SIS platforms. It has integrated over 60 EdTech companies, onboarded more than 25 million users, and serves more than 2,200 educational institutions. For a vendor that doesn't want to think about which underlying platform a district runs, Edlink abstracts it away entirely.
The business model differences matter more than they initially appear. Clever's proprietary data model creates dependency. If Clever changes its model or its pricing, you feel it immediately. ClassLink's open-standard approach gives you more options if you ever want to move. Edlink abstracts the platform entirely, which is either liberating or opaque depending on your situation.
What middleware buys you is real: faster district onboarding, normalized data across SIS flavors, reduced maintenance burden. The tradeoff is that you're now dependent on a third party's uptime, data model decisions, and commercial terms. You will also have less visibility into what the district's SIS is actually sending, which can be a problem during an incident when you're trying to figure out why a roster update silently failed.
Choosing Between Direct Integration, Standards-Based APIs, and Aggregators
No single approach is universally correct. The right choice depends on your product's stage, your target market, and how much engineering capacity you actually have.
Direct SIS API integration gives you the highest control and the lowest abstraction. You connect directly to each SIS's native API or file export. It's viable for products targeting a single district or a small, known set of SIS platforms. The problem is building and maintaining a separate connector for every SIS you support. It breaks whenever the SIS updates its API or data schema. A few districts in, it's manageable. Twenty districts in, it's a part-time job. Fifty districts in, it's a team.
Standards-based integration (OneRoster REST, LTI 1.3) is the build-once-connect-many approach. Higher up-front engineering investment, significantly lower long-term maintenance burden. But you have to support both CSV and REST exchange patterns, because districts vary widely on which they can actually deliver. A production platform that only handles one will get blocked in real deployments. And this approach requires the district's SIS to also be certified and configured, which, at the 33% adoption rate noted earlier, is far from guaranteed.
Aggregator or middleware (Clever, ClassLink, Edlink) is the fastest path to connecting with a large number of districts. The aggregator handles SIS normalization. Best fit for EdTech vendors scaling quickly across many districts without deep integration engineering resources. Introduces dependency, but for most vendors at most stages, it's worth it.
One relevant fact about the current landscape: a large majority of SIS implementations in 2025 are cloud-based, which improves the feasibility of REST-based standards integrations. But a substantial on-premises installed base remains. CSV-based exchange will be necessary for some districts for years to come, regardless of what the standards roadmap says.
In practice, mature EdTech platforms end up running all three approaches in parallel. Standards-based APIs for certified districts. Aggregators for the long tail. Direct connectors for strategic enterprise accounts.
What Reliable Interoperability Requires Operationally, Once Integrations Are Live
Getting an integration working is not the same as keeping it working. This is the part that gets underestimated most consistently.
The moment a district's roster changes, a student transfers, a class is split, a teacher is reassigned, every connected system needs to reflect that change accurately and quickly. This is a continuous obligation, not a one-time setup problem. The work doesn't stop once the connection is established.
The core things you need to have built:
Idempotent processing. Applying the same roster update twice must produce the same result. Nightly CSV bundles occasionally re-send prior data. Your system has to handle that without doubling records.
Identifier resolution. A student will have different IDs in the SIS, the LMS, and your tool. The integration layer must maintain a stable mapping across all of them. Lose this mapping and you effectively lose the student.
Anomaly surfacing. Validation has to catch malformed records, missing fields, and unexpected deletions before they propagate. A dropped enrollment record that silently removes a student's account mid-semester is a serious failure that a teacher will notice at the worst possible time.
Change detection. For REST-based connections, you need to poll or subscribe to changes efficiently. For CSV, you need to diff each bundle against the prior load.
Privacy and security don't stop at procurement. Data minimization means your tool should only receive the fields it actually needs, rather than a full student record dump. FERPA compliance obligations follow the data wherever it goes, including to any downstream service your tool calls with student data. API credentials, tokens, and access controls need rotation and audit logging.
SIS vendors also update APIs and data schemas, sometimes with breaking changes and sometimes without much notice. Your integration layer has to detect and absorb those changes without causing district-facing outages.
Teams that build this carefully the first time, with validation, idempotency, and change detection baked in from the start, onboard new districts in days. Teams that skip those steps spend weeks debugging every new deployment.
How the Interoperability Picture Is Likely to Shift Over the Next Few Years
The SIS market itself was valued at $13.2 billion in 2024 and is projected to reach $22.3 billion by 2030. It's consolidating around cloud-native platforms. As legacy on-premises deployments retire, REST-based standards integrations become progressively more viable. The technical barriers that force CSV-based workarounds today will shrink, though not on any timeline you'd want to bet a product roadmap on.
1EdTech's formation of 1EdTech Global Inc. as a separate 501(c)(3) in 2026 signals an intent to expand the standards work beyond its current footprint. What that looks like in practice will become clearer over the next few years.
A few things are worth expecting:
Certified interoperability will shift from a differentiator to a table stake. The 33% certification rate among widely-used classroom tools will rise, not because vendors suddenly got principled about it, but because districts will increasingly require it as a condition of procurement.
The privacy regulatory environment will tighten. The FERPA certification mandate of 2025 is a preview, not the final word. EdTech vendors that treat data governance as something to figure out later will run into procurement walls.
AI-driven personalization tools will push real-time data exchange requirements higher. Systems that adapt to individual students can't wait for a nightly CSV batch. The demand for low-latency, event-driven data flows will increase, putting pressure on both the standards themselves and the infrastructure running them.
None of this resolves the fundamental tension at the center of this problem: districts want data control, EdTech vendors need data access, and the standards are the negotiated middle ground between those two interests. The standards are genuinely useful, but they're only as good as the adoption and implementation behind them. And right now, implementation is where most of the work still lives.
