How To Roll Out An Open API

I’ve met a lot of companies working on web services APIs while I’ve been working on Where 2.0. These companies want to reach programmers like me, the ones who will play with something, build a cool app or two, then promote it within their company if they like it. They want to know how to make their service attractive to these Internet programmers.

I always tell them, “Make it useful and easy.” All too often the company is so tied up in its existing business that its idea of an “open API” is 10 hits/day, strictly non-commercial use, SOAP-only, with fax-in paperwork only downloadable with the latest version of IE on Windows. They’re looking at the API purely from the point of view of the provider. But if you want me to use this API, you’d better start thinking about it from my side: I want something that’s easy to start using and that will scale with the coolness of the apps I build.

Low Barrier to Entry

Sign-up is the first barrier to overcome. I recently tried to sign up for Microsoft MapPoint‘s quite liberal web services API. I got my request approved in short order, but the site where I actually create a developer ID and download the documentation says “this site showcases the latest features of Internet Explorer” and only works on Windows. Internet developers have different browser demographics than their users. Even those who use Windows shy away from IE.

And even if I could get a MapPoint developer ID, it’s SOAP-only. I’m glad Microsoft have provided a Perl module to wrap the SOAP-ness, but that still leaves PHP, Python, Ruby, etc. developers out in the cold. I recommend a REST API, but will take simple HTTP+XML as a minimum: the simpler your API is to use, the more developers will use that API. Most of Amazon’s API hits come through their simple HTTP+XML API, and only a minority use SOAP.

Another option, over an API, is to provide a simple embeddable component. For example, Multimap says “you can embed our images in your site if you use this HTML”. They are syndicating their local advertisement business in this fashion. The Google Maps “API” is really just a way of having Google serve the images and provide the Javascript scrolling, clicking, etc. code so that you need only add your custom layers on top. Google Maps functions as a component, not as a traditional web service.

This component model is an important new aspect to web applications. Ajax makes it easier than ever to integrate web components. Client-side components improve speed for the end user (clicks aren’t relayed through my web server to the API provider, returning a new image that’s then passed through my web server to the browser) and are easier to integrate (simple Javascript is seen as more accessible than PHP or Perl).

Returning to signup, though, consider developer registration in the Internet age: I fill out a short form on your site that doesn’t want DNA samples or anal probes then you mail me a link. I click on the link to confirm that the email address I gave you is valid, and then I am shown my developer ID and token (if you use tokens–Yahoo! don’t, and it’s wonderful). I now have full access to your APIs. Total time taken: 2 minutes tops. If it takes 15 minutes to fill out the form and then two business days for a human to “approve the request”, you’ve already lost a huge percentage of developers. Think of it like this: you want the developers to advertise your service, carry your product, or pitch your full service to their bosses. Why would you make it hard for them to do this?

Scalability: Hits

I build three types of apps: personal, intranet, and Internet. Personal apps use my data, only I run them, and a limited number of hits works for this. Intranet apps are ones I share with my coworkers, and which probably use company-sensitive data. I’ll need more hits for this, because people other than myself are accessing it. The Internet apps are the hardest to plan for if you’re an API provider: on the one hand you want the publicity that comes from a Craigs List-Google Maps mashup, but on the other hand it is probably well over 50,000 hits less than a month into its life.

This is the most important aspect of scalability. It’s easy to offer a service that’s of very limited use: it’s well within a business’s comfort zone. But to do so greatly circumscribes the possible apps I can build. In particular, a very limited number of hits means that if my app becomes popular on the Internet I’ll be shamed when it stops working after the first n visitors. The sight of a “You have exceeded the maximum number of free API calls, please visit for a commercial license that will let you continuing using this service.” message isn’t the great viral publicity you were hoping for when you opened an API in the first place.

Scalability: Bucks

So what’s the solution? One is to have a high cap on API calls. A longer-term solution is to build your business model into the API. In my mind the most successful APIs for the company providing the APIs are those from Amazon and eBay. Amazon’s web services API functions as a franchising operation–it lets other people set up Amazon store fronts. Their terms of service prevent you linking to the competition from Amazon API results, so it can’t be used to promote any online bookstore but Amazon’s. And, most importantly, there’s a way for the API consumer to earn money from the API provider. If I build a killer app on the Amazon API that helps people find books instantly, I can get a slice of the revenue I generate for Amazon.

eBay have also built financial interest into their APIs. Their revenue comes from people placing listings: the more listings, the more money. As a result, eBay’s API is built around placing listings. They’ve build a community of third-party developers who create applications that help end-users place listings. These developers either take a cut or charge for the software, and consequently 40% of eBay listings come through the developer API. Not that this was all good: the grassroots developer here represents the majority of eBay users, the buyers. The buyer API licensing and development process weren’t set up for widespread tools. This may change: eBay may have maxed out listers and now it’s time to increase the listers’ turnover by facilitating buyers. But for now the eBay API is great for the listing tools developers, but has impedence mismatches for open source and grassroots developers.

That’s not to say that free and revenue-less doesn’t have a place: Yahoo! want to make their services an integral part of everyone’s surfing experience. They’re a media company, they own the content, and they want to shift as many people to the content (and thus the ads) as possible. So their API is free (though rate-limited). You might wonder why they give away free search when they make money from the ads on the HTML results page that you don’t see if you use the API. The answer is, I think, partially that they are trading ad revenue for mind share, but also that they collect search terms and clickthrough data that makes their public search better.

At the other end, there are business models for open APIs around conversion rates: 2% will pay for the full service and build fantastic applications that will pay for the 98% and then some. The trap here is that you don’t want to be eyeballing the 98% and saying “you! you’re too popular! Pay us money!” Set the developer’s expectations at the start (1,000 hits/day) and then don’t harass them if they stay within those limits. If someone gets great value from 1,000 hits/day on your servers then accept that you have a happy customer. When their business grows to the point that they need 5,000 hits/day, then you can make your money. If they never grow to that size, don’t think of them as an expense that must be eliminated: they’re part of your userbase and will be happily recommending your service to other people, some of whom will become paying customers.

Google Maps

Sustainability is where Google Maps falls down, by the way. It is only accidentally an API, with a lot of reverse engineering going into it. It’s not even a true web service, it’s more of an embeddable component. There are no terms of service, no guarantees that the apps you build will be permitted to live. There are rumours that Google’s data suppliers are not happy with Google turning into a free reseller without negotiating this new role as part of their contract with the data suppliers.

Google Maps also has no business model. It’s not self-sustaining to give away infinite maps when the maps cost you. The obvious business model is to syndicate their local advertisements as they’ve begun doing with Google Local. That way I can build a killer app using maps, using Google’s map component, and I syndicate Google’s local ads for them. If they took it one step further, they might even add revenue sharing: it’d be in my financial interest to write a porn+warez+politics+religion+Google Maps mashup that everyone on the Internet would hit, because I’d get a slice of their advertising dollars.


Make signup simple, offer toolkits for the languages that Internet developers use, and think laterally about business models. Ultimately, not every developer will have a business model and exit strategy. Identify and help those that do, support those that don’t, and enjoy the rising tide that will float your boat too. It’s not hard, it sounds obvious, but skipping any step will lose you developers.

Readers, did I miss anything? What advice would you give to companies looking to reach Internet developers?