Recommended approach for 3rd Party integration with Aeries

[Ravi Jammi]

Hey everyone,

I am trying to understand what is the recommend approach for 3rd party vendors/products to integrate with Aeries platform?
I see "Aeries API" and "OneRoster API" in the documentation, what is the difference between them and what should 3rd party vendors trying to pull data from Aeries platform use?

Thanks,

Ravi

[Matt Colwell]

OneRoster API is basically like pulling OneRoster data via csv files - except it's up to the vendor to store/save the CSV and it can be triggered by the vendor instead of being scheduled by you.  The extractable data is limited by the OneRoster standard.

Aeries API is more robust and offers more accessible datapoints, but not as many vendors support it.  I don't know what the roadmap looks like for Aeries NextGen (it seems to have lost a lot of momentum) - but NextGen boosted read/write API access to all datapoints.

Which method you use is really dependent on what the platform will accept. I always choose the Aeries API when it's available. 

[Jesse Geron]

Matt nailed it - OneRoster API will give you OneRoster format data. Check the documentation here, as there are a few endpoints that aren't supported. Aeries API is more robust, but does not give you access to everything that you might want/need. For that, you need direct access to the SQL database.

I wanted to address Matt's mentioning of "Aeries NextGen".
1) I believe they are not calling it NextGen anymore.

2) I feel like they're having issues figuring out exactly how to move forward with the migration to a newer, modern Aeries. My guess is 2 main issues - loads of technical debt within the system and they had a conflict of vision for NextGen with the VP who left last year vs what they're attempting to do now.

3) Don't count on new API endpoints being available anytime soon. If you need access to certain data, you just have to work with what's available to you. If you have to read/write/delete from the SQL DB, then that's what you have to do.

A few things that have made me really lean into that #3 after looking forward to supposed 100% API coverage:
1) We were told everyone was going to have to move to Flex Scheduling. I believe the deadline was this upcoming summer of 2025, that's been walked back.
2) There was also a deadline for moving to being hosted, but there's none that I'm aware of now.

That makes me think moving to 100% native cloud architecture is quite a ways off from being a reality, and with it, 100% API endpoint coverage. I went from "gearing up for the future" making sure my in-house scripts leveraged the API as much as possible, to now - do what you have to do to get the job done. No one knows what the future holds.

[Ravi Jammi]

Apologies for the delay in my response. Thank you so much for the quick responses on this. We tried to play with the existing API's both OneRoster API's and the Aeries API's, Aeries API's seem to be more robust between the two. For our needs, we can intially rely on Aeries API's. Being a 3rd party vendor, I wonder if we would be given access to their DB.

Thanks,

Ravi