OneRoster is the 1EdTech standard for exchanging class rosters, enrollments, users, academic sessions and grades between a student information system and the applications around it. It has both a CSV binding for bulk exchange and a REST binding, and it is the backbone of K-12 data integration in the United States.
OneRoster
OneRoster models the things a school actually runs on: who is enrolled in which class, taught by whom, in which term, with what results. It exists because the alternative — a nightly CSV drop per vendor, formatted differently for each — is how the sector worked and in many districts still does.
- Rosters, enrollments and users - The core objects, with defined relationships and identifiers.
- A REST binding - A specified API, not just a file format — which is what makes its absence from published contracts notable.
- Gradebook exchange - Line items, results and categories, so assessment data moves without a spreadsheet.
- CSV for bulk - A deliberate concession to how districts actually operate.
- Certified conformance - Vendors certify against it; the certification is a badge rather than a fetchable artifact.
The gap OneRoster illustrates is the education market’s defining one. The specification defines students, enrollments, classes and grades precisely, with a REST binding ready to publish — and in The State of Education & EdTech APIs the K-12 student-systems segment scores 17.3 and publishes a machine-readable contract 15.9% of the time. The standard is not the missing piece. Publishing against it is.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The State of Education & EdTech APIs
Defines students, enrollments, classes and grades with a REST binding ready to publish — in a K-12 segment scoring 17.3 and publishing a contract 15.9% of the time.
