The spirit of our last API discussion was, essentially, “don’t believe the hype”. (Did I just drop in some Chuck D?  Yes, yes I did.)  In this installment we’ll talk about some of the groovy things you can do with APIs, as well as some thoughts on the future.

One of our clients has a complex event check-in procedure that goes well beyond just “have you reached your fundraising minimum to participate?” It includes variables for past participation, whether you are or are not on a team, whether you have reviewed the safety literature and waivers, and have you purchased any additional items for use on the event. With APIs, we are able to query all of those things and adjust the check-in flow for the participant accordingly, in real time.

We have also used APIs to allow team captains to assign certain equipment needed on event to specific team members. Keep in mind that none of the team captains are system administrators – this all happens on the front end. The Luminate Online database is queried for available equipment, and the captain’s assignments are stored back in the Luminate Online database, where it is then available for reporting or use in other ways. Before APIs, that equipment assignment was handled by staff, one by one, via the administrative interface. Assigning by hand is fine if you are doing 30. It is a significant workload if you are doing 3,000.

With another client we’ve completely customized the registration process using APIs, funneling the registration fees and donation amounts into different merchant accounts while presenting the participant with just a single registration form. All of the special processing goes on behind the scenes.

None of the examples I’ve given were able to be accomplished using the standard tools offered in the Luminate Online package. But because Blackbaud had made the functions and sub-functions available via API, we were able to use programming to combine the various sub-functions in such a way that we could accomplish things that would not otherwise be possible.

As fundraising, registration, and email systems evolve, you are going to see more and more functionality made available for API. From a system developer’s point of view, the standard package allows you the basic functionality and interfaces that will meet the needs and uses of 80% of their potential customers. These are the folks who use the ‘vanilla’ product, and for whom it meets their needs. By making that functionality available over API, you make your system available to the other 20% who need something more / different, AND you don’t have to put in costly customizations to your system (which are a problematic to maintain over the long term), AND the burden of development / resources / maintenance of a customer’s specific customization is borne by the customer. All you have to do is provide an avenue for the client to access your system over API and let them go to town. It lets you focus on improvements to your core product rather than be distracted in custom one-offs.

I think that strategy of designing for the majority and allowing access for minority advanced users is going to, over time, result in systems that excel in their core functionality. Moving from “one-size-fits-all / jack of all trades” model to more of an “a la carte” selection of the best-of-breed in each functional area presents an opportunity to create a highly tailored system for a customer. In theory, it all works great. The trick is going to be for those various system vendors to make the right functions available over API, combined with the clarity of your vision of what you want the system to be/do, and having someone pull the various functions together to make it happen.

What I hope I’ve left you with is a glimpse of how APIs can be beneficial, as well as an understanding that it isn’t just “set it and forget it”. There is, and will continue to be, a lot of hype around APIs. Before you buy into the idea that a particular product is the right one for you because their advertising says it has APIs, get some details on exactly what functions/sub-functions are available and take some time to flowchart how the available functions fit into the need you are trying to address. Think also about design time/costs and whether you have that skill in-house or would need to contract out for it. Also consider maintenance and if changes will be required for that same system to work properly next season.

APIs are great, and you can do wonderful things with them, but just having them available doesn’t get you much.  There is a lot of work involved, from planning to integration and implementation. There is no easy button.

Share Button