Best Practices for Usage-based Billing to Monetize APIs
Why monetize APIs?
For many enterprise products, revenue is driven through a subscription to the SaaS, such as number of seats or a yearly license. Subscription-based pricing models are perfect for UI-driven workflows, but they are not suitable for automation and AI-driven workflows.
Because of this, APIs are rapidly becoming the de facto interface to use another company’s products. Customers looking to leverage targeted solutions that fit their specific use case, rather than a one-size fits all UI. As an API provider, you likely already have lots of APIs being used to power your internal platform. The next evolutionary step is to expose these APIs to customers and partners for direct revenue generation. Any engineering platform can be very expensive to maintain. In today’s market, efficiency is critical. By directly monetizing your APIs, your highest cost center turns into a revenue center for the company. This fuels further investment into your APIs and products so they are best in class.
Challenge of selling APIs
However, selling an API is not easy. As companies transitioned from on-prem to SaaS, buying power has shifted away from CIO to team managers. With the transition from SaaS to APIs, this trend has accelerated empowering individual developers with tremendous amounts of buying authority. An individual developer can perform research and decide on a set of APIs that fit his/her use case. Yet, no single developer will deploy an app or integration to production in silo. There are many stakeholders that can weigh in or veto a decision to purchase and consume the API product.
Even if your proposed economic buyer of your API solution is not part of engineering, APIs are deeply technical in nature and require extensive input from different engineering teams which can create a complex process for selling an API. As part of any procurement process, you’ll need to win over software architects, security engineers, legal teams, and product managers, each who can weigh in or veto a decision to purchase an API product.
Land developers first
Instead of trying to win over every stakeholder with a complex, top-down sales process, start by landing developers first with a self-serve onboarding experience. This doesn’t mean you forego the sales team, but what you’re doing is getting developers to start seeing value in the API and advocate to their leadership team before they engage with your sales team. This process is commonly called developer-first adoption or product-led growth. Your goal is to get a developer to pay a token amount on a credit card such as $50/month. They should be able to do this quickly on their own time. Procurement is not involved for this stage so the subscription can simply be placed on a manager’s credit card.
Sell through developers
Once your customer is already paying on a self-service plan and meets certain usage criteria, your sales team can become engaged. Because the customer already saw initial value in the API, the sales team takes a consultive approach such that the discussion becomes more of an “upsell” discussion. Sales guides the customer on how to gain more value out of the API or navigate certain business requirements the customer may have. A customer may consider upgrading due to increased usage, new use cases, or have advanced requirements.
This means your sales team should understand a customer’s usage to identify when to engage a customer in a sales process. In order to do this, you should set up an API analytics tool which can track the API usage for each customer through an account-based dashboard. This provides a single pane of glass into each customer’s and pilot usage for sales and customer success. It’s recommended to set up automatic notifications such as through Slack, when a customer’s usage trend changes. For example, when an account’s API usage increased by more than 10% week-over-week, then they may be ready for a sales discussion. Other indicators include inviting additional team members to their subscription or utilizing additional APIs that they were not using before.
Choosing the consumption metric
With usage-based pricing, it’s important to choose the right metric to charge for and bill on so that it’s correlated with the business value received. Simply charging for every API call is likely a poor choice since some APIs provide no value (such as status probes), they may error out, return no results, etc. Similarly, you might offer both a batch and non-batch API. If you’re building an SMS API offering, then a single API call that sends 100 SMS messages as a batch and then transcribes them to create a larger amount of value for the customer than an API call that sends just a single SMS message. In this case, billing based on the number of SMS sent would be a better metric than billing on the number of API calls.
As a secondary example, let’s say your API handles sending marketing emails, but also provides the ability to store email templates in the platform. If you bill based on the number of templates stored, that might be a bad metric as it’s unlikely a customer receives value simply by storing additional templates in the tool. If the customer drafted a massively large number of email templates but never sent a single email through the API, their bill would still be large. On the other hand, customers will do weird behaviors like consistently deleting old email templates after it’s sent even though it would have been better to keep the email template in the tool. In this case, customers get value by automating the process of sending marketing emails. Thus, a better metric aligned to customer value would be a number of unique contacts emailed per month or number of emails sent per month.
Common value metrics
| Name | Example | When to use | Example Company |
|---|---|---|---|
| Transaction volume | # of Events ingested, # of Messages Sent | APIs and event-based platforms such as SMS and analytics | Sinch |
| Revenue/cost share | % of revenue, transaction fee | Platforms focused on money such as payments or expense reporting | Stripe |
| Data volume | Gigabytes sent, Minutes made | Platforms focused on data such as logging or storage | Datadog |
| User-centric | Monthly unique users that are active | A modern version of charging per seat or per user | Segment |
| Resource | Compute Units, active hours | Compute infrastructure such as a database or virtual machine | AWS Redshift |
Ensure the API creates business
Even once you’re able to get developers to use the API, this doesn’t necessarily mean the API creates business value. Developers may adopt an API just to experiment with a new technology, create a hobbyist project, pick up new skills, etc. However, businesses don’t care about a simple “Hello World” API. Instead, businesses are purchasing an API because they see it adding value to the organization. When it comes to business value, the three types include:
- Reduce cost or time (vs a homegrown solution).
- Unlock additional revenue for the organization.
- Reduce risk for the organization.
Pricing and Packaging
If you’re selling your API, there are many ways to package it depending on your business goals. Due to their transactional nature, many APIs enjoy an usage-based billing model (also called Pay As You Go or consumption-based billing) to unlock revenue growth, but there are many different approaches you can take. Areas that you should consider in your pricing strategy include:
- Billing
- Packaging
- Invoicing
1. Billing Strategy
Billing strategy impacts adoption and customer activation the most and is usually driven by the product department. Prepaid billing is when a customer pays for a service upfront before it’s consumed. On the other hand, postpaid billing is when a customer pays after the services are already consumed.
Prepaid billing
Prepaid is a common billing model especially for traditional SaaS and enterprise software companies. Because the API provider gets cash upfront before any services are rendered, prepaid models can drastically increase cash flow for the business as you’re getting customers to commit and help finance your R&D. This is especially important if your acquisition or setup costs are high which allows you to invest further into product and growth. Prepaid is also beneficial for customers as they know what they are committing to upfront which can provide more spend predictability. Because usage amounts are unknown before payment is made, you can handle usage-based billing through a committed spend. This might include volume discounting. However, prepaid might force a customer to do mathematical estimates before they have real world data.
Postpaid billing
On the other hand, postpaid is where you’re extending credit to your customers as they use your platform until they pay. Postpaid can reduce onboarding friction since a customer doesn’t need to estimate how much they need. Instead, they can just enter their credit card and deal with the bill later and see how much the damage was (like dining at a restaurant or bar). Postpaid billing has been popularized by consumption-based models like the digital advertising industry, and more recently the cloud industry. A benefit of postpaid is a customer does not need to commit ahead of time before any value is seen.
However, there is a downside. Because you’re extending credit, it can be abused by customers depending on your offering (like a dine and dash scenario). Having good safeguards and limits is important to ensure a customer doesn’t accumulate “too much credit”, before they purchase. Postpaid can also have higher cancellation rates. A customer could use much more of an expensive service than expected and then have regrets.
| Prepaid Billing | Postpaid Billing | |
|---|---|---|
| Description | Customer purchase credits / quota ahead of time that is then later consumed | Customer only pays for their usage after it’s consumed |
| Pros |
|
|
| Cons |
|
|
2. Packaging Strategy
Packaging strategy impacts initial contract value and expansion revenue the most. Because not every customer will receive the same value and pay for the same amount, packaging refers to how your different SKUs and offerings are presented to a customer. You might use different features or usage components to enable customer segmentation.
Tiered pricing is a packaging technique common within SaaS to create a “good”, “better” and “best” plan, each with a predefined set of features and quotas. Pay As You Go (PAYG) is another packaging technique also called usage-based pricing or consumption based-pricing where a customer purchases a quantity or volume such as number of API transactions. PAYG can be a revenue accelerant for developer-first or product-first organizations.
Tiered pricing
Classic tiered pricing makes it easy for customers to understand their cost and makes pricing more predictable, a plus for large companies purchasing software. It’s common and well understood within the SaaS industry reducing complexities around billing. In addition, it’s super easy to implement. You don’t need any metering or analytics to track usage. You can just implement a subscription billing software.
The issue with tiered pricing is the disconnect between price and perceived value. As a customer comes close to the limits of their plan, they naturally should upgrade their plan. However, the price jump to the next plan can be significant which can cause scenarios where the customer “doesn’t feel ready” for the next tier. This can be exaggerated if the tiering utilizes too many variables. It’s uncommon a customer will exceed all limits of a plan and will instead exceed only one quota limit. However, the next plan has “too many extra items” that the customer doesn’t need (such as additional features). Similarly, you don’t want more than three or four tiers. If you have too many, it creates analysis paralysis
Pay As You Go (PAYG) pricing
Because of these issues with tiered pricing, a more modern approach is being utilized where customers pay for their usage. Consumers have utilized physically metered plans for quite sometime like gas and electric utilities. This concept of metering can be applied to digital products that have a usage-based component. Common things to meter on include transaction volume, gigabytes sent, or unique users.
A benefit of usage-based pricing is the price to perceived value gap is significantly reduced as customers only pay for what they need. PAYG is a great accelerant for product-led growth or developer-first businesses. You can design a self-service plan that “hooks in customers”, and then allow them to grow their usage over time. In other words, your pricing model has built-in expansion revenue. However, PAYG can be challenging without knowing what is going on in terms of customer usage levels.
| Tiered | Pay As You Go (PAYG) | |
|---|---|---|
| Description | Traditional SaaS tiers with predefined set of features and quota. | Usage-based or consumption-based pricing based on a unit price. |
| Pros |
|
|
| Cons |
|
|
3. Invoicing Strategy
Invoicing strategy impacts cash flow and typically is driven by the financial team the most. Once you decide on a billing model and how your offering is packaged, you’ll want to determine when invoices are triggered and generated. Unlike billing and packaging which have impact on product and expansion revenue, invoicing strategy has a larger impact on unit economics. With recurring invoicing, you invoice the customer on a schedule such as per month or per year. On the other hand, you can also invoice customers once customers reach a threshold such as when they reach a certain quota or outstanding spend. This type of invoicing is called threshold-based invoicing.
Recurring invoicing
Recurring invoicing is the more popular of the two and easy for customers to understand. You can invoice them in a prepaid way (which is usually a fixed price) or send a bill for what the customer’s usage was for the prior billing period. For buyers of enterprise software, recurring invoicing is usually preferred as it’s predictable and easier to plan for. There are a couple of downsides, which usually come up with extreme Pay As You Go models. If you have some customers with extremely low volumes where they are paying only a few pennies or dollars per month, the transaction fees will exceed the cost of service. Similarly, if a customer can quickly rack up a lot of credit within a billing period or the value received is very transactional, this could create a large accounts receivable balance in between billing periods even though the service has since been rendered. This is common in the digital advertising industry where large spends can accumulate quickly.
Threshold-based invoicing
In order to combat the poor unit economics of recurring invoicing, threshold-based invoicing can be leveraged. With threshold-based, the invoice is not generated until a certain threshold is reached. If prepaid, this means a customer is purchasing credits which can then be used (which might be far in the future). If postpaid, the invoice is generated after a threshold is reached such as $1,000 in ad spend. This ensures you only have up to $1,000 outstanding for a customer at a time regardless of their monthly spend. Threshold-based pricing is not without downsides. It can heavily complicate accounting since the spend is not predictable and not exactly aligned to a billing period like quarterly or yearly. The time could be open ended and not well defined.
| Recurring | Threshold | |
|---|---|---|
| Description | Customer invoiced on a schedule like each month, quarter, or year | Customer invoiced only after a credit threshold is met (can be prepaid also) |
| Pros |
|
|
| Cons |
|
|
Implementing usage-based pricing
Implementing usage-based billing introduces additional complexities beyond typical tiered pricing. You need an accurate mechanism to meter customer usage in a reliable way, and do it at scale. The usage must be auditable and can be relied on to settle disputes. Unlike a logging or monitoring tool, this data must be accurate. You don’t want a scenario where you thought the customer used X, but they have proof stating otherwise.
You can build your own data warehousing on a platform like Snowflake or you can use a purpose-built usage-based billing product for APIs like Moesif. This solution connects to your API gateway of choice like Kong or Tyk and then integrate it with a billing provider like Stripe so yiy can easily set up metering rules. For a detailed tutorial on how to do this with Kong and Stripe, check out the End-to-end API Monetization with Kong, Stripe, and Moesif. The sample project is also available on GitHub
Pitfalls of usage-based billing after release
Beyond just implementing a data pipeline to handle usage-based pricing, there are a number of other challenges that come up especially in managing customer expectations. A common problem are customers who blow through the usage far quicker than anticipated creating a large bill they did not expect to receive. This can be especially true in APIs and tools that have a data volume component.
It’s important to reach out to customers to keep them informed of this. One way to achieve this is via automated emails that warn customers of their usage once certain predefined thresholds are met. In this case, even though the quota is not a hard limit, you’re letting the customer know how much they used for the month.
It’s also helpful to give customers some control around these thresholds. No one wants to receive 10 emails a month on their usage even though it’s a predictable bill. Providing a UI for customers to adjust those thresholds can help ensure they get alerted only when needed.
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.
