On Being Part of an API-Based Ecosystem

Much hand wringing and gnashing of teeth has occurred in the past around the Twitter ecosystem as slowly but surely Twitter identifies opportunities for development that sometimes encroach upon the functionality delivered by their ecosystem partners. Whether it’s buying a twitter service, which immediately skews the playing field for other companies in the same space, or the carte blanche cutting off of API access to particular parts of the platform, there have been many examples of Twitter “screwing over” its ecosystem for its own benefit. Buddy Josh Robb hit the nail on the head when he said:

But Twitter isn’t the only example, recently Netflix decided to no longer issue developer keys for its public API.

But is this really a fair summary? Recently John Sheehan from RunScope wrote an excellent post in which he attempted to give developers some guidance when they’re thinking about building a service that takes advantage of platform APIs. Sheehan’s perspective is that in many cases the interests of the developer, and of the API provider, are not aligned. As Sheehan wrote:

Is an app that helps you manage your Netflix queue driving meaningful new subscriptions for Netflix? Probably not. Is another Twitter client helping Twitter sell and show you ads? Definitely not. When the most important transaction for Twitter was someone putting content into the network, it made sense to allow that content from anywhere. That’s no longer important to them. This is the future of Twitter APIs.

Sheehan’s post is a real wake up call, for a long time developers, and the industry at large, has been living in a kind of alternative reality. This skewed vision of the world assumes that platform companies will continue to invest time and resource to develop and maintain their public APIs regardless of whether doing so provides any real value back to the business. It’s almost like we’ve started to believe that these platform companies, commercial entities that they are, approach their public APIs as some kind of public good work that they do for the Karma.

Unfortunately this mindset has been encouraged by the investment world – on the one hand VCs have been quick to encourage developers to build solutions on top of other’s platforms – possibly to further their own opportunistic interests as investors in those same platforms. On the other hand VCs have been running around putting wads of cash into many of these end-point services, perhaps believing their own idealistic, if slightly shonky, view of the future.

In his post Sheehan advocates for a stronger dose of reality for people contemplating building a service on top of an API platform. As he wrote in his post, the three rules that companies need to remember are:

Thou shalt not freeload

For infrastructure and SaaS APIs, the relationship is clear: you pay for the value you receive either transactionally or as part of your subscription. For everything else, the provider of the API you are using should benefit equally or better from the value your use of the API is providing. If your app is not driving direct transactional value for the provider, you’re in a risky situation.

Thou shalt not forego talking to a person

An open API is a great way to test drive an integration, but it does not absolve you from the responsibility of building a relationship with the provider. If you can’t reach someone, that should be all the reason you need not to use that API.

Thou shalt monitor everything

Using a third-party API is code for your application that happens to run on someone else’s servers. Use the same level of rigor for monitoring and testing that you would for the code that runs on your own machines. When something goes wrong (and they will), have systems in place to notify you before your customers do.

Sheehan is absolutely on the ball here, his history (he was formerly at IFTTT – a company completely built on an API play) gives him a deep understanding of the economic drivers behind a vendor’s public APIs. But more broadly than the particular API perspective, Sheehan’s post points to a much more practical perspective on business that is arising in the industry. The reawakening of attention for enterprise software, the less than stellar post-IPO showing of a number of consumer facing companies (Zynga, Facebook, Groupon) and the oft-discussed series A crunch that means investors are looking for proven and defensible traction before funding a startup are all adding up to a far more pragmatic view of the world.

APIs are an amazing enabler of innovation, and an integral part of the way companies can build their product, their userbase and their presence – but unless they think about mutual benefit, a real relationship with the provider and a strong focus on making sure the “lights stay on”, that massive opportunity may just disappear in the blink of an API providers eye.