API Monetisation: A Comprehensive Guide (Part 2)

This is part 2 in the series of API Monetisation. You can find part 1 (an introduction to API monetisation and why it’s important for all businesses) here, and part 3 (on indirect monetisation strategies) here.

Direct API monetisation is probably the first thing that comes to mind when you think about how to make money from an API. Direct API monetisation is where you charge a fee for API use and access.

Directly charging for your API makes understanding the value to the business relatively straightforward because you have relatively straightforward measures of revenue and cost.

One of the best global examples of direct API monetisation is Stripe. Stripe started life as a simple API for developers to process payments with, which rapidly grew and expanded into, what they call, the economic infrastructure of the internet with millions of customers. With the simple API they started with, they charged a percentage of the transactions you processed with the API.

Another example of direct API monetisation is Twilio. Twilio started as a simple API to allow developers to send and receive SMS as well as run voice calls and conversations. Twilio charges for usage, charging per SMS or call minutes.

As you can see, direct monetisation of your API makes the commercials for your API and your measure of success simple. But behind getting to this simplicity requires some thought and consideration. The purpose of this part of the guide to API monetisation is to walk you through the key aspects of direct API monetisation so that you can determine whether it’s the right fit for your business, implement it or improve what you have.

The topics we will cover are:

API Pricing Models
General Customer Segments
Unit of Value
Billing
Other Considerations

API Pricing Models

When you think of pricing an API directly you probably immediately ask yourself questions like “will I charge a subscription? Per transaction?” so this makes for a good starting point.

The different API pricing models you have available are:

Subscription
Usage-based
Revenue-share

These pricing models are no different to the pricing models generally available to any type of tech product so, for the purposes of this guide, the focus will be on how these pricing models are used with APIs.

Subscription Pricing

A customer pays a pre-agreed fee at regular intervals (monthly, quarterly or annual) for use of your API. Prices are set in subscription tiers where a higher or lower price gives you more or less functionality and benefits respectively. There may also be add-ons for modules of the product or service with a specific purpose in mind.

With standard software-as-a-service (SaaS) products this is the most common pricing method. It’s also where many other industries are moving or have moved.

Usage-based Pricing

Usage-based pricing, sometimes referred to as consumption-based pricing, is where you price your API in such a way that it increases or decreases as it is used more or less respectively.

You could argue that usage-based pricing, especially when paid for monthly, for example, is a form of subscription but the key differences and reasons for treating them separately are:

For our purposes here, think of the subscription pricing as “Fixed, regular pricing”
Usage-based typically varies month-to-month or day-to-day as usage goes up and down. With a subscription, people expect a set price.

Revenue Share Pricing

Revenue share pricing is where your charge is based on the revenue made from the use of your API. Usually, this charge is in the form of a percentage of sales made with the API.

The key challenges with this form of pricing are that you must also have a way to track the sale and that your customer has a strong, direct association of the sale being made to the value you provide.

Usage-based pricing and revenue share are somewhat similar with the key difference being that revenue share is directly tied to the revenue that your customer receives. While usage-based pricing is tied to another measure of value that your customer receives from more usage.

Comparing the Pricing Models

When it makes sense to directly monetise an API, there is also usually a clear corresponding task that the API performs. This clear corresponding task lends itself to usage-based or revenue share.

APIs by their nature – being software programs – need to have a relatively defined task that they execute for the customer. Twilio sends an SMS, Stripe processes a payment, MailGun sends an email. Whereas the typical software-as-a-service product’s benefit or task it’s performing is often slightly less simply defined and measured because it involves humans and the scope of its task (or Job-to-be-Done) is a bit broader. For example, the task with Google Docs is harder to define because it could be user collaboration or documents produced or complexity of the document.

For APIs that are directly monetisable, being more likely to be usage or revenue share based is good news economically. Usage-based and revenue share pricing allows for a greater capture of revenue potential across a greater segment of customers.

You can see the different pricing models along with their relevant value capture curves in the graphic below. You can see that usage based or revenue based pricing, theoretically, leads to the greatest capture of potential revenue.

You can also combine the different pricing models. For example, Segment has a base subscription at $120/month then charges for every additional 1,000 users you track.

Before you settle on a pricing model for your API you need to understand the customer segment you are targeting and the value you are providing to them.

Customer Segments

At one level an API is no different to any other product in that you need to understand your customer and the better you understand your customer the better you can get to the right approach to API monetisation. Frameworks like Jobs-to-be-Done and the Customer Value Proposition Canvas can help you get the right type of understanding.

That being said, with APIs there are some broad, general customer segments that customers fall into: Developers, SMBs, Enterprise and Partners. Each of these general segments have some common considerations that are outlined below.

Developers

Developers are the people that are on the front lines of building software that works with your API. They’re the ones that will connect whatever your API does to their software to make everything work together.

The key considerations for this segment are:

Technically able: Developers are able to start using an API almost immediately because they have the technical capability to work with an API. So you need to monetise in a way that reduces friction to getting started and enables fast use.
Try before they buy: Developers have learnt through experience that the only way to really know if an API will meet their needs is to actually work with it. So, they’re usually reluctant to commit (pay) until they’ve got it working with their software and they need a way to use it for development without incurring significant costs.
They usually have free alternatives: Developers can often build what your API is doing for them and, even if it takes them longer, may still be willing to do so even though it may appear uncommercial (often it isn’t their money that is being spent). Additionally, developers have access to open source software that may do the job of your API. The point here is developers have access to alternatives that, to them, are free.
Low desire or capacity to pay: most developers don’t have the capacity to pay either because they want to try it out personally, the project doesn’t have the budget or they don’t have the influence in the organisation (yet) to gain a significant budget. Some organisations see APIs as technical problems for developers that just mean higher costs rather than productivity gains. While this often changes as an API proves itself, to start with the capacity of developers to pay is often low, even in larger organisations, to begin with.

SMBs

Small and medium sized businesses (SMBs) are organisations that generally have anywhere from 2 to 1000 people.

Within these organisations, there are broadly two main tasks that APIs will be involved in:

Connecting their software with other software and automating processes or
As part of developing a competitive advantage.

With the latter, SMBs tend to (big generalisation) behave like the developer segment so for our purposes here we will focus on SMBs as the segment of those connecting and automating in a business of under 1,000 people.

The key considerations are:

Limited technical capability: SMBs may have a technology team but the team is usually generalist or specific to supporting the SMBs chosen technologies which usually means a lack of capability when it comes to developing against and consuming APIs. So, you will likely need to provide some assistance in the sale process and these costs will need to be accounted for in your approach to price.
Low willingness to pay initially but can invest once confident: if the business case stacks up they will often have the ability to pay but often the case isn’t clear and the risks can seem higher, especially with the limited technical capacity. This lends itself to pricing that allows for low barriers to try but then an ability for an SMB to invest more to get the support they may want once they gain confidence.
Entrepreneurial approach to budgets: SMBs will look for ways to align costs or keep them low. This is often more important than predictability.

Enterprises

Enterprises are large organisations that are likely using APIs in a range of ways, from automation through to helping them with their competitive advantage.

The key considerations are:

Technical capability: They have the ability to work with APIs in the manner that they need to and they’re able to evaluate APIs. Often they’ll want to do the evaluation before committing.
More requirements: enterprises usually have a list of requirements that need to be met for them to work with your API and will need to know these requirements will be met before they proceed to a purchase.
Predictable spend: Enterprises want to know what the bill will be and tend to value certainty over the possibility of making some savings.

Partners

Partners are organisations that are either looking to resell your API in some form or build on your API or platform.

Key considerations with Partners are:

Technically capable: they will have the capability to work with your API and, in some cases, work around your API.
Low cost in trying: Just like developers, Partners will want to know that they can try working with your platform, to ensure it will work they way they need it to, before they commit.
Only pay when they get paid: Partners will only want to pay you once they’ve been paid or know they are going to get paid.
Noisy: There are a variety of ecosystems and platforms that Partners can build upon, resell or connect to. To cut through you may need to offer incentives or at least make it easy to participate.

Choosing your customer

These customer segments give you a starting point for thinking about who the customer of your API is – it may not always be the customer you have for your existing product. You will need to dig deeper and conduct research, like customer interviews, but you can also form a hypothesis and push ahead with this guide then come back for iteration.

Unit of Value

Once you have a view on who your customer is, you need to understand what the primary value they gain from your API will be. This is how your customer thinks about the benefit they get and that they will use in evaluating your price.

Jobs-to-be-Done is a standout framework for getting to your primary unit of value. It’s been used in business-to-business tech products by companies like Intercom as well as consumer companies like McDonalds. In its simplest form Jobs-to-be-Done asks “what is the job your customer is hiring your API to perform?”.

Knowing what you are doing for the customer – what pain you’re removing, what gain you’re bringing – will lead you directly to the unit(s) of value that you can price around. You may end up with multiple proxy metrics that you need to reduce down through a combination of customer interviews and considering what will scale with your customers.

Here are some examples of units of value:

Segment, a user tracking API platform – number of users tracked
Twilio’s Mobile Messaging (SMS API) – number of messages sent
Stripe’s payments service – number and value of payments processed

Billing

Billing is the practice of charging your customer and collecting the money from them. You need to consider how you are going to bill your customer when going for direct monetisation of your API. Although billing can sound like a back-of-house operation of low consequence, it will have an impact on your success monetising your API.

The key questions you need to ask around billing are:

What’s best for the customer? What’s best for us?
When will we bill the customer?
How will we bill the customer?

What’s best for us? What’s best for the customer?

Narrow down your billing options then refer back to your customer. How do they want to be billed? What would be their preference? If you aren’t sure, ask them how they currently pay for similar services.

You need to weigh this against what’s best for the business. For example, SMBs might want to be billed in arrears but it’s better for your business to bill upfront at the start of the month so you don’t have issues collecting the money at the end of the month.

When to bill

You need to work out the timing of your billing (upfront, in arrears) as well as the frequency (monthly, quarterly, annually, all of the above).

With the revenue share and usage-based pricing you may be limited to billing in arrears (after the usage/sale takes place). Some types of usage may be billable upfront. With subscriptions your choice will be mostly based on the customer and friction you want (or not want).

For some customer segments there is also a preference. Developers and SMBs will want to pay after they’ve used the service, this helps also to reduce friction in enabling them on your API. With enterprise they generally want to know what the bill will be before they commit.

How to bill

You need to workout how you are going to bill your customer. Your options here are relatively narrow: by credit card, by invoice or through credits.

Credit cards are going to be preferable for Developers because it’s easy for them and you to manage. Credit cards are sometimes preferable for SMBs because of the reduced friction and loyalty points programs (think American Express) but at other times they may prefer charges to go through a more controlled procurement process which leads to invoices.

Partners and Enterprise will generally prefer invoices. Partners will prefer it because it allows them to hold onto cash for an additional 30+ days while Enterprises prefer it for cost control.

For Partners and Developers you may want to consider a credit system where they gain credits by helping you grow the business. A simple example would be where developers share the application so get reduced fees or don’t need to pay at all.

Other Considerations

Some other considerations for direct API monetisation are:

Points of friction and enablement: You need to think about how your approach to monetisation interacts with friction and enabling customers to use your API. This will be covered in the API Shop Front section of this guide (still to come).
Freemium: offering a free version of the product is more of an acquisition strategy rather than a type of pricing. You can have a free tier under the subscription, usage based or revenue share pricing models.