Treating API offerings as a Product and Monetization continue to be very hot topics. Recently I participated in an API-as-a-Product Livecast hosted by Nordic APIs where this was the focus.
I have previously written about both API Product and Monetization as independent topics but thought it might be beneficial to cover both topics as they interrelate and add some considerations that I have not covered in prior articles.
Since I do not intend to repeat too much of the information from my prior articles, here are pointers to those:
- API Monetization – What Does It Really Mean? (blog)
- API Monetization – It does not mean what you think it means. It is far more. (video) – roughly the same information as the blog in video form.
- API Monetization – Understanding Business Model Options (white paper)
- API Products – Who, What, Where, When, Why, and How? (blog)
Why API Products?
Let’s start where I ended in the API products article listed above. Addressing the question “Why API Products?” In the blog I said, “If we are building APIs, there is only one reason we are doing this – because we want someone to use them. API Products are all about driving the consumption of our APIs.” API products make it easier for our target audience to consume our APIs. The next logical downstream question after this which I did not address is “why do we want someone to use / consume our APIs?”
There are several common business drivers for using APIs. And this is another topic I have written about frequently, but let’s take this a step further here as well.
- Speed – Speed to market is probably the most common initial API driver. APIs being easier to use enable a developer rapid self-service access to our business assets, allowing them to deliver new or enhanced offerings to market faster. Delivering offerings to market faster drives… Revenue!
- Reach – Reaching new customers or new markets expands our potential customer base. APIs allow our business to on-board partners and create ecosystems. Having more channels to market exposes our offering to more potential customers and drives… Revenue!
- Innovation – Innovation is about trying a new business opportunity. Frequently now related to digital transformation initiatives, even in the earlier days of APIs the goal was to allow for a low risk and low cost approach to attempt new offerings and business models. APIs and microservices provide developers this option, and again the goal here is… Revenue! But also cost savings over alternate options.
- Domains – Domains is about sharing appropriate business assets across business segments. Using APIs enables secure and appropriate sharing of assets across lines of business and/or geographies. Often avoiding duplication of work and data resulting in… cost savings!
The goal for all four business drivers is Monetization – driving revenue and cost savings. API Products enable our business drivers which result in Monetization.
Most businesses using APIs successfully are monetizing APIs by speeding offerings to market, reaching new markets and new customers, innovating, and sharing assets better inside their enterprise. If you do not consider these to be monetization, you are ignoring the primary value APIs are delivering for most businesses. And yes, this is financial value. IBM worked with Forrester consulting several years ago to show an average of 674% ROI in surveyed businesses using these approaches.
What about Direct Monetization?
Direct monetization is the elephant in the room. It is the type of monetization everyone thinks of, everyone wants to talk about, but very few actually do. There are good reasons for this.
Direct monetization is attractive as a potential new business model but the most attractive aspect is that it is extremely easy to associate the revenue generated with your API initiative – the revenue is based on direct payments to you for the use of your APIs. There is no need to determine how much revenue was generated because of earlier delivery of solutions or increasing partnerships. Revenue measurement is very simple.
In the white paper referenced earlier I discuss four high level models for monetization with sub-models in each. These are: Free, Developer Pays (direct), Developer Gets Paid, and Indirect. Your business should explore all the models to determine which ones make the most sense for your API product offerings. The answer is most likely that several different models are applicable.
Since everyone wants to discuss direct monetization, we will dive a little deeper into some of the considerations with this model that I have not covered previously. Considering direct monetization, there are two key questions that need to be answered: 1) Should you directly charge for your APIs? And 2) How will someone pay you to use them?
- Should you charge for your APIs?
- Not every API provides value to a consumer. Many of them provide basic information, are promoting your offerings (which is value to you – not the consumer) or may just be a cost of doing business. Does your API provide value to the consumer? If so, then we may consider direct monetization.
- Who is it valuable to – the API consumer or their downstream customer? If it is valuable to their customer then do you want to own the relationship with this customer? If so, you might need to pay the API consumer as your agent - not charge them, to pass the customer on to you to do business. If you are charging the consumer then they have the right to manage the relationship with the end customer. If your API product is valuable to the API consumer then there may be an opportunity for direct monetization.
- Will pricing the API product cause the consumer to be reluctant to use your API? Is this something that they can acquire elsewhere? Will pricing the API decrease your access to customers? You may earn a small amount from API calls but reduce your overall revenue opportunity because fewer customers are engaged – making direct monetization a poor choice.
- What is the best metric for the direct monetization? Is the number of API calls the important factor or is the consumer value obtained by the API call different for various use cases? If the value is different then billing based on the value may make more sense than billing based on the number of API calls.
- If your API Product provides value and direct monetization makes sense, then let’s move on to the next question…
- How will someone pay you for your APIs?
- Is your API Product something a consuming developer will pay for themselves? Will your target developer audience have the authority to commit their company to do business with you? If so, then billing and payment systems such as Stripe or Braintree may be applicable and can be executed during the API consumption process.
- For many situations the developer is not the person with the authority to commit to a significant financial purchase. And corporate billing is not done by credit card or payment service. Your company needs to set up a mechanism to on-board a consuming company and set up a billing/invoicing arrangement prior to any API consumption. Then developers from this company need to be authorized to consume and use the APIs up to the agreed upon levels.
Ultimately the goal for almost all API initiatives is Monetization in the broad sense that crosses multiple modes from Free - to Indirect - to Direct. Business drivers as described enable additional revenue and cost savings. API Products are the approach used to simplify the API consumption that enables these business goals.
If you have questions, please let me know. Connect with me through comments here or via twitter @Arglick to continue the discussion.
Graphics courtesy of Pixabay.com – Mediamodifier, OpenClipart-Vectors, Mohammed Hassan, Geralt, and Rupixen