John Sheehan is a co-founder of Runscope, an API tools company in San Francisco looking for engineers and designers to help build the future of developer tools for API-driven applications. Previously, John was at IFTTT and Twilio.
Last week Netflix announced that it was no longer going to issue developer keys for its public API, effectively ending their open API program.
30,000 tech-heads descend on Amsterdam
Join us and 30,000 others at the 12th edition of TNW Conference. 2-for-1 tickets available soon.
This type of change isn’t unheard of. Consumer internet services (including the social networks) are increasingly moving to a private/partner API model where a more formal partnership must exist in order to use the API.
Use of APIs on the whole is growing like crazy. Infrastructure providers like Twilio, SendGrid and Stripe have shaken up entrenched, crowded markets by providing better APIs. Building SaaS without an API? Good luck landing that big deal with someone who wants to do a custom integration into their legacy back-end system. Companies like IFTTT are exposing APIs to the masses without them even knowing it.
Even some consumer internet companies are getting great results from their API programs. 90% of Expedia’s business comes through their API. For eBay, 60% of listings come through its web services (and that was back in 2008, I imagine it’s much higher now). Open APIs that drive direct, mutually-beneficial transactions work.
That’s just scratching the surface on what we can actually see. By my own estimate, I believe that the vast majority of API traffic is on ‘dark APIs’ behind a corporate firewall or powering mobile applications. At a recent conference, a team from Target presented on the rapid API-ification of their internal infrastructure.
As they become an increasingly service-driven organization they’re seeing more than just technological benefits; they’re able to extract new business intelligence from analyzing their API traffic.
So why aren’t more consumer internet companies seeing the same value? In short, the interests of the developer and the API provider aren’t aligned.
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.
For app developers, it’s time for us to be smarter about the services we rely on in our applications. It’s no longer acceptable to depend on a third-party API provider for mission-critical functionality without taking steps to protect yourself from the whims of another company. Here’s how to mitigate the risk.
Three Commandments for Using Someone Else’s API
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.
APIs are an amazing tool, but they’re a means to an end. When the interests of the provider and consumer are aligned, great things can be accomplished with very little technical effort. Take care in your applications to protect yourself and your customers by being smart about what services you rely on.
Image Credit: MARTIN OESER/AFP/Getty Images