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.
Industry: Education
Also in the data model catalog
This standard shows up on both sides of the house — as a standard applied in API operations here, and as a data model defining what information exists. Same standard, two lenses.
See it as a data model →