In the last 20 years of software, the way software is sold has fundamentally changed. Today, a single developer today can generate more ROI through an API than a small team using a UI-based SaaS 10 years ago.

Given the state of the API economy, if you’re looking to expand your SaaS offering simply by adding more seats, you might face an uphill battle.

As a software vendor, you likely already have lots of APIs being used to power your internal SaaS platform. The next evolutionary step is to expose these APIs to customers and partners for additional growth or revenue generation. When you directly monetize your APIs, your highest cost center turns into a revenue center for the company.

However, selling an API is not easy. You need to win the hearts of individual developers with a competitive single-use price, but you also need to capture enough value to support a relatively expensive cost structure for acquisition and support.

Here’s how usage-based pricing aligns with this.

Usage-based pricing for APIs meets everyone’s needs on the sales spectrum

Simply put, individual developers will research and decide on which APIs fit their use case. But, no single developer will deploy an app or integration to production in silo. Many stakeholders can weigh in or veto a decision on whether to use an API and how much of the API they will consume.
Different use cases and complex enterprise requirements need expensive support resources on your end—which is a very high acquisition cost in comparison to B2C models. If you priced your API for <$100/month, this can cause a wide range of problems.

With UBP, your initial goal is to get the developer to pay a small token amount (i.e. <$100/month) to get to their “Hello World” and see value. And once initial value is established and usage is growing, sales can work with the account to identify new use cases that can accelerate the usage of the API, translating revenue growth that can scale up to seven figures per customer.

This motion, known as selling through the developer, helps fuel additional customer acquisition and R&D for what was originally an expensive cost structure. Sales identifies the accounts with potential and works with them so they are internal advocates. These developers are excited to push their solution to production, find new use cases for their application, and in turn growing into a much larger customer.

Usage-based pricing is a key component that can meet the needs of both sides of the spectrum (marketing to individual developers and selling complete solutions to organizations with lots of value) regardless of how many developers are involved. However, each API business is different. There are four key components to consider when designing a usage-based pricing model:

1. Pick the right metric to charge for
2. Prepaid vs. postpaid
3. Packaging strategy
4. When to invoice

Pick the right metric to charge for

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. If you pick the wrong metric, you could be undercharging a customer and leaving money on the table. Conversely, not every API call is worth charging for. Some APIs might error out or return no results.

On the other hand, you might offer both a batch and non-batch API. A batch API can help package many valuable transactions into a single API and so the value can’t simply be measured in the number of API calls. For example, if you could build an SMS API offering where a single API call sends 100 SMS messages as a batch and then transcribes them to create a larger amount of value for the customer.

So, a useful metric to bill for would be the number of SMS sent, rather than the number of API calls. You’ll want to have a good understanding of the value your API provides and match that with a competitive price across the sales spectrum. Here are some tried and true value metrics from other companies.

Prepaid vs. postpaid billing

Billing strategy impacts adoption and customer activation the most and is usually driven by the product department.
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.

The positives and negatives of prepaid

This is especially important if your acquisition or setup costs are high which allows you to invest further into product and growth. It’s also beneficial for customers so they know what they are committing to upfront and can predict their spend.

However, customers might not know their expected usage amount before making a payment, so some companies choose to introduce committed spend—which can include volume discounting. The downside to prepaid is that customers may have to do upfront mathematical estimates before they have real world data or see value in the API.

One example of a prepaid billing model would be PandaDoc. You subscribe and pay for the API before it’s used. Another example of a prepaid billing model would be Sinch and Twilio. You purchase a set of credits which can then be “burned” down later.

The pros and cons of postpaid

With postpaid, you’re extending credit to your customers as they use your platform until they pay. It reduces onboarding friction, as 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 that a customer does not need to commit ahead of time before any value is seen.

That said, it’s not always ideal from the product end. When you’re extending credit through postpaid billing, 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.
A typical postpaid billing model can be seen by most cloud vendors. You can spin up and start using a VM or database before you pay (they may still require a credit card to prevent abuse but you’re not charged). Another postpaid example would be Stripe. You don’t pay anything until after the transaction happens.

Packaging strategy

When you’re talking about packaging strategy, you’re ultimately talking about the impact on initial contract value and expansion revenue. Not every customer will receive the same value and pay for the same amount. So it’s important to figure out how to package your features and usage components in attractive and understandable tiers.

The most common technique is through tiered pricing, where a SaaS creates 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. The price to perceived value gap is significantly reduced as customers only pay for what they need and nothing more.

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.

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.

An example of PAYG pricing would be data platforms like Tomorrow.io and Algolia. You pay per transaction with no minimum spend.

Where tiered pricing falls short

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, causing 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 might have “too many additional features” that are unnecessary for said customer. Similarly, you don’t want more than three or four tiers. If you have too many, it creates analysis paralysis.

An example of tiered pricing would be Twitter’s new API pricing. You subscribe for a quota and get access up to the quota. Nothing more.

Metered pricing meets APIs

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.

When to invoice for usage-based pricing

Your financial team drives the invoicing strategy when implementing a usage-based pricing motion. 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 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. Buyers of enterprise software tend to prefer recurring invoicing given its predictable nature.

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

Many SaaS vendors like PandaDoc and Algolia invoice you on a recurring basis. You always get the invoice on the same day of the same month, quarter, or year depending on the contract terms.

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 it’s prepaid, this means a customer is purchasing credits which can then be used (which might be far in the future).
• If it’s 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.

Of course, threshold-based pricing is not without its 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.

Sinch and Twilio are also good examples that follow threshold-based pricing. They give you the option to purchase credits at any time regardless of when they are consumed. Doesn’t matter when you purchase credits.

Additional tips for implementing usage-based pricing

Implementing usage-based billing introduces additional complexities beyond typical tiered pricing. Remember, businesses are purchasing an API because they see it adding value to the organization such as to increase revenue, reduce engineering cost, or risk reduction versus a homegrown solution.

1. You need an accurate mechanism to meter customer usage in a reliable way, and do it at scale.
2. 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.
3. Price your API on more than one variable. By pricing on just one variable, you may be leaving money on the table. The sweet spot is two or three pricing variables so enough value is captured to generate meaningful revenue for the company.

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 or Project X.

This solution connects to your API gateway of choice, like Kong or Tyk to your billing system, or like Stripe so you 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.

• SEO Powered Content & PR Distribution. Get Amplified Today.
• PlatoData.Network Vertical Generative Ai. Empower Yourself. Access Here.
• PlatoAiStream. Web3 Intelligence. Knowledge Amplified. Access Here.
• PlatoESG. Automotive / EVs, Carbon, CleanTech, Energy, Environment, Solar, Waste Management. Access Here.
• BlockOffsets. Modernizing Environmental Offset Ownership. Access Here.
• Source: https://openviewpartners.com/blog/4-tips-to-monetize-apis-with-usage-based-pricing/