Why monetize APIs?
For many API programs, the API is a product being sold for direct revenue. This requires a go-to-market strategy to monetize the API effectively. 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 quota limits in place to ensure customers stay within their contract terms.
However, there can be many stakeholders that can weigh in or veto a decision to purchase an 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.
Challenge of selling APIs
When it comes to monetization, there are two sets of challenges to be aware of. There are both Engineering challenges and also Business challenges. This guide will touch on both, but the main discussion of this article is on Business challenges which revolves 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 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. As part of any procurement process, you’ll need to appeal to 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 appeal to 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 and in a self-service fashion. 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 received 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. An 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.
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:
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 is the most common model for traditional SaaS and enterprise software companies. Because the API 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 for procurement. Because usage amounts is 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.
On the other hand, postpaid is 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). 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|
2. Packaging Strategy
Packaging strategy impacts 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 is an accelerant for developer-first or product-first organizations. This can also be important when customers have very low levels of usage.
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 pricing with predefined suite of features/capacity for each tier||Usage-based or consumption-based pricing based on a unit price.|
Choosing the consumption metric
With usage-based pricing, it’s important to choose the right metric to meter and bill on so that it’s correlated with the business value received. Billing for every API call is likely a poor metric since some APIs are low value (such as a status probe). 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 create a larger amount of value for customer than an API call that sends just a single SMS message. In this case, billing based on number of SMS sent would be a better metric than billing on number of API calls.
As 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 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 send 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|
|Transaction volume||Number of API Calls, Messages Sent||APIs and event-based platforms such as SMS and analytics|
|Revenue/cost share||% of revenue, transaction fee||Platforms focused on money such as payments or expense reporting|
|Data volume||Gigabytes sent, Minutes made||Platforms focused on data such as logging or storage|
|User-centric||Monthly unique users that are active||A modern version of charging per seat or per user|
|Resource||Compute Units, active hours||Compute infrastructure such as a database or virtual machine|
3. Invoicing Strategy
Invoicing strategy impacts cash flow and typically 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 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.
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.
|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)|
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.
Moesif has released a suite of usage-based billing features, that make it easy to set up metering rules. Because Moesif has turnkey integrations for billing providers like Stripe and Recurly, the heavy lifting of aggregating metrics and automatically invoicing customers is already handled.
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.