Pricing APIs correctly is a key part of your API monetization strategy. That means understanding how you should charge for usage, whether it’s better to set your pricing by month or quarter, whether data tiers or a Pay As You Go API pricing model would work best and a whole host of other elements. In this post we’ll cover all you need to know when pricing APIs.
At the most basic level it’s important to ask who actually pays for an API. When you monetize your APIs, you do so by charging the end user – the company that’s utilizing your API to provide business value. So, by understanding the value that your API provides, you’ll be better able to build a favorable pricing strategy.
One of the founding principles when treating your API as a Product is to understand your customer. By seeing how they use your product you’ll not only be better able to price your service, but it’ll also give you indispensable insights into what’s working, what’s not and what should be on your roadmap. For more information on treating APIs as Products check out our extensive library.
There are several ways to determine what your API is worth. Charging by number of API calls is one common pricing metric, but it’s certainly not the only option when it comes to your pricing model. Different usage-based billing approaches to consider when mapping out your API strategy include:
- Transaction volume – based on the number of API calls. It’s ideal for APIs and event-based platforms, such as in communications Twilio or Moesif.
- Revenue/cost share – you charge the end user a percentage of revenue or transaction fees. This is well suited to financial platforms, such as those focused on payments Stripe or expense reporting.
- Data volume – based on gigabytes sent or minutes processed. This is a good approach for platforms focused on data, such as logging or storage AWS.
- User-centric – pricing based on the number of active monthly unique users. It’s a modern version of charging per user, or per seat. Resource – based on compute units or active hours. Ideal for a compute infrastructure such as a database or virtual machine.
The product that you’re offering will play a key role in your pricing strategy. There’s much to be learned from the SaaS price point approach, as many API pricing strategies have their roots in broader SaaS pricing solutions. Leading thinking on SaaS pricing emphasizes the need to set prices based on three main factors: the cost of delivering your product, your competitors’ pricing and your value metrics. That is, how your customers will be paying. Obtaining feedback from your first paying customers is also key, as they’ll have plenty of thoughts on which pricing models will and won’t work for them.
External-facing APIs, ones that are available to other companies outside your organization, are often charged for. Internal APIs, which you might use to interconnect different services within your organization, are not usually charged for, and thus don’t require a pricing strategy.
The pay as you go billing model means that customers pay only for what they consume. That could be measured by a range of metrics, such as number of messages sent. This consumption-based pricing model is well suited to APIs, which are naturally transaction-based.
With pay as you go API billing, you choose which metrics to charge on, based on your customers’ usage. You can also implement volume discounts, depending on how you monetize your API.
The pay as you go model is easy to implement, which makes it a popular choice for many companies devising their first API monetization strategy. An example cloud architecture illustrates the simplicity of such an implementation.
From your customers’ perspective, pay as you go billing is cheap to implement. However, it can be more expensive for them in the long run if usage is not capped. You’ll also need to implement a system that alerts your users around quota limits, to avoid them receiving surprise bills. Such a system will work to your credit, as it will avoid surprise bills prompting your customers to shop around for cheaper alternatives.
There are many different ways to calculate how you bill for your APIs. This is where Moesif really shines, as our platform can bill based on any parameter in your API. It means you can shape your API monetization strategy around your customers’ precise requirements. If you’ve decided on usage-based billing, possible consumption metrics include number of API calls, gigabytes sent, minutes made, monthly active users, active hours and many more.
Another key question, irrespective of pricing strategy is how much your API can generate. APIs are a subset of SaaS and have proven time and time again to be capable of scaling at hypergrowth speeds.
Charting the rapid rise of the two poster-children for API success, Twilio and Stripe, is instructive. Both companies are based around an API-first model - providing their services over an API. After launching its product in 2011, Stripe’s revenue grew from $40M in 2016 to $450M 18 months later, and to $7B in 2020. Similarly, Twilio grew from $50M in revenue in 2013 to almost $3B by 2021.
If you have the option of offering an API product or an enterprise software solution, then this decision will have a material impact on how quickly you’ll generate revenue. One strategy is to focus on offering just your API to end users. It means you can get to market faster and focus all of your engineering talent on the business logic that the API provides. Opposingly, if you’re thinking of building an enterprise software solution you’ll also need to invest in creating a frontend. By focusing all of your resources on your differentiated business features, you may be able to charge more for your solution.
When developing a tiered pricing model, it’s up to you to decide price points and package your tiers accordingly. It’s become increasingly common to adopt a “Freemium” pricing strategy, where the starter tier is free and the latter tiers are paid. In Moesif’s case, we have four tiers: Free, Grow, Pro and Enterprise.
As we mentioned when discussing tiered pricing in a recent article, there are tradeoffs between transactional and tiered product pricing models. If you’re using the tiered approach, you’ll need to define which features and usage quotas are included in each tier. You’ll also need to address customers’ primary concern with this model:
Using Moesif as an example, each tier defines usage, number of users and features. If a customer needs more, they have the option to move up to the next tier as part of their planned growth. It’s a simple model that makes it easy for the customer to budget and administer, so certainly one to consider as part of your API pricing strategy.
The other benefit of tiered pricing, as you can see from the Moesif model, is that you can introduce premium elements. What is a premium API business model? It’s one where top-tier customers benefit from certain features that aren’t available on any other tier. In Moesif’s case, premium extensions include the ability to sync API usage data to on-premise warehouses, Salesforce integration, MarTech tools and more. The premium API elements that you can offer will be based on your unique business model.
The final element of pricing APIs relates to the value that your product delivers. Ask yourself: does this API address a unique need? If it does, then you have greater freedom in terms of pricing than if your API serves a need that many competitors’ APIs also address.
Ease of use also comes into play, so you’ll also need to consider how accessible your API is. Is it a REST API or another format? Is it a web API that’s based in the cloud or does it run on premises? Will users need an API key and, if so, is the process of obtaining it frictionless?
Essentially, the easier you make it for customers to access your API, the better. The Vermont Legislature API, for example, uses HTTP basic auth for authentication, with users having to email the Vermont Legislature to obtain the API key. This introduces an element of friction and delay, as the would-be user has to wait for a reply to their email before they can use it. Remember: customers will be happier to pay for an API that’s easy to use than an API that causes them headaches.
A couple of final points to consider are how to name your APIs correctly, which should be factored into your design decisions, and how to address your API security. What does API security entail? That’s a huge topic all in itself. Once you have developed your API pricing strategy, check out our API security features to ensure you’re doing all you can to reduce your own security risk and that of your customers.
Factoring all of the above into your API pricing strategy means that you’ll be well positioned to monetize your products effectively. The earlier you think about monetization, the better.
Take the plunge today. Try out our monetization solution and put into practice all you’ve learnt herein.