Why APIs can't follow traditional pricing models

The rise of API First

Although APIs have been around a while, the idea of monetizing them is still new and traditional pricing models used by CFOs aren’t well suited. As CFOs we need to act fast to build models that are suited to ‘API as a Product’ companies to catch up with huge market demand. In 2020, more than $2B has been invested in API companies, a significant increase from the $0.5M invested in 2017. So how do we build new API pricing models that will continue to drive investment?

The challenges of pricing an API

Pricing an API is tricky because:

• It’s a relatively new product in terms of monetization
• It’s not a tangible product
• Calculating the cost to serve is not straight forward
• The value a user gets from the API can vary dramatically
• Traditional pricing methods don’t fit the model

Here at TravelTime, we know these challenges all too well. So, how did we decide to monetize our API offering?

Traditional Pricing Methods

My first step for pricing TravelTime was to look at traditional pricing models and see if any would fit our use case.

Cost Plus

Why is a cost-plus pricing model not a good fit for an API First business? Firstly, we are not selling a tangible product, that has a clear-cut cost of sale. We are selling an API for which the cost structure is much more complicated. The cost of an API request can fluctuate in response to several variables including peak concurrency, endpoint, and complexity of the request. The cost-plus model is a very simple model for selling physical products but when applied to our API, it becomes far too complicated. Most importantly, pricing via this method does not consider the value of our product to our customer.

‍Competitor Pricing

Another traditional pricing method is competitor pricing. You look at your competitor’s pricing models, and you cut just below them. But what happens if you don’t have any direct competitors? If our customers wanted to use Google's Distance Matrix API for generating lists of search results optimized for travel times, it would cost an incomparable amount of money. The same goes for other companies operating in the location API space. There is no one else out there with a feasible customer proposition for TravelTime Search.

‍Value Based Pricing

Value based pricing is the go-to pricing method for SaaS businesses. The basic concept is customers will pay what they are willing to pay; the price is set based on the perceived value by the customer. To do this successfully, it requires a deep understanding of the ROI our product generates for the customer.  

This approach is popular with SaaS companies because typically they serve customers in several different industries or segments, all using their product in different ways, with varying revenues and profit margins. Salesforce is a classic example of value-based pricing, their prices can vary wildly depending on several differentiators – the main one being the industry vertical of their customer.

This is the most appropriate model for us as an API company because our API is used in so many ways.

But how do we determine the value our API creates for our customers? Our API can be used in a way that no other API can. The value of TravelTime Search is in driving up the conversion rate for our customers, boosting their top line, or to look at it another way, cutting their customer acquisition cost. Either way, implementing our API boosts £s, and the boost is not insignificant.

TravelTime enriches our user experience, increasing conversions by 10%, Christophe De Rassenfosse, Chief Product Officer, StepStone

If your annual revenue is £10m, a 10% conversion increase simply translates into an extra £1m revenue. In the world of e-commerce, a 0.5% conversion rate improvement is considered a good improvement, let alone 10%.

After looking at traditional pricing methods, the next step was to look at typical pricing models that are currently out there for other API products.

Typical API Monetization Models

‍Freemium

Lots of API companies offer a Free Tier for using their API. This works well because developers can test the API before committing any spend. It’s much easier to convert free users to paying customers than prospects who have never used it before. It’s also good for hobbyists or individuals who do not have a commercial use case.

PAYG

Another common pricing method is Pay as You Go. This is a usage-based pricing model where you only pay for what you use. This is a good option for companies or individuals who want to run small or one-off projects and don’t need a high volume of requests. PAYG would work well for your API business if usage varies wildly between customers month on month.

‍Fixed Monthly Fee

Some API-first companies offer a fixed monthly price for use of the API. This offering typically involves several pricing tiers, and with each tier, there is a cap on how much you can use. If you repeatedly reach that cap you move up to the next pricing tier.

The usage cap is most often a cap on the number of API requests you make in a period, usually a month. There are sometimes other limitations on pricing tiers, for example SLA, endpoints available, add-ons included etc. Pricing in this way is designed to encourage upsell and expansion revenue.

What are our biggest challenges?

The complexity and diversity of our customer base makes pricing a challenge. From recruitment portals processing significantly high volumes of job searches every single day, to real estate development businesses identifying the most profitable location for a future development, we serve a wide range of segments and industry verticals. It has become clear to us that there is not a linear correlation between volume of requests and the value derived, and this is where our biggest challenge lies.

Because of this mismatch between usage and perceived value of our product, we need a way to price fairly while delivering value to as many customers as possible. We are constantly re-evaluating our model and on the lookout for ways we can improve our offering to support as many customers as possible across the globe.

Additionally, understanding the true cost of serving our API is a complex task. Although we don’t apply a cost-plus pricing model, it is nevertheless important to understand the unit economics of our product. Having a solid understanding of how much it costs to deliver our API means we can ensure we aren’t leaking margin through our pricing, but more importantly understand how scalable and efficient our infrastructure is, manage our capacity and benchmark our performance against our competitors.

To understand this, we frequently load test the API to understand how much capacity we have, without impacting response times. Returning results to our customers within milliseconds is an extremely important part of the value we deliver, and we always ensure sufficient capacity to uphold the customer proposition.

We measure capacity in terms of peak concurrency, which in TravelTime terms is known as ‘HPM’ (Hits Per Minute). We then apply the results to the customers we serve and calculate the proportion of server space being used. We take the cost of our servers and any other resources involved in maintaining and delivering the API to our customers and apply that to the % of active servers space to derive our full and final cost to serve.

Finally, we want to make it easy as possible for our customers to understand our pricing approach. With so many companies pricing on usage, it’s almost become an industry-standard approach which customers and branching out from this can be a dangerous strategy. However, we believe our approach is much more straightforward, and, most importantly delivers the maximum value to our customers.

Concurrency is King!

Here at TravelTime we chose to adopt a combination of the above models to provide ultimate flexibility for our customers. However, the core driver of our fixed monthly pricing is not usage, instead, it’s focused solely on concurrency.

What this means is, that we do not limit the number of API requests our customers can make in any one month. We limit the number of concurrent requests you can do.

To put it another way, we don’t mind how much water you want to take out of the pipe, but what we do care about is how quickly you want to consume that water - the width of the pipe required.

‍Why this works for us:

The reason why this works for us is that our costs are driven by concurrency - it costs us more to serve clients that require a high HPM (Hits Per Minute) than to deliver a large volume spread over the month.

‍Why this works for our customers:

• Our customers don’t have to worry about usage limits
• Our customers can use API in many ways for a fair price, widening our reach
• The value: usage ratio can vary dramatically from customer to customer

The Future

At TravelTime, we understand that pricing your API is one of your biggest challenges and a fundamentally important part of your go-to-market strategy. Getting your API pricing right means you can deliver maximum value to your user. By broadening your knowledge of the industries you serve, you'll be able to easily cover the costs to serve customers and generate a healthy ROI for the business. Finally, and most importantly, developing a full understanding of your customers ROI will help you also develop a better product as a result.