An API as a Product is a type of Software as a Service that monetizes specialty functionality that can be used by other companies for just a licensing or consumption based fee.
A lot of technology companies often start with an Internal API, then launch a Public API, and finally a Partner API. You can read about the different types of API in the blog post Types of APIs.
Often what happens is a company decides to build a new mobile app which shouldn’t directly communicate with the database. So the company builds an API for the mobile apps to communicate with the database that also does some calculations (business logic) and validations (business rules).
Over time, the business realizes that they could also potentially sell access to the API or allow their customers to directly connect with it and finally have partners launch apps in different verticals.
Monetizing an API can be done in a few different ways, but it really depends on the Type of API and the Type of Product being offered. Some of the businesses, I’ve worked for have been e-commerce / financial focused and charge a percentage of revenue or a service fee per successful call.
Freemium Model With Tiers
The tiered model / freemium model is the most common business model for API as a Product. It often starts with a base number of free calls and significant rate limiting.
Limitations might be free non-enterprise features, time bounded free trials, certain number of allowed calls (rate limiting) , etc. The model needs to be balanced so that the free offering doesn’t hurt the premium offering and ensures that that the free option is worth integrating with.
The Consumption Based Model is based on the concept that the more you use the more you pay. There might be some sort of bulk cost discounting associated with it, but that might not always make sense. For example, if you buy 1000 calls it might cost $750 but if you want to do pay as you go, 1000 calls might cost $1,000.
This model allows the customer to control their costs, but the business has to have a great handle on what the costs are per API call. It’s really hard to get to that level when running in your own data centre. For cloud based services, it might get easier if your developers are properly tagging resources.
A subscription model is basically the same as the Consumption Based model but saying you get a number of requests per day or month. This is my preferred way of handling things – if you don’t use them at the end of the month you lose them. Usually a subscription based model results in the API Provider making more money because there will be a lot of customers that don’t use all of their capacity so they don’t have as high of costs.
I’ve never personally seen or heard of anyone doing a licensed API model, but the concept is that the business develops an API and then licenses it to somebody else to run.
Partner based APIs usually work with Partner APIs and they work on a fixed license fee upfront, and then some sort of commission or revenue splitting happening later on.
Wrapping It Up
In this blog post, we covered a number of different potential business models for an API as a Product. An API as a Product usually happens after the business realizes that the API is as valuable as the complete product.
Don’t forget it’s important to have a Product Mindset as you lead a business pivoting to an API as a Product.