What Is OneRoster? (IMS Global Standard for SIS/LMS Integration)

What Is OneRoster?

OneRoster is an open data standard developed by 1EdTech (formerly IMS Global Learning Consortium) that defines how class roster information moves between a student information system (SIS), a learning management system (LMS), and other educational technology platforms. It provides a common format for representing organizations, users, courses, classes, enrollments, and demographic data so that different systems can share this information without custom integrations.

Before OneRoster, transferring student and class data between platforms required bespoke file exports, manual data entry, or proprietary connectors built for each vendor pairing. A school district using one SIS and three different learning applications might need three separate integration projects, each with its own data format and maintenance burden. OneRoster replaces that fragmentation with a single specification that any compliant system can read and write.

The standard supports two data exchange methods: flat CSV files and a RESTful API. CSV-based exchange suits batch processes where data is exported from one system and imported into another on a schedule. The REST API enables real-time or near-real-time synchronization, allowing roster changes to propagate across platforms as they happen. Both methods use the same underlying data model, so the structure of the information is consistent regardless of the transport mechanism.

How OneRoster Works

The Data Model

At the core of OneRoster is a defined set of data entities and the relationships between them. The six primary entities are organizations, users, courses, classes, enrollments, and demographics. Organizations represent schools and districts. Users represent students, teachers, and administrators. Courses define the curriculum catalog. Classes are specific sections of courses offered in a given term. Enrollments link users to classes with a defined role. Demographics hold optional attributes such as birth date, gender, and ethnicity.

Each entity has a standardized set of fields, required and optional, with defined data types and value constraints. A user record, for example, includes a unique sourcedId, a status field (active or tobedeleted), a role (student, teacher, administrator), and name fields. This rigid schema is what makes interoperability possible. When every system agrees on what a "class" record looks like, data flows without translation layers.

CSV File Exchange

The CSV implementation of OneRoster defines a set of files, one per entity type, with prescribed column headers and formatting rules. A complete CSV export might include manifest.csv, orgs.csv, users.csv, courses.csv, classes.csv, enrollments.csv, and demographics.csv. The manifest file describes which files are present and which version of the specification the export conforms to.

Districts that cannot support API integrations often rely on CSV exports run nightly or weekly from their SIS. The receiving application ingests the files, maps the data to its internal model, and updates its roster accordingly. While less immediate than an API, CSV exchange is straightforward to implement and does not require the SIS to maintain a running web service.

REST API

The OneRoster REST API provides endpoints for querying and modifying roster data programmatically. An LMS can call the API to retrieve the current list of classes for a school, the enrolled students for a given class, or the details of a specific user. The API uses OAuth 1.0a or OAuth 2.0 for authentication, standard HTTP methods (GET, PUT, DELETE) for operations, and JSON for data payloads.

Real-time API integration means that when a registrar adds a student to a class in the SIS, the change can appear in the LMS within minutes rather than waiting for the next batch export. This reduces the window during which roster data is stale and minimizes the support requests that arise from mismatched enrollments.

Key Benefits of OneRoster

Standardization across vendors. OneRoster eliminates the need for custom integration code between each pair of systems. A district that adopts a new LMS or adds a supplemental learning tool does not need to build a new data pipeline from scratch. If both the SIS and the new tool support OneRoster, the roster data flows through the same channel already in use.

Reduced manual work. Without a rostering standard, IT staff and school administrators spend significant time exporting, reformatting, and uploading class lists. OneRoster automates this process. Errors from manual transcription, such as misspelled names, incorrect class assignments, or missing enrollments, drop sharply when data transfers are machine-to-machine.

Faster onboarding of new tools. Schools and districts evaluate new EdTech products frequently. OneRoster certification signals that a product can receive roster data without a lengthy integration project. This lowers the barrier to piloting and adopting tools, which benefits the overall digital transformation of learning in a district.

Data consistency. Because every system reads from the same source of truth, student and class data stays aligned across platforms. A teacher sees the same roster in the LMS, the assessment tool, and the reading app. A student removed from a class in the SIS is removed from all connected applications, reducing ghost accounts and unauthorized access.

Compliance and privacy alignment. OneRoster's defined data model makes it easier to audit what personal data is being shared and with whom. Districts can review the fields in a OneRoster export and confirm that only necessary data elements are transmitted to each vendor, supporting compliance with student privacy laws like FERPA and COPPA.

OneRoster Use Cases

School Districts

For K-12 districts, OneRoster is primarily a tool for provisioning and maintaining rosters across dozens or even hundreds of applications. A mid-sized district might use PowerSchool or Infinite Campus as its SIS and need to push roster data to Canvas, Google Classroom, or other LMS platforms, plus supplemental tools for math practice, reading intervention, and assessment. OneRoster provides a single export format that all of these tools can consume. Platforms like Teachfloor that support standard data exchange protocols benefit from this same integration approach, enabling cohort-based learning at scale without manual enrollment.

LMS Vendors

LMS providers implement OneRoster to make their products easier for districts to adopt. Supporting OneRoster means the LMS can receive class rosters, teacher assignments, and student enrollments automatically. This is a competitive requirement. Districts evaluating LMS options will favor products that integrate with their existing SIS through a recognized standard rather than requiring custom development.

SIS Vendors

Student information systems are typically the source of truth for roster data. SIS vendors implement OneRoster export (CSV) and API (as the provider/server) so that downstream applications can pull data directly. Major SIS platforms like PowerSchool, Infinite Campus, and Skyward all support OneRoster, making their data accessible to the broad ecosystem of certified tools.

EdTech Application Providers

Smaller EdTech companies building supplemental learning apps, assessment tools, or classroom management software implement OneRoster as consumers. Rather than building custom integrations with every SIS on the market, they implement OneRoster once and gain compatibility with any SIS or rostering middleware that supports the standard. This is particularly valuable for startups that lack the engineering resources to maintain dozens of proprietary connectors.

State and Regional Agencies

State education agencies sometimes mandate or strongly encourage OneRoster adoption to streamline data collection across districts. When every district in a state uses the same rostering format, aggregating enrollment and demographic data for reporting becomes far more efficient.

Limitations and Considerations

OneRoster is not a full identity management solution. It handles roster data, not authentication. Schools still need a separate identity provider (IdP) and may need to implement LTI (Learning Tools Interoperability) for single sign-on between the LMS and third-party tools. OneRoster provisions the accounts; another standard handles the login.

Vendor certification varies in depth. 1EdTech offers a certification program, but the level of conformance differs across products. Some tools support only CSV import, not the full REST API. Others implement only a subset of the data model. Districts should verify the specific OneRoster capabilities of each product rather than assuming that a "OneRoster certified" badge guarantees full compatibility.

Data quality depends on the source. OneRoster standardizes the format but cannot fix dirty data. If the SIS contains duplicate student records, incorrect enrollments, or outdated class information, those problems propagate to every downstream system. The standard makes transfer reliable, not the data itself accurate. A robust data governance practice at the SIS level is essential.

Handling mid-year changes can be complex. Students transfer between schools, teachers change assignments, and classes merge or split throughout the academic term. OneRoster supports status flags (active, tobedeleted) and date ranges, but the logic for processing these changes correctly varies across consuming applications. Testing mid-year scenarios thoroughly before going live prevents surprises.

Privacy and data minimization require deliberate configuration. OneRoster can transmit demographic data including birthdate, race, ethnicity, and gender. Not every receiving application needs all of these fields. Districts must configure their exports to share only the data elements each vendor requires, rather than sending the full dataset by default. This aligns with the principle of data minimization under student privacy regulations.

OneRoster vs Manual Rostering vs Clever vs ClassLink

Understanding where OneRoster fits relative to other rostering approaches helps clarify its role.

Manual rostering involves administrators exporting data from the SIS in a proprietary format, reformatting it in a spreadsheet, and uploading it to each application individually. This works for small deployments but does not scale. It is slow, error-prone, and creates a maintenance burden every time rosters change. There is no standardization, no automation, and no audit trail.

OneRoster replaces the proprietary format with a standard one and enables direct system-to-system transfer via CSV or API. It removes the reformatting step and supports automation. However, the district is still responsible for managing the connections between its SIS and each application. There is no intermediary.

Clever is a commercial rostering middleware platform. It connects to a district's SIS, normalizes the roster data, and distributes it to connected applications through its own API and dashboard. Clever handles the integration complexity on behalf of the district, providing a managed service with a centralized portal for managing which apps receive which data. Clever supports OneRoster as one of its data ingestion methods but adds its own layer of abstraction, identity management, and application catalog.

ClassLink offers a similar middleware approach with its Roster Server product. It pulls data from the SIS using OneRoster or other formats, provides data transformation and cleansing tools, and distributes rosters to connected applications. ClassLink also bundles single sign-on and analytics capabilities, positioning itself as a broader digital learning environment platform.

The choice depends on district size, technical capacity, and budget. Small districts with limited IT staff may prefer Clever or ClassLink for the managed experience. Larger districts with dedicated integration teams may implement OneRoster directly to maintain control and avoid per-student licensing fees. Many districts use a hybrid approach, relying on middleware for most applications while maintaining direct OneRoster connections for a few high-volume integrations.

Frequently Asked Questions

What is the difference between OneRoster and LTI?

OneRoster and LTI solve different problems. OneRoster handles roster data: who is in which class, who teaches it, and which school it belongs to. LTI handles tool launch and context passing: it allows a user to click a link in the LMS and land in an external tool already authenticated and placed in the correct course context. In a typical integration, OneRoster provisions the accounts and enrollments, and LTI handles the seamless transition between platforms. Both are 1EdTech standards and are designed to work together.

Is OneRoster free to use?

The OneRoster specification itself is open and free to implement. 1EdTech publishes the documentation, data models, and API specifications at no cost. However, 1EdTech membership is required to access the certification program, and certification testing involves fees. Vendors can implement OneRoster without certification, but certified products carry a trust signal that districts rely on during procurement.

Does OneRoster handle grades or content?

OneRoster v1.1 introduced a Gradebook service that supports exchanging line items (assignments) and results (grades) between an LMS and a SIS. This extends the standard beyond pure rostering into grade passback. OneRoster does not handle content packaging or delivery. Content standards like SCORM and AICC address that domain.

How long does it take to implement OneRoster?

Implementation timelines vary based on the systems involved and the integration method chosen. CSV import support can be added to an application in days to weeks. Full REST API implementation with OAuth authentication, pagination, filtering, and error handling typically takes several weeks to a few months. For districts, enabling OneRoster export from a SIS that already supports it is often a configuration task rather than a development project.

Can OneRoster work with non-K-12 systems?

The standard was designed with K-12 education in mind, and its data model reflects that context, with entities like schools, districts, and class sections. However, the underlying concepts of users, organizational units, courses, and enrollments apply broadly. Some higher education and corporate training platforms adapt the OneRoster model to their needs, though it is less commonly adopted outside K-12 than standards like LTI.