Watch out - Your Roster APIs are now excluding data

Question

Just in case you missed this update and you're using any of the Roster APIs to populate your data warehouse or use that information for reporting purposes, you most likely just lost data!

https://developer.blackbaud.com/skyapi/support/changelog/bbem

The big issue here is the approach to exclude data by default without thinking about how this impacts end users.

We've also added an exclude_inactive parameter. Set it to true to exclude inactive courses. It defaults to false, so responses are unchanged when the parameter is omitted.

We generate transcripts outside of Blackbaud and with this recent change, we lost all the academic roster information associated to students where the course is now set to inactive.

Though I welcome the extra filter options, I think the better approach would always be to include more data by default when adding in new filters so that current processes are not impacted.

@Stephen Boyle wanted to share with you and your team!

Michael Panagos · Answer

@Stephen Boyle Related request (if not already in the works): Add an include_inactive parameter to GET /v1/schedules/meetings Endpoint: GET /v1/schedules/meetings Documentation: https://developer.sky.blackbaud.com/api#api=school&operation=V1SchedulesMeetingsGet Since the 2026-08-31 release added an include_inactive parameter to the roster endpoints (academics, activities, advisories, athletics and community groups) and changed them to return only active sections by default, this affects some of our integrations for getting meetings along with the meeting details and rosters for those meetings. The main issue is that the meetings endpoint did not get the same treatment. It still returns meetings for sections whose offering status is Inactive, and it offers no way to filter them out. The response gives no way to filter them client side either. The Meeting model carries no offering or section status field, so a caller cannot tell from the response whether a meeting belongs to an inactive section. The only workaround is a second request to a roster endpoint for the same sections, reading section.offering.status and filtering locally. The concern is not payload size, which is trivial. It is the number of round trips, and the fact that they cannot be avoided or cached away: nothing in the meetings response indicates status, so the lookup has to be repeated on every schedule query. That lookup costs one extra request per offering type, per school year, per batch of section IDs. A single-day query for one offering type goes from one request to two. Pulling a full school year across all four offering types is roughly 12 meetings requests plus 4 status requests, and a date range spanning two school years adds 8. The request, in order of preference: * Add an include_inactive query parameter to GET /v1/schedules/meetings, using the same name as the roster endpoints. * Failing that, add the offering status field to the Meeting model, so callers can filter client side without a second request. Either option removes the extra round trip. The first also makes the meetings endpoint consistent with the roster endpoints.

Lindsey Bryant · Answer

Hi Michael,

That's what I discovered too. I had to adjust 9 integrations yesterday as we lost data for multiple students due to things being set to inactive. I confirmed my courses continued to be inclusive of both active and inactive data, so I didn't have to adjust that one.

Michael Panagos · Answer

I haven't tested this yet, but from the help page it looks like GET rosters now exclude inactive by default (changed; flip using include_inactive) while GET courses include inactive by default (not changed; flip using exclude_inactive).