Don’t just monetize your APIs – do this instead
“How can we make money with our APIs?” is a question I get asked quite often. My answer: Don’t just monetize your APIs – do this instead.
“How can we make money with our APIs?” This is a question I get asked quite often when working with customers on their API strategy.
For some, this question comes up when they are starting their API initiative – for others it comes up much later in their journey, after having grown their internal API portfolio and planning to selectively open up some APIs. Maybe you have also wondered about it?
If you rather watch than read, you can click on the video at the bottom. It covers the same topics as this blog post.
What is API monetization?
When you start researching API monetization, you might come across John Musser’s seminal work: “API business models: 20 models in 30 minutes.” He studied different API revenue models, categorized them, and ordered them into a tree diagram. It is fantastic work, providing an overview of all these models in a convenient tree structure. But how do you practically navigate the models and select the right model(s) for your API?
And when you continue researching API monetization, you will also come across products such as Stripe, Twilio, or Google Maps that demonstrate that it is not only possible but highly lucrative to put a price on APIs. As API-only or API-first products, a significant amount of these products’ revenues can be attributed to the pattern of “direct API monetization,” requiring the caller to pay for access to the API.
These API products are seen by many as the pinnacle of API success, and the pattern of “direct API monetization” as clearly something to emulate and replicate within the API program of their enterprise. The success of these businesses inspires others and creates aspirations to work towards to. Why wouldn’t you want to charge a price for each and every API call?
I say, if you want to generate revenue with your APIs, don’t just put price stickers on all your APIs. Learn about alternative forms of API monetization first and be strategic about selecting the right form of monetization that matches each of your APIs.
You may ask: “But Matthias, don’t we leave money on the table, by not directly monetizing all our APIs?”
Not just about the price tag
As it turns out, using direct API monetization in the wrong situation can be counterproductive. A price tag might prevent API consumers from using your API, and direct API monetization might not always be a fit for your existing business model.
It is important to realize that “direct API monetization” is just one tool in your toolbelt for monetizing the benefits of APIs. Which other options are there and when should you use which one? That is what we will explore in this and a follow-up blog post.
We’re a Leader in new Gartner MQ
See how the top API platforms compare in the 2021 Gartner® Magic Quadrant™ for Full Life Cycle API Management and why Software AG is ranked a leader.
The alternative to “direct API monetization” is “indirect API monetization,” 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. Can’t imagine it? Here is why and how this works.
Indirect API monetization
To use indirect API monetization, your business needs to have existing (digital) products that you sell. If you are a bank, this product could be a bank account. If you are an insurance company, this product could be an insurance policy. If you are a hardware company this product might be an embedded device. If you are a software company, your product could be SaaS. Revenue comes from selling these existing (digital) products.
If you already started with a monetized product, why do you need an API? With indirect monetization, the API plays an important role in realizing features and benefits of the product or in the sale of the product. Indirectly monetized APIs can help to create additional revenue for existing products, help to sell existing products, and help to make existing products more competitive and attractive for end-users. It is all about carefully choosing and designing the relation between the product and the API.
Counter-intuitively, in indirect API monetization the API is free to use for 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. The value the API provides, grows with the usage of the API. Putting a price on the API would limit usage and thus limit its value.
The relationship between product and API
You can identify a good starting point for monetizing APIs by answering the question: What is the relationship between your product and your API? It is a question that is often relatively easy to answer. This question can also help you navigate John Musser’s tree diagram of revenue models and find a suitable model. The nature of the relationship between product and API determines viable monetization opportunities, which can then be captured by different revenue models.
So, when using indirect monetization, it is important to carefully consider the relationship between the API and the underlying product. Specifically, each of the following four patterns describing the relationship between the API and the underlying product offers an opportunity for indirect API monetization.
- Indirect API Monetization Pattern 1: API = Feature, which enables the emergence of an ecosystem
- Indirect API Monetization Pattern 2: API = Sales funnel or distribution channel
- Indirect API Monetization Pattern 3: API = Feeding a data-driven product
- Indirect API Monetization Pattern 4: API = Internal, creating omni-channel experiences
Let’s go through these patterns one by one.
Indirect API Monetization Pattern 1:
API = Feature which enables the emergence of an ecosystem
In this pattern, the API is an externally visible feature of the product. If we take Spotify as an example, it has many features (small white blocks inside the product box), such as searching for music, listening to music, or discovering new music that matches your taste. The API is one more such feature, that end-users will love the product for: The API links the product with other apps that the user already likes and uses.
Your music app might use this API pattern to create an ecosystem for music by interacting nicely with other apps in your digital environment, such as the routing planner app you use to navigate from A to B, the fitness app you already use for working out, and the social media app you use all the time to communicate with your friends – this music app has become a part of your life. It is so conveniently embedded in your daily routine, you would never even think about switching to another music app.
This API pattern allows linking your product to other complementary products, which leads to the emergence of a digital ecosystem around your product. This is why I also call APIs following this pattern “Ecosystem APIs.” 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 in the digital ecosystem.
Imagine you have to choose between two music products: A and B. If product A can play music in your car (via ecosystem APIs), while product B cannot offer that (because it does not offer an ecosystem API), then you will likely choose music streaming product A and happily pay for the product. End-users choose products that play nicely with other products that they already have. The ecosystem API provided by product A is indirectly monetized and helps sell the product now and keep selling it in the future.
Indirect API Monetization Pattern 2:
API = Sales Funnel or Distribution Channel
With this pattern, the API helps to sell the product and provides leads for the sales of the product. An example is the eBay API, which allows taking orders for eBay items from third-party websites. So eBay can get additional buyers that do not even have to come in via its own website or app. Using this pattern, eBay has made more than $5 billion in gross merchandise-bought in 2020.
Another example is embedded insurance products where, say, APIs allow you to sell travel insurance policies directly from travel booking websites, or to sell car insurance policies directly from car configurator websites.
These APIs help with the distribution and sales of your 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’s interest is at its peak.
Indirect API Monetization Pattern 3:
API = Feeding a data-driven product
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 an API, which is more efficient for its power sellers. So the API helps with 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.
The same pattern is applied in many social media apps, where user-generated status updates get fed via an API into one side of their data-driven platform, to subsequently get monetized on the other side of the platform via personalized news feeds.
Indirect API Monetization Pattern 4:
Internal, creating omni-channel experiences
In this pattern, the API is an internal part of the product and is not directly visible to the customer. However, customers experience the effects of such internal APIs as omni-channel experiences (synced consistent data and experience), for example, 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. Take 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 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, and 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.
Again: What is indirect API monetization?
In indirect API monetization, an existing product (not the API) is monetized. The API plays an important role in selling the existing product: It is an important feature of the product, helps to build an ecosystem of complementary products around the core product, creates lock-in, gets relevant leads for the sale of the product, conveniently feeds valuable data into the product, or enables product differentiation.
The indirectly monetized API is typically for free to API consumers. The end-users, or customers of the underlying product pay for the product and thus create the revenue. And the set of customers of the underlying product is typically disjunct from the set of API consumers.
Now that you know what indirect API monetization is and have seen the four patterns for realizing indirect API monetization, should you use only indirect API monetization from now on?
No. Neither direct nor indirect monetization is the only answer. It is about making the right choice for each API and being strategic about your choice. And how to make a strategic choice for API monetization is the topic for my next blog on API monetization. Stay tuned.
Meanwhile, you can watch the recorded webinar by signing up below.