Agreed - an odata API for the SKY API would be extraordinarily helpful in order to use the API more efficiently. We use the https://api.sky.blackbaud.com/gift/v1/gifts endpoint to get gift data, and we use the gift_type=Donation, campaign_id=[...], and the date_added attributes to limit the scope of the results to Donations. But we need more options to limit the scope even further, and we think that oData will provide that.

Customers want us to process gifts with very specific attributes, and for each gift, we have to re-query the API up to 5 times to get the necessary data to determine if the gift is in scope for the customer. Specifically, we have to re-query the sky API to get gift custom fields, solicit codes, the constitutent entity, constituent-consent, consitutent-codes in order to figure out if the donation is in scope and should be processed by our app. So if we send one network request to get 25 gifts using the v1/gifts api, we actually have to send up to 125 https network requests just to get the data we need to process the gifts, depending on the filters that our customers set up in our product. Having to send 126 https requests to the SKY API increases network congestion and requires more processing power - the end result is a slower integration. We fetch all of that data just to find out that a small subset of the initial 25 gifts are in scope and should be processed by our app! It also has real constraints on API rate limits.

Earlier in the thread, you mentioned that it'll be good to look at other industry APIs for inspiration. We actually have a good example from Salesforce here. They have an endpoint that lets you send soql to their service so that you can fetch exactly what you want from their API. So it's not an oData implementation, but it's an expressive implementation that lets developers fetch exactly what is needed. It's super efficient, so customers are happy because the feedback loop is a fraction of the time.

Let me know if you ever want to chat and/or need more information. I love the SKY API and am very appreciative of it - but the ability to send more expressive queries to the API will likely decrease the amount of processing power and network congestion on your machines and ours, resulting in integrations with faster feedback loops to customers. Everyone wins.

Hi, you can now connect the SKY API to Power BI (without needing OData) using a custom connector I've developed. There's still a few bits to do, but you can try it out here: https://github.com/GrantQuick/BlackbaudSkyApi

Hi Dan,

Thanks for your speedy response.  I am glad to hear your plans for some form of connections to 3rd Party BI tools. 

In terms of the exact need as long as there is a complete access to all data, through a standards best web API I don't mind whether it is REST API with JSON or OData. 

Cheers,

David.

David, thanks for the OData suggestion! And, for the context as to your intended use case(s). I'd like to dig in a little deeper. 

We've been looking into the possibility of providing an OData interface with the SKY API, and definitely to support the BI use case of connecting Blackbaud data to 3rd party BI tools like Tableau and Power BI. I wonder if those are necessarily a package deal for you.

For example, if we continue down our current path of provide a REST API (not necessarily using OData spec) with JSON data format output, which of the available Tableau (screenshot below) or Power BI data sources might you consider using...and what benefits does OData provide that these don't?

Also, do you use any OData APIs today that you really like? We love to look at other industry APIs for inspiration and comparison. 

Curious to hear others' thoughts on this topic, too. If anyone wants to chat and/or share with us what you're doing today in tools like Tableau that you'd want enabled by SKY API, feel free to sign up at https://www.timetrade.com/book/YZDXC.