Clarification on Course Request Changes from August

Question

Good morning everyone!

Back in August, BBEM released a bunch of changes to APIs expanding out the filtering options as well as the output. The one I need clarification on is the Course Request:

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

Request type and recommendations for Academics course requests

GET Academics course requests now identifies the type of each request and returns the following additional fields on the CourseRequest model:

* type - Whether the record is a request or a recommendation. Either Request or Recommendation
* is_required - True if the request is required
* is_recommendation - True if the record is a recommendation or is a request that came from a recommendation
* recommended_by - The user who made the recommendation. Only populated when is_recommendation is true

These fields are returned for every request type, so some are empty depending on the type. requested_by is now populated only when type is Request.

We've also added an include_recommendations parameter. Set it to true to include recommendations in the response. It defaults to false, so recommendations are excluded unless you ask for them.

As I'm looking to leverage some of these new features I'm finding the following:

* is_recommendation is coming across as True or False. But those that are marked true don't have the "recommended_by" option. We do course requests in the Spring for the next year. So is this something that is only included for future requests?
* When I true to use the include_recommendations=true in the API as a filter, nothing is adjusted even though I confirmed we have records returned in the JSON body with a true or false value.

@Stephen Boyle let me know if I am missing something here.

Lindsey Bryant · Answer

I confirmed with our registrar that we don't use recommendations, most because we build our schedule outside of BBEM. This makes sense on why I wouldn't see any changes in our filters. I think that's also whey the recommendation_by portion is opted for me as well.

Thanks again for the clarification!

Stephen Boyle · Answer

Syntax looks correct.

If you are looking at the current year, it may be that you do not have any recommendations that were not turned into requests. If the recommendation was converted to a request, it would be in your output regardless of that filter.

Just to level-set, in the example above, the History of Rock and Roll Course would be affected by the filter. But, if I hit the Add as request button, then it will not be affected because it will technically be a Request at that point, though it will have recommendation info included.

All that said, if you do have pure non-request recommendations, then the filter should be affecting your total. And you have yourself another ticket for us to tackle.

Lindsey Bryant · Answer

Thanks, Stephen. I'll get a ticket submitted here today.

I might not be doing this right, but when I add the parameter to my URL, I get the same results as if it wasn't there or if I switch it from true to false:

v1/academics/courserequests?school_year=2026-2027&include_recommendations=true

Total lines in Postman

true = 334448

false = 334448

not included at all = 334448

The parameter doesn't seem to filter anything. Is this the right syntax?