At Bedrock, we look at A LOT of API docs when considering what new systems to add to our platform. Typically, if a system is popular and shows signs of strength in a market or vertical, we'll simply just add it -- it's really not that complicated for us, as we're in the business of integrating systems together.
But we're just one company, and there are lot of other developers out there, many of them independent consultants looking for projects, so it's important to have your platform be as attractive as possible and let developers navigate your waters quickly and easily so that they're more apt to come back in the future. After all, these developers will go a long way to giving you the street cred that you're looking for with your app. Here are some thoughts on how to make that happen.
1. Nail your API Documentation - Are you a developer writing an API that's going to be public facing? Are you a product manager planning this API for public release? Ok, listen up: here's here's how it goes from a user perspective developing against your crazy new API:
"Hmm, ok, there's this documentation that I found, but in order to test this API I really need an account to this system. Is this easy to get? How do I get this? Is there a developer account? Here's a link to a free trial of the product, I'll try that. click."
"Crap the trial is only for 14 days ... hmm, what if my app breaks down the road? I'm not going to pay for a subscription for this project, so I guess I'll just get another trial then -- that sorta blows."
"Ok, got the trial, now let's test this thing out. Hmm, no sample data in the product, let's add some" ... click, click, type, type ... "ok, time to check the docs and make our first call to this API, time to fire up the REST client"
"Dammit, this parameter that's documented for this endpoint clearly isn't working, WTF -- it's documented right here and it just isn't working, NOT COOL!"
"Guess I'll write to the API support group to ask someone for assistance and get this fixed. Probably won't respond for 2 days though, puting the brakes on this project, UGH"
Your APIs are the lifeblood of your app - they are your platform - get them right for developers by nailing your documentation, which doesn't just mean writing nice docs when you release a new API, it means updating your docs as a part of your greater documentation scheme as well. Your APIs will change as your product changes. Update your docs.
2. REST it up (and use JSON)
Want to know what SUCKS for developers? XML parsing -- that sucks. Try writing 300 lines of Python using some crazy library like xml.dom.minidom to parse a giant XML file returned from your API, then have the XML change just slightly 3 months later and then trying to de-bug -- well, you can probably guess where that developer is telling you that you can go stick your XML at that point.
3. Find a B2C niche or Viral Approach
Your "TAM" (total addressable market) of your product matters to third party developers, especially small, indie developers or dev shops that don't really care about your Business Development team. Developers are just like the rest of the greater business world, most of them want eyeballs and users consuming their stuff.
It's for this reason that it's important to provide APIs that can access data available to not just B2Bs, but to consumers as well. It's not super easy to do, but you can count on this meaning a lot to any developer that crosses your path that is considering writing an app for on top of your platform. Get creative, branch out and try something new -- at the least what you'll probably find is that this B2C app is really good at driving leads.