A top concern for treating your API as a product is creating a profitable business model. However, on the face of it, immediately charging people to use an API might seem like a strange thing to do, as adding a barrier to entry isn’t always desirable for Software-as-a-Service (SaaS).

So how do we monetize access? Charging an across-the-board access fee of, say, $1000 per month feels strange if one API consumer is logging 50 calls per day and another logging 50,000. As a result, freemium plans are a common solution for API providers. They allow free use until a certain threshold, then charge by the call thereafter. Freemium is arguably becoming the de facto choice for monetized public APIs. Take the Mashape API marketplace, for example. Although flat paid options are possible, they strongly encourage the freemium model by suggesting paid plans with increased API calling limits:

Why the Freemium Model Works for APIs

We’ve previously written about different API monetization methods, but to review, here are common methods:

1. Charging directly
2. Using API access as an upsell in your premium model
3. Drive revenue generation through activities performed by your API
4. Form strategic partnerships through the use of APIs
5. Improve operational efficiency and decrease time to market

An advantage of charging indirectly using a freemium model is that it doesn’t necessarily conflict with the other four revenue generation tactics. In fact, it can even help because it places a monetary value on the API. Though the freemium approach may not be right in every scenario, services like MailChimp and Buffer have proven that the freemium model is a viable one on which to build a business.

Sujan Patel also points out on Forbes that the freemium model is much better for exposure:

“If you search for mentions of MailChimp (freemium product), you’ll find 10M results. If you search for Aweber (premium only competitor), you’ll find 718K results.”

Of course, you can’t pay your bills with exposure. But in the case of an API, which may well be generating buzz around the paid product of which it is an offshoot, this is definitely a good thing. The freemium model makes sense as income scales to cover the operational expense of an API. With a freemium API, more calls = more revenue = more money to reinvest on maximizing your uptime and ensuring that your setup is as robust as it can possibly be.

Things to do When Implementing a Freemium Model for your API

Before

Let’s assume that you’ve already dealt with the technical side of things – language, documentation, security, testing, etc. – and are now looking to implement monetization. Before doing so, there are all sorts of things to factor in:

• Talk to your users and current API users. What do they think is the most valuable data your service has to offer? Would they be willing to pay extra for it?
• Your premium conversions must cover expenses, and ideally generate revenue too.
• Ensure that your documentation is as up to scratch as it can possibly be.
• Create a plan for how to communicate the benefits of the paid version of your API and how you are going to convert users.

That last point is perhaps the most important one. The bad news about creating an API that involves some form of payment is that you’ll probably receive fewer passive signups, but the good is that those who do sign up will probably be more serious about working with you on a long term basis.

See more Insights on API Business Models:

During

Ensure that the pricing model for your API is competitive. Is there a breaking point; a perfect balance between maximizing revenue and tiers that is attractive enough to get high numbers of users to convert?

As you’d expect from the very different nature of the products below, there’s some differentiation depending on the space we’re talking about… but perhaps not as much as you might think:

source: Moz

source: Microsoft Azure

source: Mapbox

source: Imgur

source: XE.com

source: FullContact

With the exception of Moz, which comes in a little higher, the following looks to be a pretty good benchmark for pricing a freemium API:

But please don’t think that’s the job done for you! The above is intended only as a rough guide to show how startlingly similar freemium API pricing models are, even across very different spaces. Setting and maintaining competitive pricing is one of the biggest challenges of adopting the freemium API model.

After

Just like any business, a monetization model needs tweaking to sustain and increase conversion rates. To keep your program attractive, and API integrations usable , fuel this iteration with feedback from current users and from the companies that have previously expressed an interest in working with you.

To save API consumers countless hours and headaches, consider offering additional time-saving features. For example, MailChimp provides an API playground that allows API consumers to noodle around with the API without putting things live and burning through their calls. You could also take your sandbox a step further with virtualization, or a dashboard to monitor API usage. With tiered plans, there must be an easy way to check usage. This is something that Moz does well, with the ability to monitor API usage directly from their API dashboard.

Launching a freemium API is just like launching any other product – it requires a lot of thought before, during and after the launch, and you can’t be afraid to admit – or try to hide it – when things go wrong!

Why you might NOT want to charge for your API at all

Just because you can doesn’t mean that you should. That adage is true of charging for APIs for a couple of different reasons.

First, you might kill your API. If your API has a userbase of thousands who enjoy tinkering with the data it provides but don’t have any real need for it, introducing fees to use it could put the majority of them off, which could kill exposure for the parent company or product.

Second, calculate what it costs to provide your API in the first place. If these can be absorbed into the running costs of the business as a whole, you might think twice about charging for your API.

Do the math

Consider the value your API currently offers – integration partnerships, what percentage of your traffic is generated by referrals. Now try to estimate what proportion of those currently using your API would pay for the service. This is a big ask, as it could be anywhere between 10 and 70% – the percentage of users making daily calls should help you form an approximation in your mind.

Now ask yourself whether the ARPU (average revenue per user – more on that here) multiplied by the number of projected users, i.e. how much you stand to make from charging for API access every month, is a fair trade-off for what the API does currently. Because, while that value won’t go away totally, it will probably lessen.

Is charging for an API the norm now?

In 2011, cueing up a quote from Augusto Marietti, Mashable wrote that “while the majority of APIs are now free, that trend is changing.”

Five years later and that’s not really the case; most of the APIs that are dominating the market in a big way – the likes of Google, Twitter, Facebook – are still free. Of course, there’s an argument to be made that most of these brands don’t charge for using their APIs because they can afford not to. There are in fact a handful of key reasons why companies might want to charge for using their API:

1. The API is a product: Businesses charge customers to use their products and an API is an extension of a product or, in some cases, even functions fully as a product on its own.
2. Development resources: Building and maintaining an API requires hours and hours of developer time and commitment. It only makes sense to charge to cover at least some of that expense.
3. Operational expense: Answering thousands, or even millions, of data calls requires a solid, reliable setup with as close to 100% uptime as possible. And those don’t come cheap.

The idea of buying sight unseen – which is, in effect, what a pay to play API with no free version is – is one that doesn’t appeal to the vast majority of API consumers. And the data even seems to suggest that things are heading that way. We took a look at how many pages of free, freemium and paid APIs were on offer in Mashape. It looks like this:

• Free: 52 pages (66%)
• Freemium: 22 pages (28%)
• Paid: 5 pages (6%)

Unless a company can a) comprehensively demonstrate API functionality within demos or sandboxes or b) prove that the data/functionality they provide is absolutely indispensable, it seems unlikely that paid APIs without a Freemium ladder will become the status quo. Freemium? Maybe. But paid, no.