For many enterprise products, revenue is driven through a subscription to Software-as-a-Service (SaaS), such as a number of seats or a yearly license. Subscription-based pricing models are perfect for UI-driven workflows but unsuitable for automation and AI-driven workflows.

Because of this, APIs are rapidly becoming the de facto interface to use another company’s products. Developers often seek 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.

Engineering platforms are costly to maintain, and in today’s market, efficiency is critical. By directly monetizing your APIs, your highest cost center becomes a revenue center for the company. This fuels further investment into your APIs and products so they are best in class.

The Challenge of Selling APIs

However, selling an API is not easy. As companies transition 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 buying authority. An individual developer can perform research and decide on a set of APIs that fit their use case. Yet, no single developer will deploy an app or integration to production in isolation. Many stakeholders can weigh in or veto a decision to purchase and consume the API product.

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, 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. If you get developers to start seeing the value in the API, they can advocate to leadership 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 at this stage, so the subscription can simply be placed on a manager’s credit card.

Sell Through Developers

Once your customer is paying on a self-service plan and meets certain usage criteria, you then engage your sales team. 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 they may have. A customer may consider upgrading due to increased usage, new use cases, or advanced requirements.

This means your sales team must understand a customer’s usage to identify when to engage them in a sales process. To do this, you should set up an API analytics tool to track each customer’s API usage. This provides a single pane of glass into each customer’s habits, which can aid sales and customer success. It’s also 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 increases 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 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 or return no results.

Similarly, you might offer both a batch and non-batch API. If you’re building an SMS API offering, a single API call that sends 100 SMS messages as a batch and then transcribes them creates more 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 perform 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 with customer value would be the number of unique contacts emailed monthly or emails sent monthly.

Common Value Metrics

Ensure the API Creates Business

Just because you’re able to get developers to use the API doesn’t necessarily mean it creates business value. Developers may adopt an API just to experiment with new technology, create a hobbyist project, or pick up new skills. However, businesses don’t care about a simple “Hello World” API. Instead, they purchase an API because it adds 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 deploy a 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:

1. Billing
2. Packaging
3. Invoicing

1. Billing Strategy

The 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 spending 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. Since 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 might, for example, use a much more expensive service than expected and then have regrets.

2. Packaging Strategy

Packaging strategy impacts initial contract value and expansion revenue the most. Not every customer will receive the same value and pay for the same amount, so 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 a 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 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 that 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 the 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-based component. Common things to meter 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.

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 an 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 certain PAYG models. If some customers have extremely low volumes and are only 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.

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

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