API Monetization Models for Usage-Based Billing

Why Monetize APIs?

API monetization is a great way to recoup your investment in your API programs. Without direct monetization, you’re dependent on other sources of capital to grow the program, such as other profit centers or venture capital.

If you’re not directly monetizing your APIs, you could be leaving money on the table. This can be especially true if you don’t have any limits in place and lean on the honor system.

Challenge of Selling APIs

When it comes to monetization, there are two sets of challenges to be aware of: engineering challenges and business challenges. This guide will touch on both, but the main discussion of this article is on business challenges, which revolve around go-to-market (GTM) strategy and finance.

Business Challenges Selling an API

Selling to developers is hard, which complicates API monetization strategies. Even if the 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. As part of any procurement process, you’ll need to appeal to software architects, security engineers, legal teams, and product managers, each of who can weigh in or veto a decision to purchase an API product.

Land Developers First

Rather than trying to appeal to every stakeholder, instead, focus on the developers doing the integration. Sometimes called developer-first or bottoms up, the goal is to drive developers to integrate and pay a token amount for the API, even if it’s only 50 bucks or so per month. By doing so, you remove many of the blockers to purchase. For example, instead of requiring extensive security and legal review, an individual developer can just click through standard Terms of Service. Procurement is not involved, as the subscription can simply be placed on a manager’s credit card.

Sell Through Developers

Only once your customer is already paying on a self-service plan and reaches certain goals or volumes, sales can get engaged. An organization may consider upgrading because they have increased usage or may have advanced requirements. This only happens after the developers already saw value in the API and how it can fit his or her company’s needs.

Capture Expansion Revenue

Because self-service and developer-first are phenomenal strategies for getting API monetization off the ground, it’s common to implement some sort of usage-based billing model for pricing. However, there are different levers you can tweak on your pricing model which is dependent on your specific business to capture “your fair share” of the value a customer receives.

• Prepaid vs Postpaid billing
• Tiered vs Pay As You Go (PAYG)
• When to invoice
• Level of support/functionality

1. Billing: Prepaid vs Postpaid

Prepaid billing is when you pay for a service upfront before it’s consumed. On the other hand, postpaid billing is when you pay after the services are already consumed.

Prepaid Billing

Prepaid is the most common model for traditional SaaS and enterprise software companies. Because the provider gets cash upfront before any services are rendered, prepaid models can be a lifesaver for the business which can increase cash flow. 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 it provides spend predictability and reduces the processes involved in procurement. A software buyer only needs to go through procurement once a year and ensure they already have a budget.

Postpaid Billing

On the other hand, postpaid is a different model where you’re extending credit to your customers as they use your platform until they pay. Postpaid can simplify consumption-based business models since a customer doesn’t need to “guess” how much they will consume. 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). Because of these benefits, postpaid billing has been popularized by consumption-based models like the digital advertising industry, and more recently the cloud industry.

However, there is a downside to postpaid. 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 extra cancellations. A customer could use much more of an expensive service than expected and then have regrets.                                 

2. Packaging: Tiered vs Pay-As-You-Go (PAYG)

Related to prepaid and postpaid billing is how your service is packaged. Tiered pricing is a packaging technique common within SaaS to create a “good”, “better” and “best” plan. Customers can choose the plan they need based on a predetermined set of criteria. On the other hand, Pay As You Go (PAYG), also called usage-based pricing or consumption based-pricing based on a volume metric.

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 like Recurly, Stripe, or Chargebee.

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 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 different variables. It’s uncommon that a customer will exceed all limits of a plan and will instead exceed only one limit. However, the next plan has “too many extra items” that the customer doesn’t care about (such as additional features). At the same time, you don’t want more than three or four tiers. If you have too many, it creates decision 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 some time, like gas and electric utilities. This concept of metering can be applied to digital products that have a usage component. Common things to meter include transaction volume, gigabytes sent, or unique users.

A benefit of usage-based pricing is that 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.                                                          

Choosing the Consumption Metric

With usage-based pricing, it’s important to choose the right metric to meter and ensure it’s roughly correlated with the value a customer receives from the platform while preventing weird behaviors that create an unusual experience.

For example, let’s say your SaaS or API is an email marketing tool for sales and marketing. Choosing to meter on the number of sequences or campaigns stored would be a bad metric, as the customer does not receive value by storing additional campaigns or sequences in the tool. Instead, customers would get large bills if they drafted a significant number of new campaigns even though they never sent a single email through the tool. On the other hand, customers will do weird behaviors like consistently deleting the sequence after it’s sent even though it would have been better to keep the sequence stored in order to track historical metrics with the tool.

Customers get value by reaching out to prospective or existing customers, not whether a sequence is stored in a tool. Thus, a better metric aligned to customer value would be the number of unique contacts emailed per month or the number of emails sent per month.

Common Value Metrics                                                                      

3. Invoicing: Recurring vs Threshold-Based

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 an impact on product and revenue-generating teams like sales, invoicing has a larger impact on finance teams. 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 on a threshold such as when they reach a certain limit or spend.

Recurring Invoicing

Recurring invoicing is the more popular of the two as it’s been popularized by traditional SaaS and is 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 for finance teams to plan for. There are a couple of downsides with recurring invoicing, 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 spending can accumulate quickly.

In order to combat this issue, threshold-based invoicing can be implemented. With threshold-based, the invoice is not generated until a certain dollar volume is reached. If prepaid, this means a customer is purchasing credits that 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 spending 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. 

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.

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 is 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.