Making money with APIs is a reality for successful API products such as Stripe, Twilio, or Google Maps. They work according to a model that is called direct API monetization, where they take a small amount of money for each API call and their customers make billions and billions of such API calls. With huge market valuations, these businesses are the shining examples of API success. And the success of these businesses inspires others.
For many organizations that might have just started their API journey, or organizations that have so far focused on their internal API programs, API monetization is often seen as the pinnacle of API success and aspiration they are working towards.
Too many API practitioners seem to be banging their heads against the wall, attempting to cram direct API monetization into their business. It does not always fit with the existing business model. In my work with clients, I have discovered that in such situations, we need to think a bit broader about monetization, beyond direct API monetization and its strict pay-per-API-call pattern, leading us to explore indirect API monetization. There are some practical patterns you can use to apply indirect API monetization in your business. First, let’s agree on definitions.
What is indirect API monetization?
Indirect API monetization is a catch-all phrase for situations in which the use of APIs is central to the business, and contributes to the revenue, but there is no price tag on the use of the API – the use of the API is free. Revenue comes from selling a (digital) product and the API plays an important role in the product or in the sale of the product. Counter-intuitively, in indirect API monetization, the API is free for use by the API consumer but enables or increases the sale of underlying products. It does not require a change in business models and it is more likely to improve your existing business model.
API monetization patterns
There are different ways to approach API monetization opportunities. It can help to think of different patterns for the role between an API and the underlying product being sold. These patterns can serve as an inspiration for creating indirectly monetizable APIs. These patterns describe the relationship between the API and the underlying product, which is monetized. I don’t claim to have found all possible patterns and I am looking for any additional patterns you may have discovered. But first, let’s review what I mean by the term “product”.
The product
The product is monetized, it has a price tag, and customers buy it. In this context, products are not limited to software products, they can contain software, such as a smart physical/hardware device or it can be just a service, such as an insurance policy. The product can be any product or service, software, an app, SaaS, an internet-enabled hardware device (like a fire alarm system), or an IoT device. Concrete examples of products are a payment service, an insurance policy, a telephone subscription, accounting software, a music streaming service, a car, or a thermostat.
The API and its relation to the product
Now that we have a monetized product, why do we need an API? Because the API plays an important role in the product or in the sale of the product. Specifically, any of the following API product patterns provide different opportunities for monetization.
Pattern 1: API = Product
If the API is the product, then we have a product-API relationship that lends itself to direct API monetization. For big API players such as Stripe and Twilio, the API is the product and this allows direct monetization of the API. The API usage is typically charged to the API consumers, who pay for the product.
This is the only pattern that allows for direct API monetization. All the following patterns will be realized via indirect API monetization.
Pattern 2: API = Sales Funnel or Distribution Channel
The API helps to sell the product and provide leads for the sales of the product. An example is the eBay API, which allows taking orders for eBay items from third-party websites. Another example is embedded insurance products where, say, APIs allow selling travel insurance policies directly from travel booking websites, or selling car insurance policies directly from car configurator websites.
These APIs help with the distribution and sales of the product, often through embedding into existing customer journeys.
There is a particular opportunity for products that are difficult to sell. Customers desire the shiny new car or the vacation, but not the car insurance or travel insurance. This type of indirectly monetized API allows surfacing those difficult-to-sell products at just the right time and place when the customer interest is at its peak.
Pattern 3: API = Data Feed
The API feeds data into the product so the product can work with that data. Many products intend to become “smarter”, to be more attractive to customers, and stay competitive. Platform businesses typically rely on data being fed into their platform. For example, eBay allows its sellers to feed new items into the platform via API, which is more efficient for its power sellers. So the API helps feeding data about items to be sold into the eBay platform. But where is the revenue? The revenue is generated when these items (whose data is fed via API) are sold on the eBay platform.
Pattern 4: API = Internal
The API is an internal part of the product and the API is not directly visible to the customer. However, customers experience the effects of such internal APIs e.g. as omni-channel experiences (synced consistent data and experience) or as smart/connected physical devices that can be configured and used via mobile app. These internal APIs make the product more competitive and more attractive and might justify a higher product price, however, they are not directly monetizable.
Let’s have a look at internal APIs in both software and hardware/physical products.
If the product is a pure software product, internal APIs are typically used to create omni-channel experiences. There are many examples, as this pattern is well-established for building modern applications with omni-channel experiences. Omni-channel experiences allow customers to log in to a service from any device, have a consistent and personalized experience, and finish on one device what they have started on another device. One of those many examples is Netflix, which uses internal APIs to synchronize settings, preferences, and view status across all connected devices, whether that is a TV, a mobile, or a web browser.
If the product is a physical device, it runs embedded software that exposes the API. It makes core functionality, analytics, configuration of the physical device available via a specific mobile app. Often, the functionality available through the hardware-based user interface becomes “remote-controlled” via an app. Examples include remotely switching the car’s heater on prior to leaving the house, so the car is comfortably warm when you get into it. Internal APIs make it all possible in the background, making the product more attractive to the customer.
Pattern 5: API = Feature
In this pattern, the API is an externally visible feature of the product. This API pattern allows linking the product to other products, which leads to the emergence of digital ecosystems. This is why we also call it Ecosystem API. If we look at these APIs in more detail, they share user data or data associated with a particular user, e.g. email data or bank transaction data. These APIs are ecosystem enablers, as they allow for automation, notification, and data synchronization across the boundaries of classical applications or products, the product “plays nicely” with other products.
Being a feature of the product, the API allows for the integration of the product into an ecosystem, which might revolve around the life of the end-user, or automate underlying business processes.
An example of an ecosystem that revolves around the life of the end-user could be the ecosystem for music. Let’s imagine end-users have to choose between two music streaming products A and B. If product A can play music in my car (via ecosystem APIs), while product B cannot offer that (because it does not offer an ecosystem API), then customers will likely choose music streaming product A and happily pay for the product. End-users choose products that play nicely with other products they already have. The ecosystem API provided by product A is indirectly monetized and helps sell the product.
So again: What is indirect API monetization?
In indirect API monetization, the underlying product is monetized. The API has one of the following roles: it is an important feature of the product, enables product differentiation, or plays a role in the sale of the product. The API is typically free for use by API consumers, it is the customers of the underlying product who pay for the product. And the set of customers of the underlying product is typically disjunct from the set of API consumers.
In summary: How to monetize APIs
For many existing companies that have products which are not APIs and customers that value their product, introducing direct API monetization would require quite a big change to the business. The organization needs to establish a new line of business (the API product) next to its existing products. They need to establish API consumers as a new customer group within the organization and need to find new customers for their directly monetized APIs. Their existing customers might be happy with the underlying product, but they are not ready yet to buy APIs as a product.
As you can see, direct API monetization requires a big effort and a change in the underlying business model for existing companies. However, this change is often integral to wider change and transformation. Claire Barrett’s advice for getting support for API products describes it in more detail.
Due to the large changes required to realize direct API monetization, the opportunities provided by indirect API monetization are often easier to realize. Explore the indirect API monetization patterns described in this blog and see how they fit your current business model or your future plans. It can be an API that sells the product, an API that feeds data into your product, internal APIs, or an APIs-as-a-Feature.
You might also like … the three foundations for making money with APIs
Making money with APIs is often aspirational and can be difficult to realize in practice without: (1) the right business model, (2) an appropriate pattern for API monetization, and (3) support from the organization. In this series of articles, we explore these foundations in more detail.
- Marjukka shows how to select the right business model in Is there room for API products in your business model?
- Matthias shows 5 simple-to-follow patterns for making money with APIs that go beyond direct API monetization.
- Claire discusses some of the challenges at traditional organisations with getting commitment to productized APIs, and how to get around them.
Also published on Medium.
