If you are involved in the technical side of event fundraising, you’ve probably come across the term ‘API’. It’s often used in the same sentence with “open”, “standards-based”, “custom”, or “integration”. It is touted as a way to attain new levels of efficiency and interoperability by letting different systems communicate with each other. While no one comes right out and says it, it is portrayed as an “Easy Button”.

That’s great, right? We all want to make a better experience for our constituents and if we can do that while reducing our own workload, it is a total win. We’ll have all of our systems talking to each other and by virtue of that communication, registrations and fundraising levels will rise, overtime hours will fall and all of the donations will reconcile perfectly with the bank. The weather will be perfect on event day. Unicorns and bunnies will frolic together in a sunny meadow…. It is a worthy goal and a beautiful dream. However, as any IT person will tell you (sometimes without you even asking), unless you are shopping for office supplies, there is no easy button.

So what IS the deal with APIs, then? In short, they are way to make a system perform its usual tasks, but without going through an administrative interface to do it. API is the common abbreviation for Application Programming Interface.  Use of APIs allows very granular control over how things are processed. An example might be helpful in explaining.

We utilize the TeamRaiser module in Blackbaud’s Luminate Online platform for many of our NPO clients who do events. Out of the box it performs the expected functions: participant registration, donations processing, and email communications. There are, of course, many sub-functions that go into that, such as “search for a participant”, “start a team”, “check the database to see if the participant already exists”, “update the constituent address information”, etc.  APIs allow us to access those sub-functions directly, such that we can create a unique experience that is tailored to the needs of a specific event or client. There are three important conditions to keep in mind, though:

  1. The function or sub-function must already exist in the system somewhere.
  2. The owners of the system (in our example, Blackbaud) must do some programming on their end to make those functions available for use with API. Not all functions are, or should be.
  3. You will need someone on staff (or outsourced/consultant) to write the code needed to stitch the various available APIs together with whatever other processing is desired to create a flow that meets your individual needs. That is why the word programming is in there.

It’s number 3 that the API marketers never mention.

Now before you go thinking that I am anti-API (or anti-marketing), let me say up front that I *love* APIs. At Event 360, we’ve used them for a number of things that we wouldn’t be able to do otherwise.  We’ll talk about those in the next installment. For this post, I wanted to lay out some of the hype and realities involved in considering whether programming system customizations and interconnectivity via API is right for your organization or project before we got too far down the road. In the next installment, we’ll lighten up a bit and I’ll share with you some of the great things you can do with APIs, in systems you may already use, as well as my thoughts on the future of systems development in light of APIs becoming more public and common.

Share Button