OneRoster
OneRoster is an open standard from 1EdTech (formerly IMS Global) for exchanging roster data — students, staff, classes, enrolments and demographics — between a student information system and the applications that need it.
| REST API | CSV bundle | |
|---|---|---|
| How it moves | Application pulls over HTTPS, OAuth 2 | Zipped CSV set, usually dropped to SFTP |
| Freshness | On demand; supports incremental pulls | Whatever the scheduled export produces, typically nightly |
| Setup burden | Credentials, endpoint, scopes | SFTP account and a scheduled job |
| Failure mode | Rate limits, token expiry | Truncated or partial file — the dangerous one |
| Best for | Districts whose SIS exposes it | Districts whose SIS does not |
What it actually specifies
OneRoster defines both a data model and the ways to move it. The model covers the entities every school application needs and almost every application models slightly differently:
- Orgs — districts and schools, in a hierarchy.
- Users — students, teachers, administrators, parents and guardians, with role assignments.
- Courses and classes — the course catalogue and the actual sections that meet.
- Enrolments — which user is in which class, in which role, over which date range.
- Academic sessions — terms, semesters, grading periods.
- Demographics — optional and frequently omitted, for good privacy reasons.
There is also a gradebook extension for passing assignments and results back to the SIS. Most communications vendors implement only the roster half, which is the correct scope for the job.
The date range on enrolments is the field that quietly matters most. Effective-dated enrolments are what let a system know a student has withdrawn rather than simply vanished from a file — and that distinction is the difference between stopping messages to a family and continuing to message them for months.
Why a district CTO should care
The commercial argument for open rostering is portability. If every application in your stack consumes the same standard, replacing one of them is a configuration change rather than a bespoke integration project. If instead each vendor built a proprietary connector to your SIS, every replacement is a negotiation and the incumbent knows it.
That is the entire lock-in mechanism in K-12 procurement, and it is why "do you support OneRoster?" is a better first question than any feature question. A vendor who only integrates through their own partner programme has made switching expensive by design.
Rostering intermediaries — Clever and ClassLink being the two most common in US K-12 — sit between your SIS and your applications and emit OneRoster-shaped data to downstream vendors. For most districts that is the practical path, because it means the SIS integration is solved once rather than once per vendor.
The failure mode nobody warns you about
The dangerous OneRoster failure is not an outage. It is a truncated export that succeeds.
A nightly CSV job fails halfway. The file that lands is valid CSV, parses cleanly, and contains 40% of your students. A naive sync compares it against yesterday and concludes that 60% of your district has withdrawn. Depending on what downstream systems do with a withdrawal, that can suppress messaging to thousands of families overnight, and the failure is silent because every individual step reported success.
Ask any vendor consuming your roster: "What happens if tonight's file contains half the records it did yesterday?" The right answer is that the sync refuses to run and raises an alert. Kastr aborts a sync that would withdraw more than half of active records and records the run as aborted_guardrail; overriding it is deliberate.
The related question worth asking is what a withdrawal actually does. Removing a student from a roster should stop messages to that family. If it only changes a status field that nothing reads at send time, the family keeps receiving attendance notices for a child who left in October.
Questions people actually ask
What is the difference between OneRoster and Ed-Fi?
Both are open K-12 data standards, with different centres of gravity. OneRoster is scoped tightly to rostering and gradebook exchange between a SIS and applications. Ed-Fi is a much broader data model aimed at district-wide analytics and state reporting. A communications platform needs OneRoster; a data warehouse project is more likely to need Ed-Fi.
Is OneRoster the same as Clever?
No. OneRoster is a standard; Clever is a company that implements rostering as a service. Clever and ClassLink both sit between your SIS and your applications and can emit OneRoster-shaped data downstream. You can use OneRoster without either of them if your SIS exposes the API directly.
Does OneRoster include parent and guardian contact details?
The user model can carry parents and guardians and their relationships to students, but contact detail coverage varies considerably by SIS implementation. For a communications platform this is the field most worth verifying early, because guardian phone numbers and language preference are exactly what the system needs and exactly what is most often thin.
Which SIS platforms support OneRoster?
Most major US K-12 student information systems support OneRoster in some form, either natively or through a rostering intermediary such as Clever or ClassLink. Support quality varies more than support presence, so confirm which version and which delivery mode with your own SIS vendor rather than assuming from a compatibility list.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.