OneRoster 1.2 vs Ed-Fi vs LTI Advantage: EdTech Interop Guide

A district RFP lands on a product team’s desk in spring 2026 asking for four things: OneRoster 1.2 rostering with gradebook pass-back, LTI Advantage for SSO and tool launch, Clever sync, and Ed-Fi v7 reporting to the state longitudinal data system. Lose any one of those, lose the deal. The team is two engineers strong. This pattern is now the norm for any edtech platform selling into US K-12 and higher education, and the same standards stack is migrating into European and Latin American markets.

Interoperability is the part of edtech that decides whether a product can be sold at district or state level, regardless of how good the learning experience is. This post is for edtech engineering leads, product managers, and integration teams scoping a multi-standard backend. It compares the four operative standards (OneRoster 1.2, Ed-Fi, LTI 1.3 with LTI Advantage, and Caliper) on what they actually do, when each is required, and how to ship support for all of them without doubling backend headcount.

The four interop problems every edtech platform hits at scale

Every learning product that scales beyond a single school runs into the same four interop problems:

1. Rostering: who is in this class, with what role, and what does that role allow?
2. Authentication and tool launch: how does a user sign in from an LMS or district portal, and how does the platform receive identity context?
3. Gradebook pass-back: how does the platform send grades, completion, and progress back to the system of record?
4. Learning analytics events: how does the platform emit structured learning event data for state reporting, research, or institutional analytics?

The historical solution was a custom integration per district. That model collapses past 10 to 20 districts. The standards stack is the structural answer.

OneRoster 1.2: what changed and why CSV is not optional

OneRoster, maintained by 1EdTech (formerly IMS Global), is the rostering standard for K-12. Version 1.2 superseded 1.1 in 2023, and 1.1 is sunset for new certifications. The changes that matter:

• Gradebook pass-back is now in scope. OneRoster 1.2 includes the Gradebook service alongside the Rostering service. A product that supports gradebook pass-back through OneRoster 1.2 satisfies what previously required LTI AGS.
• CSV and REST profiles are both standardized. The CSV profile is the path most district SIS systems use for nightly export. The REST profile (with OAuth 2.0 client credentials) supports real-time queries. Production platforms must support both; districts vary.
• Demographics, courses, classes, enrollments, terms, academic sessions are all structured entities with stable identifiers.

The CSV profile is where engineering teams most often underbuild. A district will deliver a nightly OneRoster CSV bundle (six files: users, classes, enrollments, courses, academicSessions, orgs). The platform must consume that bundle, validate it, resolve identifiers against prior loads, surface anomalies, and apply changes idempotently. Building this once carefully (with diff reporting and a manual review queue for ambiguous deletes) means every new district onboards in days instead of weeks.

The pitfall on the REST profile is API rate limits. A district with 50,000 students and 2,000 classes will fetch the full roster in tens of thousands of requests. The OneRoster spec allows paging but does not mandate batch sizes; districts vary widely. A production client should adapt page sizes dynamically and cache the resolved roster locally.

LTI 1.3 and LTI Advantage: deep linking, NRPS, AGS explained

LTI (Learning Tools Interoperability) 1.3 is the current standard for tool integration with LMSs. LTI Advantage is the umbrella for the three core extension services:

• Names and Role Provisioning Service (NRPS): lets the tool fetch the roster for a launched context. Useful when LMS-provided launch context is not enough.
• Assignment and Grade Services (AGS): lets the tool send grades, scores, and completion back to the LMS gradebook.
• Deep Linking: lets the LMS embed specific resources from the tool, not just a generic launch.

Every major LMS supports LTI 1.3: Canvas, Schoology, Brightspace, Moodle, Blackboard Ultra, Open edX, and Google Classroom (through the Classroom Add-ons program). Most districts require LTI Advantage certification, not just LTI 1.3 baseline.

The implementation pattern that scales:

1. A platform-level OIDC and JWT signing service handling the LTI 1.3 launch handshake, with a single keyset rotation strategy across all tenants.
2. A tool registration UI for institutional admins, exposing the platform’s configuration JSON, public keys, and supported scopes.
3. A launch handler that maps the launch context to the platform’s internal user and class models, resolving identifiers in a deterministic way (LTI substitution variables, lis_person_sourcedid, custom claims).
4. AGS support that writes grades back to the LMS in the format expected by each LMS family (Canvas, Schoology, and Blackboard have subtle differences in how they handle line items and result types).

The mistake teams make is treating LTI as a per-customer integration. LTI 1.3 is fundamentally a single integration that works across all compliant LMSs. The work is in the OIDC handshake, the platform service, and the AGS gradebook mapping. After that, onboarding a new LMS is a configuration exercise.

Ed-Fi ODS/API for state reporting: when you actually need it

Ed-Fi (maintained by the Ed-Fi Alliance) is a state-level longitudinal data system standard. Roughly 30 US states standardize on Ed-Fi for state reporting; many state SLDS systems consume data from district Ed-Fi ODS (Operational Data Store) instances.

Ed-Fi ODS/API v7.x is the current generation, with v8 in technical preview. The data model is much larger than OneRoster (hundreds of entities covering attendance, assessments, discipline, graduation, special education, finance, and more).

Ed-Fi support is required when:

• The platform is selling into a state where state law mandates Ed-Fi reporting (Texas, Indiana, Wisconsin, Ohio, and many others).
• The platform is providing data that the district must report to the state (attendance, assessment outcomes, intervention data).

It is not required for most learning tools that only consume rostering and emit grades. A tool that needs only roster and gradebook can satisfy district needs through OneRoster 1.2 and LTI AGS, regardless of whether the state uses Ed-Fi.

For platforms that do need Ed-Fi support, the right architectural pattern is to keep the Ed-Fi adapter as a translation layer over the canonical internal model. Ed-Fi version increments are frequent and breaking; tying the platform’s data model directly to Ed-Fi means rewriting every time the Alliance ships an update.

SCORM, xAPI, cmi5, and Caliper: choosing a learning-events format

The learning event format question splits the market:

• SCORM 1.2 and 2004 remains dominant in corporate LMS content (estimates suggest around 60% of corporate L&D content still ships as SCORM). SCORM is built around a JavaScript runtime API talking to the LMS during a session. Limited data model. Largely sunset for new K-12 content but very much alive in compliance training and higher education.
• xAPI (Experience API, sometimes Tin Can) captures arbitrary learning experience statements (actor, verb, object, context, result) and sends them to a Learning Record Store. Much richer than SCORM but lacks the structural contract that institutional consumers want.
• cmi5 is the bridge: an xAPI profile that combines xAPI’s flexibility with SCORM-like launch and reporting structure. cmi5 is the recommended format for new content authoring when interop with multiple LRS systems is needed.
• IMS Caliper Analytics 1.2 is the K-12 and higher-ed flavor, with a JSON-LD payload and a defined set of event types (NavigationEvent, AssessmentEvent, GradeEvent, etc.). Caliper is the preferred analytics format for institutional consumers integrating into LMSs that already speak OneRoster and LTI.

For a new platform in 2026, the practical advice:

• If selling primarily into K-12 or higher ed, default to Caliper for events and cmi5 for any embedded content the platform produces.
• If selling into corporate L&D, support SCORM 1.2 and 2004 because that is what existing content libraries are built in, and add cmi5 for new content.
• xAPI without cmi5 is increasingly rare in production. Most LRS deployments now expect cmi5-shaped statements.

Clever and ClassLink: the real district onboarding path

In North America, two SSO and rostering brokers dominate the district onboarding path: Clever and ClassLink. Both speak OneRoster. Both provide a marketplace experience for districts to onboard apps quickly. For an edtech platform selling into US K-12, listing on both Clever and ClassLink is typically a higher-leverage move than building direct OneRoster integrations with hundreds of individual districts.

The integration pattern is essentially:

1. Register the platform with Clever and ClassLink as a developer.
2. Implement Clever Instant Login (OAuth-based SSO) and ClassLink LaunchPad SSO (SAML or OpenID Connect).
3. Subscribe to roster sync events from each broker.
4. Surface a single platform-level admin experience that lets a school or district admin connect the platform with their broker account.

For platforms also selling into states with their own SSO brokers (Texas Login.gov pilots, Ohio OH-ID, the state-level identity broker landscape in California and New York), the same pattern applies with additional adapters.

Pay attention to data-sharing contract law

Standards alone are not enough to ship in education. Data-sharing contracts have legal requirements that vary by state:

• California AB 1584 governs student personal information handling by third-party contractors. A platform contracting with a California district will sign a 1584 addendum specifying purpose limitation, retention, deletion, and security.
• New York Education Law 2-d requires similar but stricter terms, including encryption at rest and in transit, breach notification timelines, and parent access rights.
• Illinois SOPPA, Texas SB 820, Connecticut and Maryland have their own variants.

The pragmatic move is a single template addendum that satisfies the strictest commonly applicable statute (typically New York Ed Law 2-d), with state-specific riders. Legal review per district is unavoidable but the engineering posture (data minimization, retention controls, deletion APIs, breach detection) is a once-built capability.

Reference architecture for a multi-standard edtech backend

The architecture that supports all four standards without quadrupling engineering effort looks like this:

• A canonical internal data model for users, classes, courses, enrollments, grades, and learning events. The model is the platform’s source of truth.
• Standard-specific adapters for OneRoster (CSV and REST), Ed-Fi (REST), LTI (launch, AGS, NRPS, Deep Linking), Caliper (JSON-LD emit), SCORM and cmi5 runtime. Each adapter translates between the canonical model and the wire format.
• A roster reconciliation service that ingests data from multiple sources (OneRoster, Clever, ClassLink, direct district imports) and merges into the canonical model, surfacing conflicts.
• A grade write-back service routing grades to the right destination (LTI AGS, OneRoster Gradebook, direct LMS API) based on the deployment configuration of the tenant.
• An event bus emitting learning events in Caliper, xAPI, or platform-specific shapes based on subscriber configuration.
• A tenant configuration store holding the per-deployment integration settings: which LMS, which broker, which state, which contract addendum applies.

Built once, this architecture supports every common district and institutional deployment. New customer onboarding moves from custom integration projects to configuration. The engineering effort to build it is real (typically 6 to 12 months for a focused team) but the alternative (custom integrations per district) does not scale past a hundred customers.

What to ship first, what to ship later

If the platform is new and the team is small:

1. LTI 1.3 with LTI Advantage first. It is the lowest-friction entry into any LMS-based market and required by virtually every district and higher-ed institution.
2. OneRoster 1.2 REST profile second, with CSV close behind. This opens K-12 districts that drive rostering through SIS exports.
3. Clever and ClassLink listings as soon as direct district sales become a pattern. The marketplace effect is real.
4. Caliper when institutional analytics buyers start asking for it (typically at the school district director of curriculum level).
5. Ed-Fi only when entering states that require it for the platform’s data category. Ed-Fi is heavy; pay the cost when the revenue justifies it.
6. SCORM and cmi5 if the platform produces or imports authored content, especially for corporate or higher-ed customers.

The standards landscape feels overwhelming when read end-to-end. It is much more navigable when sequenced by the customer segment the platform actually sells to. A tool sold to high school math teachers does not need Ed-Fi or SCORM. A tool sold to district curriculum leaders for elementary literacy intervention probably needs OneRoster, LTI, Clever, ClassLink, and depending on the state, Ed-Fi. The trick is to match the standards stack to the actual buyer, not to the longest interoperability checklist.