There's a crucial step that's easy to overlook: Make sure you have a solid plan for how you're going to update your API. The ideal is a versioned API, where old versions are supported indefinitely. If that's not plausible for you, consider how you're going to communicate changes to developers with enough lead time for them to update their apps. (And you'll still want to version things, because it's no good to make everyone deploy at the exact same time as you.) Remember that since you don't have control over third-party code, even changes that seem totally innocuous to you might break things.

Couldn't agree more, we plan to keep meticulous documentation, version control and a moving forward only approach with new API versions. We realize that changing even the most trivial functionality in the API can cause issues.

It's often hard for a web company that's used to agile-style fast release cycles to get in the proper mindset for maintaining an API. The ideal is for breaking changes to be rare, and done with a lot of lead time. This can of course be different in a beta period, but communicate that heavily and plan to lock things in eventually.

Yes, we do plan on having a beta period dedicated to working out the kinks.

Thinking about the business side of things is also important. Start thinking now about what sort of apps you'd be tempted to try to shut down, and whether you're going to do that. Try to come up with a terms of service that you can live with for a long time, because nothing makes developers more wary of a company than them shutting down any third party service that gets too popular.
Get all of that right, and you'll be head and shoulders above 90% of APIs out there. :)

Some great advice here, thank you.