While the subscription-based pricing option has been the popular go-to for many SaaS companies, the usage-based model has recently seen significant traction in SaaS companies. But which solution is right for monetizing your API product?
To answer that question, this week on the API Intersection podcast, we spoke with Behailu Tekletsadik, co-founder and CEO of Archetype, which is a startup focused on usage-based billing for APIs.
“We’re building a solution for API-first companies to essentially enable them to monetize their APIs and manage a lot of the infrastructure that it requires. So, when it comes to building flexible pricing models for each of their enterprise customers, to assigning permissions roles or managing their API Keys authentication, we can help,” shares Behailu.
Behailu sat down with the API Intersection team to discuss the pros and cons of a usage-based approach versus a subscription-based approach to your API pricing strategy. According to INVESP’s ‘The State of SaaS Pricing Strategy– Statistics and Trends’ report, “it is estimated that the average Saas company will only spend about 6 hours determining their pricing strategy.”
The most significant advice to take away is–Don’t be like that! It is critical to take the time and effort to figure out how to monetize your API correctly and to determine if monetization is even the right approach. For example, your internal APIs are usually free, and external APIs will be the ones monetized, if any. Your APIs should be products you nurture and strategize for, like any other product, including the billing aspect of that product.
Usage-Based Billing for Your APIs
“I like the idea behind usage-based pricing because you charge people for the value that they get from your product; I believe that drives a lot more adoption,” shares Behailu.
This model is also commonly referred to as consumption-based, focused on charging users for how much of the product or service they use (think of your energy company, water company, or phone bill). API-first companies like Twilio and Stripe are also great examples of companies that have maximized the usage-based strategy.
“If you are doing usage-based pricing, definitely think about whether doing volume base discounts makes sense to your customers. Then there are other things around that you can offer, like can you charge a commitment?” shares Behailu. “For example, charge a minimum for their usage where your usage is free for the first ten thousand API calls, and go up from there.”
Cost-effectiveness is often the lure of usage-based pricing on your APIs because, with a subscription-based model, developers can utilize as much of the API as they want or as little as they want and will be charged the same flat rate. This can also be a cost-friendly option for your end users using the API less. Finally, usage-based billing often provides more flexibility than subscription-based.
However, letting your users control their own costs can also have some downsides. Be smart about which metrics you charge for usage (i.e., API calls, gigabytes sent, minutes, monthly active users, active hours, etc.) because if you’re putting too much cost behind specific aspects of your API product, high prices can deter heavy-usage customers.
Although charging by the number of API calls is probably the most common in our industry, it’s not the only option. Transaction volume, revenue/cost share, data volume, or the number of users could also be considered depending on what your API does.
If you’re considering this model for your APIs, Behailu highly recommends thinking closely about pricing as well in the context of API, understanding what your users are doing, and seeing if there are other competitor APIs that they are getting more value from. Ask yourself if there is more value you’re not charging for than you could be in the future. He also mentions considering soft and hard caps applied to your API when using this approach.
“Feedback we’ve been given about the idea of using a soft cap and a hard cap was helpful. For example, say a soft cap is when you alert a customer that they’ve reached 80% or 90% percent of their threshold,” shares Behilu. “Then a hard cap where they’ve gone to 110% or 120% of their usage, and you cap it there so that they don’t blow their entire budget and rectify a mistake if it was made on the users’ end.”
It’s a fine line to not give too much away for free but also not charging to the point where end-users can’t even seek the value out of your API without hitting a paywall.
Subscription-Based Pricing
“With a subscription, you can have a seven-day free trial or 14-day free trial, versus with usage-based pricing, you could also go the premium route where you have the first thousand API calls as free, but to go beyond that, you must enter your credit card,” shares Behailu.
A subscription-based pricing model has a set rate and different package levels at each fixed rate that charges the end user either monthly or annually. Streaming services like HBO Max, Netflix, and Hulu are great examples of this form of pricing.
This is a tempting model because it ensures consistent revenue from your API every month, which is relatively predictable. It’s often easier for end-users to budget your API into their costs, understanding precisely what it will cost them monthly. This model also bodes well for creating longer-lasting relationships with your end-users than a usage-based billing model may provide.
On the flip side, a con of this API-billing method is that usually, on a subscription-based model, over time, you will see rates increase as production costs rise. It’s also less flexible, meaning this model may deter API consumption if you ask users to pay upfront before understanding the value and how much they’re seeking to consume. Developers are a very ‘try before you buy’ crowd, and an immediate paywall that requires a monthly subscription can make one adverse to even using your API.
So, which is better?
Ultimately, it depends on what goals you’re trying to accomplish with monetizing your API. Behailu emphasizes that usage-based billing for APIs is not necessarily the right fit for everyone and to use caution when determining what’s the best pricing model for your APIs.
Sometimes, even introducing usage-based pricing could be a barrier to API adoption when developers are considering whether or not to utilize your API (see the dangerous delay to adoption that we covered last year on the podcast). At the end of the day, the most crucial thing is garnering adoption and value for your API. If you do not see that, you have other problems to take care of long before monetization becomes a concern.
In Behailu’s experience, some companies haven’t even considered monetization and instead are in a ‘public beta where they’re capping everyone at a thousand API calls a month, or they’re just seeking to see if adoption is even of interest for their API product before introducing monetization,’ as an example.
It’s always wise to ensure users will actually consume your API product before you even think about building the billing infrastructure. Be careful not to pull that motion lever too soon by introducing premium immediately. Take time to understand what value your API product drives, and then your end consumers will be more willing to pay. For more insights from industry leaders, check out the API Intersection podcast.
