The Case for Private APIs

Originally published on Tumblr.

Lately I’ve heard a lot of teeth gnashing over the idea of private APIs. I’ve heard people complain that private APIs exist at all, and I’ve heard people complain that once-public APIs are now private.

If I were a pure consumer of APIs, I might be more sympathetic than I am. But I’m not. My company sells a service through an API, a public API. In the past we’ve provided access to our service through a private API. The two are completely different.

Our private API was complex and difficult to support. It gave our users fine-grained control over every aspect of our platform. We only gave it to high-value customers who were willing to commit to a significant monthly spend. Some months ago we realized that we couldn’t keep up with the demand for access to this API – we couldn’t scale – so we decided to build a public, self-service API.

This one gives users limited control, but it’s conceptually simple, and therefore easy to support. And support, it turns out is the key to deciding whether to make an API public or keep it private.

Support is expensive. Support is hard to scale. Every week more people start using our public API than used our private API in three years, and we support it with far fewer people. If our private API were public, we couldn’t make even a fraction of those users happy.

As I’ve said in the past, APIs are a critical lubricant in our digital economy. I’ve also pointed out that APIs are a lot more than a programmatic interface to a software service. They are the interface to the company behind them. If the company isn’t capable of properly supporting an API, it should keep it private. Developers, in turn, should stop complaining that it’s private. Lubricant doesn’t belong everywhere.