Infinite Campus and Interoperability

As a Student Information System (SIS), Infinite Campus stores and manages student data for K-12 schools. It simplifies student data management, enhances communication, and supports school operations with features like:

  • Online gradebooks
  • Messaging tools
  • Detailed reports on attendance, grades, and schedules

Interoperability refers to the ability of software systems to exchange data seamlessly. In edtech, this means learning tools, apps, and content can integrate with learning institution data systems (like an SIS). When interoperable, systems can:

  • Provision student accounts before the school year begins (rostering)
  • Sync learning outcomes with a school’s gradebook
  • Retrieve attendance data for analysis

The goal of SIS interoperability is to enable a more effective, personalized, and seamless learning experience.

An Infinite Campus Integration

In edtech, there are only two types of integrations: API integrations and specification integrations – like OneRoster and LTI (more on LTI integrations here). To integrate with SIS providers like Infinite Campus, edtech developers can choose from several methods, including:

  • using an education specification, like OneRoster,
  • building a custom integration to the SIS provider’s API, or
  • connecting to an aggregator like Edlink

Infinite Campus and OneRoster

OneRoster is a specification that provides a standardized framework for integrating edtech products with an SIS. Unlike API integrations, which allow for customized connections, OneRoster follows a fixed structure, limiting flexibility.

Since Infinite Campus doesn’t allow access to its API without a certain partnership-level commitment in place, most developers will have to work within the constraints of OneRoster - the only integration option that doesn’t require a commitment. The platform supports three different OneRoster implementations, meaning institutions may use different versions that affect data access. The image below is from Infinite Campus’s integration documentation.

Developers integrating with Infinite Campus must understand OneRoster 1.1, 1.2, OAuth 1.0, OAuth 2.0, and JSON.

Because OneRoster implementations vary by institution, scaling integrations requires adapting to different versions and requirements.

OneRoster 1.1 supports three main data services:

  • Results (grades, assessments)
  • Resources (course materials, digital content)
  • Enrollments (rosters, student assignments)

OneRoster 1.1 can also support the modern and widely used OAuth 2.0 security protocol. The specification supports the transfer of data using CSV templates or through system data exchanges using REST API binding. OneRoster 1.2, the newest version, introduces several updates, including:

  • Uses OAuth 2.0 Bearer Token exclusively
  • Adds 3 new name properties from for users who wish to be called by a different name than their legal name; preferredFirstName, preferredMiddleName, and preferredLastName
  • Supports users who have multiple roles within one or several organizations
  • The 'roles' class has been added to enable the assignment of any combination of role/org/account mappings for a user including date stamping to enable partial academic sessions.
  • The roles attribute has been added to the 'user' class.
  • The role attribute has been removed from the 'user' class.
  • The orgs attribute has been removed from the 'user' class.
  • The primaryOrg attribute added to the 'user' class.
  • Updates the Gradebook Service to support Standards-Based Grading
  • Adds the weighting scheme the organization or teacher designed to copy to the new system – supporting score scaling with grades
  • Adds a new attribute to store non-numeric scores: textScore
  • Adds a new endpoint for those with unique gradebook categories for each class: getgetCategoriesForClass
  • Limits access to data within an endpoint through scoping down

The following updates impact how institutions implement rostering, meaning edtech developers must be flexible when working with Infinite Campus integrations.

  • Reorganizes Rostering into its own Service Model with newly annotated endpoint: /ims/oneroster/rostering/v1p2
  • Extends the vocabulary of the attribute sex with the tokens 'other' and 'unspecified'
  • Adds attribute userMasterId to the “User” class to enable a definitive globally unique identifier (not the interoperability sourcedId for the user)
  • Adds attribute roles to the “User” and “Roles” classes to enable the combination of role/org/account mappings for a user
  • Adds the resources attribute to “User” to identify resources available to the user
  • Removes the role and orgs attributes from “User” class
  • Adds primaryOrg to the “User” class
  • Adds  masterProfiles attribute to the “User”, “UserProfiles”, and “Credential” classes to enable assignment profiles to a user
  • Makes the following extensible for easier profiling and internationalization: ClassTypeEnum, GenderEnum, OrgTypeEnum, RoleEnum' and 'SessionTypeEnum'
  • Removes CEDS/SCEDS vocabulary in order to be replaced by more relevant (by geographic region) vocabulary
  • Requires Service Provider to make a localized OpenAPI file available for Service Discovery

To recap…

Edtech products can integrate with Infinite Campus but might feel limited by using the OneRoster specification rather than making a partnership commitment to get a direct API. Scaling integrations across institutions means understanding multiple OneRoster versions. Although Infinite Campus can store and add to several data records for learning institutions, integrations are limited to the data that OneRoster is able to access (results, resources, and enrollments).

Read More on SIS Integrations

Here are other resources on SIS integrations and Edlink to help you on your integration journey:

Want to Get Started?

If you're looking for a partner to guide you through developing integrations, then let us introduce ourselves. We're Edlink!