What’s the Best Way to Determine the Price of an API?
As an API provider, once you’ve decided to bring in revenue from your APIs, the next step is to figure out how you will price the usage. As with any business decision, there are plenty of ways to go about pricing an API. There are many short-term strategies to establish initial pricing and then iterate to find which pricing model and price points work best for your customers. Long term, there are also steps that can be taken to ensure your pricing stays relevant and balances retention and revenue.
In this article, we will take a deep dive into all the relevant questions when it comes to API pricing. I will aim to give you some points to think on as well as some best practices. Hopefully, by the end of the article, you will have a better understanding of API pricing and how you can apply the techniques below to your organization’s monetized APIs. Lastly, we will take a look at how Moesif can help you to figure out what APIs to monetize, how to price them, and how to actually charge users for usage. Let’s jump in!
How does API pricing work?
API pricing, as with most product pricing, consists of two major questions: What metric will be charged upon, and what pricing model will be implemented? For example, you may choose to bill upon every single API call and charge a set price per call. You may also involve a discounted rate per call when usage exceeds a certain amount. Maybe you’ll decide to just charge per user or the API key used to access the APIs.
Each company may have a different metric that they would like to bill upon and different pricing models they may want to implement. These choices are all very dependent on the APIs you are monetizing and the needs of your business.
What are common metrics to charge upon?
There are an infinite number of metrics that one could charge upon. Generally, though, there are a few common scenarios that come to mind. Here are a few of the most common metrics used to measure API usage:
Per event
This metric is applied to every call that comes into your API. Each call is tallied up and counted towards the total for the billing period. An example may be if you want to charge $0.10 per API call. If a user calls the API 5 times, they will receive $0.50 in charges on their bill. This metric is one of the most popular to start with as it is easiest to implement.
Per request/response body count
In some cases, you may want to count the number of elements in an API request or response body. This is great if you want to charge users based on the payload going into or out of the API. An example would be if we wanted to charge $0.10 per element in a request body (since each element will be processed by our service). In this case, if a developer sends a request with 3 elements to be processed in the request body, they would be charged $0.30 for their API call.
Per unique user
This metric works well when you want to charge for usage based on a unique user accessing the API. Unlike using API keys, where a user may have several, instead, you charge at the user level. An example would be if you wanted to charge $10 per user, per month. In this case, regardless of how many API keys a user is using, possibly one per environment or app, they will only be charged $10 for access to the platform’s APIs.
Per API key
Similar to per unique user, the charge would be based on the number of unique API keys used to access the API. At the end of the billing period, the total API key usage would be added up and billed for. An example would be if there was a cost of $5 per API key per month. In this case, if a developer has 3 API keys they have used to access the API then they would be charged $15 for usage that month.
On top of the metrics discussed here, there are plenty of others. Some of these may offer a good place to start and as you expand, you may find that measuring more complex metrics is required to fit your future use cases.
What pricing models can be implemented?
Pricing models vary widely, although there are some staples that many companies use. Let’s quickly check out some of the more standard pricing models that could be used when charging for API usage below.
Standard pricing
This pricing model can be used when you want to charge the same price for each API call or for each unique user. Essentially, every unit of usage that is recorded will be charged at the same price point. This is the simplest pricing model in existence and may be a great place to start if you don’t want to get too complex off the hop.
Package
This pricing model can be used when you want to charge for API usage by the package, or a group of units. For example, you could set it up to charge $10 for every 1000 API calls. Every time users go over the 1000 API call threshold, they are charged another $10.
Graduated
A graduated pricing works if you want to use pricing tiers to charge for usage. For example, in a graduated pricing scheme, you might charge $10.00 per unit for the first 100 units and then $5.00 per unit for the next 50.
Volume
Using volume-based pricing can be used to charge the same price for each unit based on the total number of units sold. For example, you might charge $10.00 per unit for 50 units or $7.00 per unit for 100 units. At the end of the billing period, usage is totaled up and the overall volume of usage will determine the price applied to each unit of usage.
Of course, this is not an exhaustive list. Depending on the customer or product, you may also use different pricing models for each. Choosing the pricing model which makes the most sense for your specific API should balance driving customer usage while still making sure revenue is maximized.
What’s the best way to determine the price of an API?
Once you’ve decided on the metrics and pricing model, you’ll then have to determine what you will charge customers. This, of course, can be quite complex depending on factors such as what metric and pricing model you are using. The recommendations below are meant to guide you on some important considerations when thinking about the price of your API.
Calculating the cost of your API for your business
One thing you need to take into consideration is the cost of your API to your business. This cost could be the ongoing support costs, development cost for new features, or even third-party APIs or services that your API leverages that add to the cost.
The easiest cost to determine is other services that your API uses and the costs associated with them. The goal should be to at least cover these costs that will directly cause an expense for your business. You may factor in third-party API costs, maybe other services that your API leverages to provide its functionality, or maybe even your infrastructure costs if API call volume will make the cost increase or decrease.
Creating a product will also cost time and dollars for support and ongoing engineering effort. This should also be calculated into the cost of ownership for your APIs. This is especially true if the resources used for support and maintenance are spending the majority of their time working on the monetized API. Figuring out the base cost, or total cost of ownership, of the API, can help to give you an idea of where your price should start.
How much value are you adding through your API?
Is your API bringing a lot of value to potential users? For instance, the value may come in many different forms but the one that most frequently comes to mind is how much savings a company is getting from using your API. The savings generally come in the form of how much it would cost for them to develop a similar service in-house. If the service would take them 2 days to create and deploy, maybe you’ll need to add a bit more depth to your product in order to extract a high dollar amount for usage. On the other hand, if it would take months and a massive budget for them to build what you’ve already created then you may be in a very good position.
It may be hard to quantify the exact value but you should have a good idea of what it takes to build an equivalent service in-house and how much companies may be willing to pay in order to use your service versus building their own. Another way to measure value maybe if you are offering a service through your API that is outside of the expertise of your potential market. This means they would likely need to hire an entire suite of staff just to create what you already have available. Use the value you’re adding to give a range for your pricing and eventually determine the price for your API.
What pricing model should you use?
Generally, you have two big decisions on this front: will you charge a subscription fee or will you charge based on actual usage? Both come with pros and cons, as well as ways to somewhat combine both paradigms. For instance, you may charge a subscription fee that allows for 1000 API calls per month and then charge for usage overages in the form of overage fees. If you go decide to charge on overages, on top of the pricing model you will also want to think about your overage model as well.
Once you’ve determined the higher-level pricing question above, you can then decide if you will implement any volume-based pricing, tiered pricing, and other potential pricing schemes available. Some companies strive to offer simple pricing strategies while others have a huge amount of flexibility and options. Based on your customers, and potentially looking at other products that they may be using, you can probably get a feel for which pricing model makes the most sense.
Should you be factoring in SLA and support into the cost of usage?
On top of charging for usage, some companies also charge a premium for different levels of support. This could be another way to drive revenue for your APIs that can be factored into the overall price you charge customers. You may still charge for your API based on a strict pricing scheme but charge for upgrades such as an improved support package for companies that require such an agreement.
Keep testing your price points
Your price points don’t have to be set in stone forever. As with most products and services, over time, the cost tends to increase. Customers generally expect an increase at some point and as long as the value is still being delivered in an equivalent or exceeding manner, they won’t churn out due to cost.
When should you assess your current pricing model?
The answer to this question is heavily dependent on your business model. If you are doing month-to-month or pay-for-usage type models, price points can technically be changed at any time. Obviously, you want to make sure customers are aware to shield yourself from any blowback and give customers a chance to adjust to new rates. However, if you have an annually-paid enterprise plan or more strict time-based contracts, you’ll likely only be able to increase the price upon renewal.
It’s always good to be assessing your prices against your competitors as well. If your service is more expensive, you may want to dig hard into differentiators and push from that side to ensure you are showing the value of the cost to consumers.
Overall, pricing should be assessed and revisited frequently. This should include looking at how much you charge, what pricing models are available to customers, and if new features warrant a price increase across the entire pricing scheme or if new packages or add-ons should be added to purchase options.
What’s the best way to roll out pricing changes?
The best way to roll out pricing changes is to make sure that you have accurate feedback loops set in place. When a price changes you want to have monitoring in place so that customer success and sales teams can try and bring back any customers who churn out. This is more of a reactive approach and not every customer will come back, some may be afraid of further price hikes in the future.
You also want to make sure that any price changes are well communicated. If a customer is coming up for renewal, start negotiations early. If customers are paying monthly by credit card, try and let them know well in advance before the next billing cycle starts so they aren’t surprised. One thing to be careful of is not over communicating the “why” of the price change. You can state something simple about new features, improved SLAs, or another high-level value add that justifies the increase. However, by listing out all of the features you’ve improved, it may give customers a chance to say “I don’t use that so why am I paying for it?” and other possible objections to price increases.
Lastly, you may also add a question on price to customer surveys to check if they are happy with the current price or if they think it is too high or low. Asking a customer “What is the upper limit of what you would pay for our service?” is actually a great way to see the perceived value for the customer and to test what the upper limits might be without experimenting with your live prices.
Free trial, free tier, or nothing?
Assessing your trial period pricing is something you may also play around with. If you have a free trial, playing around with the length of it may drive more paying customers as well. You may find that your free tier is “too good” and many customers stay on it. This prevents customers from jumping to a paid plan since the free plan already covers everything they require. Maybe scrapping any trial at all is in favor of your business?
As much as trials can be a major driver of adoption, assessing how your trial period perks are working for you and your customers is part of the pricing strategy. If you do play around with the trial offerings within your product, make sure to have heavy analytics input so that you can track the true value of the changes.
Using Moesif for conversion analysis and billing
With Moesif, using API analytics to help figure out which APIs to monetize and what price to charge becomes a more precise science. Of course, you could guess around all of these factors and through trial and error, find what works. This comes with a great amount of risk and wasted opportunity to drive more revenue from the start.
Using the Moesif platform can help you with finding the right price for your API, navigate price changes, and optimize onboarding. The platform can easily be integrated through your existing API code using an SDK or through your API gateway by leveraging one of our plugins.
Researching API usage for API endpoints to monetize
Are you familiar with what APIs are receiving the most traffic? Do you know what companies that traffic is coming from? By asking and answering key questions in your API usage, you can quickly determine which endpoints to monetize. You may even be able to accurately predict revenue for when the API does become monetized. Moesif can help to generate reports that show API usage in ways you may have never looked at before.
A bar chart from Moesif demonstrating where each customer’s users generated the greatest number of API events
By using Moesif to dig deep into your API usage, you can uncover the answers to many questions which can help to determine the value of an API and potentially how much to charge for it. After you’ve implemented monetization, these reports can help you to see revenue at the user and company level to drive long-term organizational goals and inform your API product roadmap.
User funnels and retention
A user funnel report from Moesif, showing the percentage of users completing three phases of integration
After you’ve implemented or changed your pricing, you’ll want to make sure customers are still converting to paid customers. This can be tracked with a user funnel in Moesif. The user funnel will allow you to outline each step in your conversion funnel and see what percentage of users convert throughout each step and how long it takes.
API retention chart showing which users used which language at different stages of integration. Languages include node.js, python, go, ruby, php
Retaining customers is also important, especially after a price change. With a retention report, you can see the historical retention rate of your product and ensure that recent changes in pricing strategy are benefiting your business and not driving down retention rates.
Billing Meters
Flowchart showing data moving from your app or API to Moesif, and then to payment processors Recurly, Stripe, or Chargebee
Moesif can also help with implementing monetization on your APIs as well. By using Billing Meters, you can establish which endpoints you’d like to monetize and the pricing model, and send the usage totals to a billing provider such as Stripe, Recurly, or Chargebee. Moesif’s Billing Meters give end-to-end monetization capabilities with minimal engineering effort. If you need a solution to monetize your APIs easily, securely, and quickly then Moesif’s Billing Meter feature is exactly what you need.
Wrapping Up
The pricing plan that works best for your business will always need to be tailored. Pricing API calls can be extremely tough to do, but following the guidelines above can help you find ways to make it easier and more precise. Making sure that any endpoint you decide to monetize is bringing value to developers and their organizations can be a win-win scenario for your business and theirs.
Using Moesif can help with many aspects of API monetization including helping you make informed pricing decisions, figuring out what endpoints to monetize, and tracking customer retention throughout the process. To get started, sign up today and try Moesif’s API analytics and monetization features for yourself.
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.
