Attracting Developers to Your API

Guest Author
May. 23 2011, 12:00AM EDT

This guest post comes from Alex Willen, Business Analyst at Box.net. Alex works with the Box platform, improving its usability and evangelizing it to developers.

An API can be an extremely powerful tool, allowing you to expand the functionality of your product without having to do the development yourself. To achieve this, however, you need to get developers using your API. If you’re Google, that’s not an issue, but if you’re a young startup, it can present a real challenge.

To maximize the appeal of your platform to developers, you need to provide a number of things. First and foremost is a high quality core product, ideally with a large user base. Second, it is essential to offer the best possible user experience for anyone working on your platform. Documentation should be easy to locate and well written, and sample code is a must.

Beyond that, you’ll want an active developer community. That certainly raises chicken-egg issues, and it won’t be possible right away. Nonetheless, you should keep it in mind as early adopters start to use your platform and get them interacting with one another in a public forum as much as possible. Finally, provide developers with a way to market their apps to your users. They’re spending time to create useful tools, so it’s in everyone’s best interest for you to give them a direct line to your user base.

Before I delve deeper into these topics, I should clarify that this article is about open platforms that are designed to augment your core product, not to make money on their own.

Number of users

When developers are deciding whether to use your platform, they will certainly check on the size of your user base. The reason for this is simple - the more users you have, the more users you can send to third party applications. I won't belabor this point, however, because if you're not already doing everything you can to attract users to your service, you should probably start focusing on that.

Features

There are two very important measures of the quality of the features you're offering through your API. First, how do they compare to those offered by your competitors? When developers are evaluating the Box APIs, they're often comparing us to sites that offer only basic online storage (like the recently acquired drop.io). We shine in those comparisons because in addition to storage, we also have features like commenting, tagging, and search. Even if developers don't use these in their initial integration, they know they're available if they want to expand the integration later.

Second, what proportion of your site's functionality is exposed through your APIs? Where at all possible, anything users can do in your application, developers should be able to add into their own applications through your APIs. There will probably be some methods you can't give out for reasons of security or because of future changes you have planned, but even in those cases, try to have private APIs available that you can give out to trusted developers. This gives the dual benefit of making those people feel appreciated and getting you feedback before you release those APIs to the public.

Ease of implementation

As a principle, the less work developers have to do to integrate with your application, the more likely they are to do it. Thus, the lower you can make the barriers to entry, the better off you are. This means that you should have easy to locate, well organized documentation for all of your API methods, as well as sample code in a variety of languages.

Place as few restrictions on usage as possible. Ideally, developers should be able to automatically generate API keys without the need for you to manually approve them. Try not to put rate restrictions on the number of API calls, and if you do, make sure they're high enough that they'll only be catching malicious use, not impeding anyone from honest development.

Community

When developers are examining your platform, they want to know that other people are using it. A healthy developer community is a strong indication that your APIs are up to date and your service is reliable enough that people are willing to invest their time into it.

There are a few ways to demonstrate the strength of your developer community, the first and foremost of which is a forum. A developer forum is beneficial on any number of levels. First, it shows that people are active - not only other developers, but also engineers at your company. Since posts are timestamped, it's very easy for anyone to quickly get a feel for how responsive you're going to be when they have problem. If you're answering questions soon after they're posted, that will certainly help to instill confidence in potential users of your platform. The forum also comes with the added benefit of being a public repository of knowledge, which means that developers can find the answers to common questions without having to dig through documentation or email you, which saves everyone time.

Marketing opportunities

Needless to say, developers want people to use their applications. The more you can help them advertise, both to your users and the general public, the more inclined they'll be to work with you. You can advertise applications that have integrated with your service through all of the usual marketing channels, like a newsletter, blog, and social media accounts.

Once you have more than a handful of integrated applications, though, you should consider creating a directory of applications. Doing so benefits everyone involved - your users have a central way to access other applications that can improve their experience with your product, and developers have a place to advertise their own applications. As a result of both of those things, you end up with happier users and happier developers. Creating a great directory is a topic that's worthy of a separate article of its own, but for ideas I recommend you take a look at Salesforce's AppExchange, Evernote's Trunk, and certainly our own directory at Box.

The bottom line

Developers who are thinking about integrating with your platform want three things. First, they want to improve their application. Second, they want to get more users. Third, they want the first two things to take as little time as possible.
Thus, if you minimize the time developers have to spend and maximize the returns on their effort through a great product and strong marketing opportunities, you'll soon find yourself with a thriving developer community.

Guest Author

Comments

Comments(5)

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

Alex, this is a great article. You raise some really important issues for anyone who's implementing an API.

But you have to admit this is no easy task. Especially for lean startups that need to move quickly. In many cases API iterations move quickly and managing documentation can be especially difficult.

Add this to the fact that everyone approaches RESTful APIs slightly differently... so even if your API is a shining example of wonderment, there's no guarantee that the next company will follow suit.

Not suggesting that standardisation is required... but it would help!

This is something I'm trying to resolve desperately with Reactor (http://reactorapp.com/)

Hey Simon,

Thanks! I absolutely agree this isn't an easy task - if it was, it wouldn't be worth writing about :)

It's definitely true that managing documentation when you're moving quickly can be a tough task, but it's definitely necessary. After all, you can make brilliant improvements to your API, but if they're not documented, you may as well have done nothing at all.

The best thing you can do for that is to have everything roadmapped in advance, and make the documentation as important as the API itself. Lots of folks block off time specifically for API development, but only plan to get to documentation when they have time, which, as I'm sure you can guess, leads to the documentation falling way behind.

I just took a look at Reactor - looks interesting, and I definitely think there's lots of room for new businesses to help improve APIs for all parties involved. I signed up - looking forward to seeing what you're building!

Very pertinent insight.

Somebody should hit Jeff Weiner, LinkedIn CEO over the head with this kind of common sense as their so-called service is a p.o.s. and they even paid apigee (sp) a big fail whale to build "consoles" that are even worse.