APIs are capable of bringing in millions of dollars of revenue. They expand a user-base, offer a wider go-to-market strategy, add new streams of revenue, and can be responsible in increasing product stickiness and user adoption. They can also burn bridges with developers, soak up precious development resources, and if not properly secured, offer threats to application security.

APIs are products. Just as a good API balances abstraction, flexibility, and learnability, an API business model needs to balance the value proposition of not only the company but also the developer.

APIs as products require the same amount of attention to the 4 P’s of marketing: promotion, product, place, and price. In this article we’ll focus on primarily the pricing aspect. We’ll also discuss monetization and price in general, show how it applies specifically to APIs, and go over benefits of not monetizing your API. We’ll also discuss metrics, and other considerations when developing a strategy. Let’s get started.

Common Pricing

APIs extract the value of your business. Therefore the API pricing strategy should reflect your unified overall business strategy (check out Rob Zazueta from TIBCO’s take here). Not considering the overall impact of an API or thinking of it as a “less than” product could lead to cannibalization of other aspects of the business or money left on the table, so it’s important to consider where an API fits into your overall go-to-market and how to maximize various pricing strategies.

Many times APIs are part of a long-tail play by a company to generate awareness and drive user adoption. Revenue is of course a concern, but investing in an API strategy that will allow a company to innovate and speak to new markets can mean long-term survival. In fact, as the digital transformation continues companies that don’t have an API strategy baked into their overall GTM will find adaptation (and therefore survival) more and more difficult.

Smart companies use a mix of pricing strategies. Even smarter companies will reflect pricing against the changes in the market, in their API product maturity, and in their competition. Since APIs became a thing around 2005ish there have been new monetization strategies (see API Business Models: 20 Models in 30 Minutes – by John Musser), but essentially not much has changed.

Things either boil down to someone (either a dev or a company) getting paid or value made through other methods like awareness, adoption, etc.

To be more concrete let’s look at some common strategies and how they relate to APIs. Keep in mind it’s possible to offer more than one simultaneously for different products:

• Per Usage: AKA pay-as-you-go or “Pay Go”. One example of this pricing model would be how many API calls your business makes. It can be charged individually per call or in bulk like “make 1000 calls and then we charge you $X”. This depends on the actions performed by the customer. Some customers can be surprised by how expensive things get which is where tiered licensing comes in.
• Tiered license: Most commonly the “freemium” pricing model or “free/select/premium” offering. For developers this is great because it allows them to try something out before committing. The delicacy is deciding what features get baked into the premium offering and if that price is worth it to the customer. Usually premium gets rolled into the subscription model.
• Subscription model: An API provider can offer access to a service for a weekly/monthly/yearly rate regardless of usage or up to a certain limit. Usually the length of time committed to and any amount paid up front offers a discount.
• Per Unit of Infrastructure: Consider auto-scale pricing here. For an API provider perhaps it equates to the amount of data stored or processed. Now that microservices are a thing this could be thought of as “duration” or time of compute usage.
• Per Unit: Also known as the ‘per seat’ model in software. For APIs this could mean number of keys or developer licenses. It’s not uncommon to see numerous developers use one license or key though there are ways to prevent this.
• Revenue Share: One scenario for API revenue share is “company X that uses your API generates Z revenue. They will give you the API provider a % of Z”. It’s also been used as a “we’ll provide Y company with a certain amount of free usage or space for a % of revenue or stake in a company.” Usually only large organizations offer this type of strategy, but that’s not to say it’s not an option.
• Costs Savings: Flat “use more get a discount.” For example, here’s Twilio’s pricing model which is a mix of pay-as-you-go, subscription, and cost savings. We would imagine for their enterprise deals looking like a tiered license might occur. Also, check out Lambda’s pricing. There’s tiered pricing, per unit of infrastructure, or duration, pay-as-you-go by the millions. Whatever method you choose, consider mixing things up with a couple different monetization methods. There are a few other great examples here as well as here.

Open-Source Options

One thing that is unique to a technology offering that other products can’t offer is an open-source model. For instance, open-source strategies can be about driving users to pay for another product or premium subscription. It can be about offering something risk-free and up-selling with services or support. Open-source also offers the benefit of including other developers mindshare into improving the overall quality of a product.

What Are You Selling?

Before deciding on which flavor of pricing you choose it’s important to consider the end-goal of your API program and how it integrates into your key business strategy. There are certainly other ways to measure the value of your data when exposing an API, but here are a few strategies we can see today:

• Awareness: Offering an API can provide a way for a company to gain awareness it wouldn’t otherwise have.
• Content: For content providers APIs offer ways to integrate with new partners and open new to syndicate content and extend audience reach.
• Problem solving: Great APIs solve problems. Companies are built around this strategy of helping developers.
• Improving the core product: There are plenty of free products offering easy integration that track user data. By giving away an API for free (and providing a terms of usage) you can find out more about your users and improve the product.
• Adoption: When a developer builds a net new application integrating your API you now have their users as well. By offering easy ways to work with your API and working to ensure the success of your developers you increase the chances of adoption and usage of your API.
• Stickiness: When an application can offer your APIs features into their system, users can find more use in their product and return more often.

It’s Not All About Money

As you can see above, the value of APIs aren’t solely in revenue generation.  Being able to show success in new users and business opportunities, improvements to another product, more integrations, and opening new channels are just a few ways other than revenue that can make APIs vital to your organization.

Having your strategy aligned with your overall business and getting executive buy-in is definitely a critical part of success. Regardless of the pricing model, APIs certainly offer new routes to market and can be a critical piece to the overall success of a company.