What Puts the Open in Open API? Adam DuVander July 10, 2013 Product, Technical // SUMMARIES ?> Open APIs make the web better. Heck, they make the world better. They’ve certainly made SendGrid better. Isaac, Jose and Tim entered TechStars with API in the company name, so it’s an important part of who we are. API as a term has existed for almost as long as computers, but the heyday of web APIs began in 2005. Google released its mapping API and inspired the creativity of thousands of developers. With it came this idea of the “open API,” a nebulous concept that I’ll try to clear up in this blog post. However, it gets sticky because there are so many different definitions of “open.” In those early days, we called something that used multiple APIs a “mashup.” It was pretty much expected that a service would cost nothing. Similarly, we expected the service to be available to anyone. The biggest barriers were usually registering for an API key. Many still use this definition when determining whether an API is open, but it’s short-sighted. As Mehdi Medjaoui writes, open is not a binary choice. There is flexibility. The snarky definition of open would be “not closed.” That’s hardly helpful, though it does differentiate open APIs from another API trend. Every mobile app that does anything interesting has its own API. Almost all of these APIs are private, available only to the app. Maybe the company behind the app uses the same API internally for other products. A private API is certainly not an open API. As I have discussed this topic and considered the many API examples I’ve seen, there are three signs that I look for in an open API: Acknowledged — the company or entity behind the API acknowledges that the service exists and is available for some practical subset of all developers. Documented — information on how to access the API is available in some capacity, on the open web, behind a registration/pay wall, or directly from the provider. Supported — someone is available to answer questions, fix bugs and provide the support needed to use the API. The kicker here is that these three aren’t a checklist, but rather levels of openness. At the very basic level, an open API needs to be acknowledged. This is what separates it from a private API. A documented API then becomes more open and a supported API even more-so. This loose definition invites more companies to the table, because it accepts that business decisions are naturally going to be involved in how open a company can be. As Marco Arment wrote in his recent post Lockdown, “You aren’t entitled to unrestricted access to someone else’s service.” Some may point to Google, Facebook and Twitter closing, restricting or never opening APIs that people want. And holding on to data–our data–is a disturbing trend. I’m bullish on open APIs, despite these signs from major players. I concluded my keynote at API Days SF (slides above) with the best reason to expect open APIs in the future: people are asking for them. Not developers, but real people, care about APIs, even if they don’t know that techy term. When Twitter shut off Instagram’s access to its API, users complained. Here were real people affected by an API decision. Holding customers’ data hostage will only work for so long. With the continuing proliferation of smart devices, I hope we’ll see an expectation that our own data will be available in a way that plays well with others. There are actually earlier signs of end users voting for APIs. In 2010, cloud accounting company FreshBooks wrote that its free customers were three times as likely to pay for the service if they used an integration. Here you have people asking for open APIs with real money. These days it’s not a question of whether an API exists. If there’s an app for that, there’s an API for that. The question is whether that API is made available. When customers expect services to work together, they’ll implicitly expect an API to be acknowledged, documented and supported.