Non-Profit Tech Blog

Convio has announced its new open API. They have the documentation up too just like Kintera. It’s very good news so I’m not going to bother too much with what was said yesterday but with the actual experience of trying to participate in the open API programs of Kintera or Convio. I’m going to say it right now — too many bloggers who talk about open APIs are unwilling or unable to research the documentation and I’m one of them. Today, I’m going to address that. I think I’m a little more gun-shy these days about proclaiming openness and here’s why.

I write code. It’s a seemingly minor difference but it’s a difference with a very large distinction. And if you happen to be one of those people who like to write code, you’re going to want to sign up for Kintera or Convio’s open API program.

Guess what? You can’t get in. I tried. Really, I did. I tried to go to open.convio.com and I couldn’t get past the registration wall. Kintera has a registration wall too. There are problems with both Kintera’s and Convio’s developer support philosophies that belie their attempts at openness. You have to buy their software in order to understand the way their systems work. In other words, without a working sample of Kintera and Convio that you can play with in a sandbox, it’s incredibly difficult for a coder to understand the context of the API calls that she is supposed to make. The worst part is that neither Kintera nor Convio will even allow you into their community forums. Now how is your average coder going to learn from or add to the discussion?

Again, this is a lesson in Web 2.0 transparency both for the sector and the vendors who serve it. Control? Let it go. I really mean that. From both a business point of view and from the point of view of how our sector should work to heighten transparency in society at large, there’s no reason to limit the ability of coders to learn about and discuss the API at hand. And the big guys have already done this work, check out the way Google and Amazon distribute their APIs. Those shine as industry-standard examples of how open APIs need to be distributed.

We now have the API documentation but quite a bit of the support infrastructure is still missing. Asking developers to have access to a nonprofit’s copy of Convio5 or Kintera Sphere is clearly a wrongheaded approach. Developers and nonprofits won’t necessarily have such a tight relationship and frankly, with a total installed base of less than a few thousand nonprofits (if that) for both Kintera and Convio, you’d think both companies would want to expand their developer base quickly. The clearest solution would be to create sandboxes of both Convio5 and Kintera Sphere. Reset the data every few hours and let the coders have at it.

At this point, with so little information that I could glean from what’s been given out, I have to give Convio compliments on the choice of REST as their API implementation. It’s easy to use, easy to understand and very easy to build libraries for. On the other hand, Kintera seems to have picked the older horse to run in the API races. I don’t quite understand the usage of SOAP when it’s more difficult to program for and harder to debug.

When I first thought of open APIs for CRMs, I had thought that one of the most basic applications would be the classic progress bar widget for a particular donation appeal to be placed on a nonprofit’s web site. This progress bar widget would be just like the one used on the ChipIn widget.

Convio’s API is weaker than Kintera’s in the sense that it does not allow for pass-through queries to be sent to the Convio data store. Kintera’s API has a method called “query” which looks like it will let you pass SQL or SQL-like queries into the data store. This may allow for aggregate queries of the entire data store. You can basically build custom reporting tools with this method. Also, it doesn’t look Convio’s API has a method for doing more than just retrieving one user’s data at a time. Frankly, this is going to drive developers nuts. At this point, you cannot create simple fundraising mashups with the Convio API as you cannot retrieve that data. It’s simply not allowed as there is no basis for extracting donation data on more than a per single-user basis using Convio’s API. Indeed, Convio’s API looks like you can ONLY retrieve user-related data one user at a time. It’s not even clear if you can extract donation data but there seems to be a provision for a MONEY type in the response to the listuserfields method. There’s also a getuser method that might return specific pledge information but it’s locked away in a Wiki that seems to be inaccessible right now (10/17/2007 12:13 AM).

In other words, you can build a progress bar widget with Kintera’s “query” method but it would be very difficult to do the same thing with Convio’s API. In order to sum up a campaign’s pledge total, you’d have to have as many getuser calls as you have users. This is simply impractical for larger databases that may have thousands of users.

On the basis of utility, Kintera’s API is just simply more powerful than Convio. It’s also a remarkable amount of trust that the company has placed in its users and in its own viability as a company. Clearly, Kintera’s API is so wide open that extracting your entire database as a prelude to the porting of that data to another Kintera competitor is within your grasp. Sorry Kintera users, I let the cat out of the bag! In terms of TRUE openness, Kintera is beating Convio hands-down.

Ok, so we’ve got problems of API openness here. Are they insurmountable? Absolutely not. I expect that both Kintera and Convio will still have to match evolving expectations of what coders mean by open. With the exception of a poor choice on the SOAP interface, Kintera is on the right track. Convio needs to implement a “query” and a “retrievemultiple” method just like Kintera in order to really match a reasonable definition of openness.