OneRoster API

Revised article! 

We've updated this article recently and hopefully improved the information available. What do you think? Is anything missing? Scroll to the bottom of the article and leave a comment if you have feedback or concerns. Thanks!

What is OneRoster?

OneRoster is a set of specifications established by the 1EdTech Learning Consortium. Campus created our OneRoster API based on these specifications.

The OneRoster API allows third-party systems (such as an LMS) to retrieve data from Campus, if the system has been given the correct credentials. The data that can be gathered through this API includes roster and section data, as well as assignments, grades, and scores, if enabled. This API allows districts to more simply integrate their third-party program with Campus.

Campus does not own the OneRoster specifications; we created the OneRoster API based on those specifications to allow third-party systems to communicate with Campus. Fields in Campus are mapped to fields in OneRoster.

Getting Started

It is important to understand that the OneRoster API allows third-party systems to request information from Campus and send it back; Campus does not make requests, it only receives them. Thus, there is no interface in Campus through which users interact with OneRoster. The external system is responsible for making all requests for data, either to receive section data or to send grade/score information. If the OneRoster API were a telephone, Campus would only be able to receive calls, not make them.

In order for the third-party system to make these requests, they must be given credentials to Campus through the Digital Learning Applications Configuration tool. After these credentials are created, the district is responsible for communicating important fields with the third-party system. The Implementing OneRoster section below explains this process and the fields used by the third-party system to connect to Campus.

Type of OneRoster Connections

See Types of Digital Learning Application Connections for more information about the types of OneRoster connections are available. Connections are managed in the Digital Learning Applications Configuration tool.

Versions of OneRoster

1EdTech currently supports the 1.1 and 1.2 versions of the OneRoster specification. Vendors may only support one version of the specification. It's important to verify what version(s) a vendor supports before creating a connection. See the next section for more information. 

Another distinction in OneRoster connections is which version of OAuth they use, which are backend authentication protocols related to data security. OAuth 1 is an older version of the protocol that has been officially deprecated. Vendors who do not support OAuth 2 are not using the most secure methods of syncing data and are out of compliance with the OneRoster specification. As of December 2023, any new connections created use OAuth 2. OAuth 2 is the only version currently supported by Campus. 

Implementing a OneRoster Connection

At the beginning of the school year, districts should not sync with vendors until student scheduling is finalized. Syncing prior to finalizing scheduling may cause incorrect data in the vendor system.

Step 1: Verify Vendor

Verify whether the vendor conforms to the OneRoster specification (version 1.1 or 1.2). 

If the Vendor is a Digital Learning Partner

If the vendor is already a member of the Digital Learning Partner Program, then they meet the necessary requirements and any connections with that vendor are supported by Infinite Campus. 

If the Vendor is not a Digital Learning Partner

If the vendor is interested in becoming a Digital Learning Partner, have them fill out this interest form. 

Districts can connect to vendors who are not Digital Learning Partners, BUT

  • Only Roster Sync connections are available for non-partners. Non-partner vendors can request roster data via the OneRoster API, but they cannot send any data to Infinite Campus, including grade data. 
  • Infinite Campus does not support connections non-partner vendors; Campus Support will not be able to help troubleshoot.

Step 2: Gather Information

Prior to configuring a OneRoster connection, gather answers to these questions and make decisions based on how your school/district stores data. 

  • Will the connection use the 1.1 or 1.2 version of the specification?
    • Communicate with the vendor about which version of the specification they use. 
  • Which types of connections will this OneRoster connection use? See the Types of Digital Learning Connections article for more information. 
  • How does my district store data? 
    • There is some customization options available for OneRoster connections, based on how districts manage student data. Review the global settings that apply across connections and connection-specific configuration options that apply to individual connections. 
  • Is there data that should NOT be included in the API?
    • The External LMS Exclude checkbox, with appears on various school and student records, prevents data from being made available in the OneRoster API. Review the External LMS Exclude article and mark records that should not be included. 
  • When should the cache refresh? 
    • Communicate with the vendor about when the daily OneRoster cache refresh should be set to run. Review the OneRoster Cache article for more information about the cache and how to change the refresh time. 

Step 3: Verify Data Setup

Review the OneRoster Prerequisites article to verify that data made available via the API is set up correctly. 

Step 4: Configure the Connection

Use the Digital Learning Applications Configuration tool to configure connections to OneRoster. See the Configuring OneRoster Connections article for more information about configuring a connection to a Digital Learning Partner or a non-partner vendor

Step 5: Share Necessary Information

As part of the configuration process, you'll gather data that must be shared with the vendor for them to establish a connection. Data is found in the Information to Share section when you configure the connection. 

Information includes: 

  • The Client ID and Client Secret: the username and password the vendor uses to access Campus. (Sometimes called a API Key and Secret)
  • The Token URL
  • The Base URL: the URL the third-party system uses to access Campus. (Sometimes called a Source URL)

Campus also recommends sharing: 

Once these credentials are shared with the vendor, the vendor can begin requesting data via the OneRoster API. 

At this point, the remaining setup is performed by the vendor. Districts are responsible for ensuring that vendors conform to any recommended guidelines.

Additional Information

The Digital Learning Applications article collects links to all information relevant to this tool. These articles might prove helpful for understanding OneRoster: