The Aeries SIS

The Aeries SIS is a software solution that coordinates administrative processes in learning institutions and serves as a central hub for managing student data and academic records. Its features lead to:

  • improved communication,
  • informed decision-making,
  • streamlined operations, and
  • enhanced engagement among students, parents, educators, and staff.

Ultimately, Aeries empowers educational institutions to focus on their core mission – delivering quality education – while minimizing administrative duties.

For edtech developers, Aeries is important because of interoperability. Interoperability is the ability of software systems to share data between each other. In this context, interoperability refers to edtech products (elearning apps, tools, content, etc.) and their ability to connect with learning institution data systems (like an SIS). When interoperable, the two systems can:

  • provision accounts automatically and ahead of the school year (known as “rostering”)
  • share learning outcomes to a learning institution’s gradebook automatically
  • retrieve attendance data for analysis, and more!

Interoperability allows educators to have a more complete view of a learning journey. This perspective then supports better-tailored instruction to meet individual needs. The goal of interoperability with SIS providers is to use data to deliver a more effective, personalized, and seamless learning experience. When edtech products become interoperable with systems like Aeries, it can lead to higher marketability and “sticky-ness” (read: hard to let go of) for learning institutions of all types. This means happier customers (like school admins, educators, and students) and higher renewal rates.

Integrating with Aeries

In edtech, there are two types of integrations: API integrations and specification-based integrations – like OneRoster and LTI (more on LTI integrations here). To integrate to SIS providers specifically, edtech developers have a few integration methods to choose from, such as:

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

OneRoster's integration method lays out how to implement the specification – to “build the bridge” to an SIS. In contrast, API integrations are more direct connections. Edtech developers looking to make connections to Aeries can use either of the 3 methods mentioned above. However, integrating with OneRoster or directly to the API comes with a hefty load of challenges.  

Aeries OneRoster Integration Challenges

In our experience, the challenges of using OneRoster in Aeries are complex. 1Edtech designed OneRoster to share only class rosters, enrollments, and grades. Though SIS providers house a lot of learning institution data like facilities and period data, OneRoster cannot engage with those fields.

To have a OneRoster connection, developers may have to build several implementations of OneRoster, like in 1.1 where it can be implemented with OAuth 2.0, OAuth 1.0, or through CSV file transfer. This is only because to form the connection, the implementation must match the SIS provider’s chosen implementation method too.

For example, a middle school using Aeries might send out an RFP seeking edtech products that can connect to their SIS. If that school’s Aeries instance uses OneRoster with OAuth 1.0, then to build a OneRoster integration, the edtech product would also have to use OneRoster with OAuth 1.0. Using OAuth 2.0 or a CSV wouldn’t work. At this time it isn’t clear if Aeries has any deprecation plans to focus on one version over another.

OneRoster integrations aren't customizable. A specification is clearly laid out and to be implemented correctly, it has to remain as planned. Say if a developer wanted to add extra security measures around the OneRoster integration, it wouldn’t be a true OneRoster implementation. Developers have to follow the specification to implement it correctly.

Probably the largest (and most controversial) limitation of specifications like OneRoster is that they are never future-focused (from our perspective). OneRoster is reactionary – it was only created after a problem became large enough to solve. OneRoster isn’t innovative – its focus isn’t to “find the best SIS integration method”. And when a new specification version is released, the previous version is quickly deprecated regardless of other edtech companies and SIS providers.

Aeries API Integration Challenges

Building a direct API integration comes with challenges too. After looking through the Aeries API documentation (and leaning on some personal experiences from our team), here are 10 of the numerous challenges a developer may encounter and solve when integrating with Aeries:

  1. Prepare to code for both anonymous and Windows-authenticated requests, supporting both HTTPS and HTTP depending on the operation.
  2. Managing updates and integration changes with an in-house Aeries integration at any point in the year. The last time that Aeries updated its fields or relations was August 2024, which could have pushed breaking changes to an integration.
  3. Developers need to remember to use the Request Header to specify the response format expected (JSON or XML).
  4. When accessing dates, if the “DatabaseYear” parameter is omitted, invalid, or doesn’t match a school year in the configuration, then you will receive default data instead – there isn’t an error built for this.
  5. Developers must have student demographic permissions. If the “Student Demographics” – field-level permission isn’t granted, the value will be ignored.
  6. Not all test scores are held under the /api/v5/students/{StudentID}/tests endpoint. The Aeries documentation states that, “This end point will return a full history of all State and locally administered Standardized Tests in Aeries. Examples include SBAC (CAASPP) and ELPAC. College Entrance Test Scores such as SAT I, SAT II, ACT, IB, and AP are available in a separate area detailed elsewhere”
  7. Districts can customize their tables in the /api/v5/schools/{SchoolCode}/DistrictSupplemental/{StudentID} endpoint, which can cause confusion when trying to pull information.
  8. Attendance data seems to require knowledge of a student if they attended that day. Here’s how the documentation explains it, “An ‘AttendanceDay’ is only returned if the student has an attendance code for that day or for at least one period in that day. For negative attendance schools, it is normal for many days to be ‘missing’ from student attendance results because no attendance code is entered when the student is present for the day or period.
  9. Aeries’ use of HTTP makes it less secure than HTTPS, creating a vulnerability risk overall.
  10. The SIS uses flex period data (like school year 2011-2012) but also only uses static years in enrollment requests (like school year 2011 or 2012), making it confusing when to use which year type.

In short…

Building an Aeries integration presents inherent challenges for edtech developers to solve. In OneRoster, developers have to:

  • be at peace with the limited amount of accessible data,
  • determined to sift through complicated documentation, and
  • accept that the integration may not be as advanced or tailored as desired.

However, integrating with the Aeries API directly comes with its list of integration issues as well. For Aeries, developers will face challenges around understanding the expansive, detailed, and complex nuances of Aeries and its data. Either choice comes with problems, but it is still valuable to be interoperable with a SIS like Aeries. Learning institutions need more edtech products that can communicate with each other to enhance learning outcomes and the student experience overall.

Learn More about Integrations

If you’re interested to learn more about Integrations here’re other articles we’ve written:

If you're looking for a partner who can help guide you through developing LMS integrations (like these), then let’s introduce ourselves. We’re Edlink!