How to Harness the Power of Open APIs

Adam DuVander
Dec. 09 2013, 08:00AM EST

In the very early days of APIs, when John Musser founded ProgrammableWeb, the default for every new API was open--wide open. As the industry has matured, companies have become more careful to enter the open, public API waters. Though the number of APIs is still growing rapidly, most new APIs look very different from those of a few years ago. Popular services used to launch with public APIs, or perhaps have them soon after. Now the popular services are more likely to hold out for awhile, perhaps learning from those before. This wariness of openness has perhaps gone too far, ignoring the positive potential of embracing the ecosystem.

The Case Against Open

Firstly, the whole label of "open" is often misunderstood. Developers and providers alike often interpret it as "free of cost." A better term, which I've been trying to use more, is public. The idea of public APIs--those that are available for developers to sign up--contrasts nicely with private APIs, which are typically only for use internally within the company that creates it.

The Google Maps API is the classic example that many think of with an open API. For years the service was free for unlimited usage an any number of sites. Google even once deprecated API keys for geocoding. The era of mashup mayhem created thousands of websites plotting any data onto a map, including data that doesn't even belong on a map.

Google Maps, and the Facebook craze that followed, caused many companies to believe the secret to API success was to not make any money off of your API. Somehow, you'd make up for it. Developers would build something you never thought of and from that something amazing would be born. This happens sometimes, but it's far too laissez faire for today's web.

How Twilio Landed Intuit

SMS and voice API company Twilio has long been a model of public APIs. Twilio might be way overused as an example, but the following story of how it landed Intuit as a customer is too good to pass up.

Intuit is a much, much larger company than Twilio. Even though Twilio has raised over 100 million dollars, Intuit turned 30 this year, has over 8,000 employees and billions in revenue.

Yet, a couple years ago on a Friday afternoon one of those thousands of Intuit employees was browsing Twilio's website. Documentation and code samples abound. The employee was able to register directly for an account and use free credits to test out the platform. She went home and over the weekend built a prototype to perform voice verification phone calls.

On Monday morning she showed the test application to co-workers. They agreed it would go a long way toward helping verify the millions of people whose salary runs through Intuit's payroll service.

Intuit Payroll is a major Twilio partner. It was simply open documentation and a self-serve interface that won Intuit's business.

Infrastructure Sells, Business Models Abound

Twilio provides tele-communications infrastructure. Making voice calls or sending text messages programmatically is hard stuff that Twilio makes easy. Because it provides immense value, it can charge developers money for the time and investment they save. There are many examples of these new types of infrastructure businesses.

The idea of "the cloud" is infrastructure made virtual and sliced up to be affordable to anyone. Amazon and many others are doing it with storage, computing power and databases. My employer does it for email. Infrastructure APIs take a developer problem and make it go away. The solution is self-serve, available to all, which makes it highly scalable from a revenue perspective.

That's not to say infrastructure APIs don't have employees devoted to business development or sales. Most do both, some relying on the self-serve as only one form of lead generation.

And though infrastructure APIs are the common example of APIs as Products, there are many others that are able to get developers to pay for their API. Even Google Maps, the gold standard for wide open APIs, has learned from the API as Product trend. High volume websites must now pay to access the Google Maps API.

Developers paying for an API is only one of many API business models. The key is to make sure the API provides a value to developers and that by developers using the API, they provide value back to the provider.

For more on this topic, check out How to Choose the Right Business Model to Win the API Economy.

Adam DuVander is Developer Communications Director for SendGrid and Contributing Editor of ProgrammableWeb. Previously he edited this site and wrote for Wired. You can follow him on Twitter.

Adam DuVander -- Adam heads developer relations at Orchestrate, a database-as-a-service company. He's spent many years analyzing APIs and developer tools. Previously he worked at SendGrid, edited ProgrammableWeb and wrote for Wired and Webmonkey. Adam is also the author of mapping API cookbook Map Scripting 101.

Comments

Comments(1)

Hey Adam -- great piece that helps me to think through some important concepts about "open APIs". Your historic take helps contextualize the place of open APIs today. I agree that making a "public" vs "private" distinction is helpful to clear up confusion, as well as finding concise terms to indicate whether something is free-of-charge vs requiring-payment. I will study the post on business models for APIs.