Charging for APIs...SRSLY?

This may be reading too much into random and unrelated things, but the idea of charging people for access to web APIs seems to be coming up more and more around the web. I saw it the other day on a Forbes article about Facebook (saying that one possible revenue stream for FB is to charge for Facebook Connect) and then in a random developer’s post about API-driven applications (saying that monetizing APIs is an good reason to build API-centric applications).

Side Note: I have no beef with the latter post in general…it was mentioned in just one paragraph in his post and he’s encouraging people to do something I wholeheartedly support (building your API as the core of your app). This just brought up an issue that I have strong opinions about and wanted to take some time to cover.

So to everyone out there who thinks it might be a good idea to charge for your API, I have one question for you:

There are a multitude of problems with this attitude. I’m going to tackle one on a specific front and then some more in a general manner.

Forbes thinks so highly of charging for access to Facebook Connect that they listed it as one of only three potential ways for the social networking behemoth to make money. Wow. Maybe I should forgive them, Forbes is a financial publication, not a tech one, but just wow.

If Facebook started charging for its development platform, that would do exactly one thing: cripple its development platform. From my experience Facebook already has a tenuous relationship with developers (built more on a sense of feeling obligated to integrate with Facebook than a real joy in it) and adding a toll booth at the entrance to Facebook integration is only going to snap that tenuous link.

That’s not to say that some wouldn’t pay the price. All of those multi-billion dollar brands would probably happily still pay for their Facebook promotions. Zynga would likely pay up (begrudgingly) so as not to lose their stranglehold over the free time of the casual Facebook gamer. But smaller companies, individual developers and startups? No thanks, I can build on top of someone else’s social graph if you’re going to make me pay for Facebook’s. I hear Twitter is integrated into the iPhone these days.

Charging for Facebook Connect (which is not even what it’s called anymore) is also completely orthogonal to Facebook’s company mission to Borg-style assimilate the concept of identity on the web. It is to Facebook’s enormous advantage to get every site they possibly can integrating with Facebook, because that only drives more data and more eyeballs to the advertising and other means that will actually make Facebook money over time.

OK, so now I’ve got this little rant about Facebook off my chest, but let’s talk about the general question because I can see how it would be tempting to charge developers for API access as an additional revenue stream for your startup.

If you’re building a startup (especially a consumer facing one), monetization might be a tricky question. You may have pressures from investors or even just yourself that say “I need to know now how I’m going to make money.” In general, that’s a good thing, I think the “just get an audience and money will work itself out thing” is a dangerous line to tread. However, if you’re thinking monetization and “I know! We’ll charge developers to access our API!” I’m here to put a stop to that madness before it gets worse.

1. API friction is already a problem. It’s hard for developers to integrate with new APIs. They have to learn a whole new set of methods and no two APIs are really implemented alike. You will likely already have to pour blood sweat and tears into docs and developer relations just to get a decent community using your free API. Charging for it is only going to increase this friction.
2. Your API is not your business. You are presumably creating a product that has some sort of business value beyond its API (if your API actually is your business, maybe you can charge; see the section below). But the moment you start charging for access, your API is your business. And paying customers are going to have big expectations, meaning you now have to serve your API customers in addition to your normal customers.
3. APIs should enhance your core business. Do you remember why you wanted to build APIs in the first place? It was probably in the hopes that developers would make awesome tools for your product that you didn’t have to build but nonetheless drive additional audience and/or customers your way. Charging for your API makes it more likely that developers are going to charge for their API products and you lose out on this benefit almost entirely.
4. Developers will go elsewhere. The problem with marketing yourself towards developers (and this is what you’re doing if you charge for API access) is that they’re going to be a savvy bunch. If they can find a way to do for free what you offer for charge, they’re going to flock to it. Expect zero traction unless your product is so unique and peerless that they have no choice but to buy in. And even then, many developers would just take their toys and go home rather than integrate with a paid API platform.

Hopefully this gives you some idea of why charging for an API is generally a massively bad idea. Of course, there are exceptions to every rule, and I’d be remiss not to point out that sometimes charging for an API can make a whole lot of sense.

So when is charging for an API OK? When your API is your product. That’s it, that’s the only time.

What do I mean by that? Startups that cater to developers by providing means to accomplish difficult-to-do thing via a simple API. Think of a simple API for grabbing screenshots of web pages, or semantic text analysis as an API, or an API for sending and/or receiving faxes. You can charge for an API when your API is going to take pain away from developers because in that scenario the developer friction works in your favor. If your API is much, much easier to use than the free alternative, finally you have the leverage you need to charge developers, and they will gladly pay.

The other potential scenario where it makes sense is when the infrastructure costs of providing your API are so significant that you have no other option. Twitter’s firehose is an example of this. The sheer volume of data that has to be transmitted to firehose partners demands payment because it requires dedicated operations support and resources just to make sure it doesn’t all come crashing down. And that only works because Twitter already had millions of users when they started charging.

So please build APIs, because APIs are an important part of the current and future web. Here at Opperator we’re building an API-centric app where the web interface is just one more client. But don’t charge for your APIs; it’s bad for your business and it’s bad for the development community.