Cloud Thought Leadership White Paper

API Monetization – Understanding your Business Model Options

2 API Monetization – Understanding your Business Model Options

Contents

2 Executive Summary

3 Introduction to API Monetization

5 API Monetization Options5 Free6 Developer Pays8 Developer Gets Paid9 Indirect

10 Closing Thoughts and Recommendations

HighlightsAPIs aren’t new, but their uses are rapidly driving new opportu-nities for businesses, developers and customers. Dive into how a variety of business models can be implemented to drive API monetization.

Executive summaryEnlightened businesses are recognizing a new channel to market through APIs. Just as the internet expanded the reach of busi-nesses through a new channel that allowed businesses to expand beyond their physical location, APIs are allowing businesses to

expand beyond their enterprise boundaries to drive revenue through new business models potentially using other enterprise’s resources as additional channels to market.

The API Economy allows access to business assets through a simple to use API (Application Programming Interface). Technically, this is accomplished by exposing the API to an audience, securing it, and controlling the consumption of the asset. From a business perspective, it enables extending the reach of our business capabilities through rapid consumption of our existing business assets. Access to the assets is provided via APIs enabling new and innovative usage of the assets to drive additional revenue. This is referred to as API Monetization.

In this paper we focus on the business models for API Monetization. We describe 4 groups of API models: Free, Developer Pays, Developer Gets Paid and Indirect, with many sub-models described for each. For each model we explain the model and provide existing examples of companies that are executing that model.

The paper also provides initiative guidance / considerations and a recommended project approach to implementing API Monetization in your enterprise.

3Cloud

API Monetization Options

APIs

Free Developer Pays

Pay as you go

Developer Gets Paid Indirect

Freemium

Tiered

Points Based

Transaction Fee

Revenue Share

Affiliate

Referral

Content Acquisition

Content Syndication

Internal - Consumer

Internal - non-consumer

B2B - Customer

B2B - Partner

Business Expansion

Figure 1. API monetization models and variations

Introduction to API MonetizationSimply, API Monetization is using APIs to make money. To some, this means that API usage is priced so that there is a direct correspondence between the use of an API and someone paying for that use. This certainly is a mode that fits the defini-tion. However, it is not the only one. In some business models (e.g. Insurance agents, Auto sales) an agent is used to sell your product and the agent is paid to do this. APIs can also be used in this manner and paying someone to use the API to sell the product is another pattern that uses APIs to make money. However, in this model instead of someone paying you for the use of the API, you pay them to use it. (See Figure 1)

Another business model that is often used to drive revenue is advertising/marketing. In this model there is not a direct pay-ment, but the advertising may bring a potential customer to you where you can establish a business relationship and frequent interactions that are far more valuable than a single interaction. APIs can also be used in this indirect monetization model.

Our discussion of API Monetization includes both Direct payment models and Indirect models that drive revenue.

4 API Monetization – Understanding your Business Model Options

The API Economy value chain has three participants:

●● API Provider—the API provider chooses which business assets to make available as an API, under what terms and conditions (the API Monetization approach), and is responsible for driving the success of the API.

●● API Consumer (Developer)—the API Consumer is a devel-oper who uses the API under the designated terms and conditions to supply something (e.g. an App) to the End User.

●● End User/Customer—the End user does not directly see the API, but benefits from its use in the App that is provided.

If API monetization is to be successful, then all three parties must benefit from the use of the API. An example of a poor API Monetization strategy might be where the API Provider would like to charge for the use of the API (they obtain value), but there is no clearly defined need on the part of the API Consumer to pay for this usage. A positive example would be an API that performs a customer credit check, being used by a Bank to initiate a mortgage for a Customer. In this case, the API

is valuable to the consumer (the bank) and they would be willing to pay to use it, while the end user is also obtaining value as they are able to obtain a mortgage loan to purchase a house.

In considering API monetization, there are a set of questions that should be considered:

●● Is the asset valuable or is exposing the asset a cost of doing business?

●● Who is it valuable to—the API Consumer or End User?●● Do you own (or want to own) the customer relationship or

does the API Consumer own the relationship?●● Will pricing the asset cause the API Consumer to be reluctant

to use your services and will this decrease your access to customers?

●● Is the API Consumer working on your behalf (i.e. should you pay them)?

●● Is there a tiered structure that makes sense based on usage (e.g. lower utilization free to obtain market presence)?

Answering these questions can help lead you to the appropriate method of monetization to be used.

Business AssetsExposable

services

Web APIs Developers Apps End UsersProvide access tobusiness assets

Use APIs tocreate apps

Connect to thebackend via APIs

Provide newvalue and drive

revenue

APIs apps

API Provider API ConsumerEnd User/Customer

Figure 2. The API economy value chain

For monetization to be successful, value must be obtained by all participants in the API value chain (See Figure 2):

5Cloud

It is possible that all three participants in the value chain could be in the same company. In this case, monetization might be in the form of internal charge backs or “showbacks” to account for the usage. Perhaps one line of business using assets provided by a different line of business in the same company.

Another possibility is that the developer is in the same company as either the API Provider or the End user. If the developer is in the same company as the API provider, then this is an internal consumption use case where that developer might be creating an App (e.g. mobile app) for the company which is made available to customers (end users) who might transact business with the company. So, monetization through the App is a possibility, but there will not be a direct charge to the developer for the API use, since again this is internal.

If the developer is in the same company as the end user (but not the API provider), then this is a business to business (B2B) type scenario where one business is accessing resources from another business and potentially using it inside their company to auto-mate business processes. An example of this might be supply chain automation. Again, monetization is possible in this sce-nario with one company paying for the assets enabled by the API from the API Provider.

It is also possible that all three participants might be in separate companies. The API Monetization options described below cover all these scenarios.

I would like to acknowledge work done by John Musser, Founder and CEO at API Science on API Monetization models (http://www.slideshare.net/jmusser/j-musser-apibizmodels2013). This paper builds on his prior work

API Monetization OptionsThe API Monetization Options are divided into 4 categories: Free, Developer Pays, Developer Gets Paid, and Indirect.

FreeObviously, given the title of this option, there is no direct exchange of money in this scenario. So, why are you making the API available under this option? Possible reasons could be:

●● Drives Adoption of APIs●● Typically low valued assets●● Drives brand loyalty●● Enter new channels

While no money is exchanged clearly there must be a business purpose. It could be a cost of doing business such as supplying product information, advertising, etc. An example of a free API is the Facebook login. Facebook supplies this API and many other companies use this to identify end users. Facebook does not receive direct revenue for these API calls, however this is a benefit to Facebook as a company. Consumers may choose to

6 API Monetization – Understanding your Business Model Options

sign up for Facebook for the convenience of using this logon elsewhere. Facebook can also understand usage patterns which can provide additional value.

Developer PaysIn the Developer Pays scenario, the business asset being exposed through the API must be of value to the Developer. The Developer may obtain downstream revenue through its use. An example in this category is a credit check API which might be used by developers in many businesses to ensure that their customer is credit worthy for the scenario they are pursuing (e.g. car purchase, real estate purchase, personal or business

loans, etc.). The Developer Pays scenario has several sub- models: Pay As You Go, Freemium, Tiered, Points Based, and Transaction Fee.

●● Pay As You Go—this is a very simple model. Developer pays for what has been used—no minimums, no tiers. It is usually billed periodically (e.g. monthly). It may be necessary based on the scenario to provide some capability for the developer to try the API before buying (perhaps in a sandbox environment). Examples of this style of monetization are IBM Softlayer or Amazon Web Services.

●● Freemium—Basic features are free, with higher value features priced (with one of the other pricing models). Examples include: Compete and Dropbox. (See Figure 3)

Figure 3. Dropbox pricing is an example of a freemium model

7Cloud

Figure 4. Constant Contact is an example of a tiered model

●● Tiered—Multiple tiered options provide higher levels of resource access. A developer chooses the tier they believe they need and pays for that level of access. This is similar to the old mobile phone plans where you purchased a certain number of minutes per month. Typically tiers are based on the number of API calls, but other factors could also be used. The lowest tier is often free to allow a developer to try the API. The Developer is billed for their selected tier level whether they use the entire amount or not. Usually tier limits are enforced to drive purchase of a higher level tier if additional access is required. It is also possible to offer a higher fee if the selected tier level is exceeded but this increases complexity. Examples include: Vertical Response, and Constant Contact. (See Figure 4)

Operation: getCount: 53 ad groupsService: AdgroupAdService

API request Operations counted towards Daily Limit

1

1

10

2Operation: mutate (ADD)Count: 2 ad groupsService: AdgroupAdService

Operation: mutate (ADD)Count: 10 campaignsService: MutateJobService

Operation: getCount: 100 targeting ideasService: TargetingIdeaService

Figure 5. Google Adwords is an example of a points based model

●● Points Based—Different API features or APIs have different value and are assigned a number of points. The developer either pre-buys a number of points (like tiers) or is billed by number of points used (like pay as you go). Example of this style is Google Adwords. (See Figure 5)

●● Transaction Fee—A fixed or percentage of a transaction is paid to the API Provider. Examples include: Stripe and PayPal.

8 API Monetization – Understanding your Business Model Options

Figure 6. Expedia is an example of a revenue share model

Developer Gets PaidIn the Developer Gets Paid scenarios, it is in your best interest as the API Provider if someone uses the API. That is, the value is to you if this is used, so you provide a monetary incentive for a developer to leverage your web API. Typical scenarios include you selling an asset through an agent, for example insurance through an insurance agent, an automobile through a broker, etc. The Developer Gets Paid scenario also has several sub-models: Revenue Share, Affiliate, and Referral.

●● Revenue Share–In this model the developer (API Consumer) is acting as an agent to help sell a provider product/asset. A fixed or percentage of a transaction is paid to the API Consumer (i.e. commission). Examples in this model include Car comparison sales (e.g. Cars.com) and Travel comparison sales (e.g. Expedia) as API consumers with car dealers, hotels, airlines, etc. supplying the APIs to access their available offering options via this channel. (See Figure 6)

●● Affiliate–In this model a partner includes your content/advertisements to drive potential customer traffic to you. This type of relationship has several possible sub-models: impressions, clicks, engagement, or action/acquisition. So, based on how engaged the end user becomes with your advertisement different payments could be made (was it just placed on the page or did the user click on it?). Examples include: Google Adsense, Amazon.com, HSN, and Expedia.

●● Referral–Referral is similar to Affiliate but paid only when the customer purchases the item. Payments can be one-time or recurring. Examples include: Insurance companies and agents, streaming music services, or job placement (e.g. Monster.com)

9Cloud

IndirectIn the Indirect models, use of an API achieves some goal that drives the business model. Reasons include: increased awareness of specific content or offerings, internal use cases to speed time to market, regulatory requirements, customer retention, and others. There are several Indirect sub-models: Content Acquisition, Content Syndication, Internal—Consumer, Internal—Non-consumer, B2B Customer, B2B Partner, and Business Expansion.

●● Content Acquisition—APIs allow for content submission by 3rd parties which attracts customers to you. The Indirect revenue opportunity is through advertising or monetization of your assets. Examples include: YouTube, EBay, and Twitter.

●● Content Syndication—APIs allow third parties to distribute your content. Multiple financial models may surround this. You might create a contract between parties—outside the API integration using one of the following models: Subscription, Freemium, Marketing (free), and others. Examples include: Yelp, NY Times, Huffington Post, and Twitter.

●● Internal—Consumer—APIs are used by your employees to build customer facing capability for your company. Typical scenarios include creating Mobile Apps and Web Commerce sites. You might also use this to integrate to devices (e.g. Cable box, security system for home, intelligent home controls). Since this is internal usage, typically there are not direct charges. There may be chargeback billing or accounting (showback) transactions. Examples include Twitter, Netf lix, Citibank, and many others. Note: as these are internal, links are not provided.

●● Internal—Non-consumer—APIs are used internally to assist in productivity, time to market, meeting regulatory require-ments, strategy/architecture requirements, or managing domains (cross-geography or cross-Lines of Business). Typical scenarios include providing simplified secure access to systems of record, managing asset usage through secure access and rate limits. Monetization may include chargeback billing/account-ing for cross-LoB usage, or usage tracking and accounting for actual usage of internal assets. The most common use case is Cross-LoB asset sharing. Additionally, in some industries there are regulatory requirements to restrict asset visibility which can be achieved in this manner as well.B2B Customer—APIs are used by your customers to integrate to your enterprise. Customer value is provided through the use of the API so they are incented to use the API. For you, this facilitates customer retention, since they are program-matically connecting to your enterprise capabilities. Customers using your APIs considering changing to alternate providers could be costly as your systems are integrated. Typical scenarios include B2B ordering, commercial financial interactions, check inventory, shipment status. Examples include Walmart, Commercial Banks, and many others.B2B Partner—APIs are used by your partners to integrate to your enterprise. This is used to increase existing partner relationships or expand to new partners and geographies through rapid partner on-boarding. The model can also be used after a merger/acquisition. APIs can be used to access Systems of Record from both companies and provide a common User interaction layer across the companies quickly. Deeper integration may follow, but the customer experience of the merger/acquisition can take place faster. Examples include Government agencies sharing information and Retail/Shipping partnerships.Business Expansion—APIs are used to: expand into new geographies or new demographics, offer new products or upsell new capabilities to existing clients, or promote aware-ness of business capabilities to potential clients. Examples include Facebook ads and YES Bank (India).

●●

●●

●●

10Cloud

Closing Thoughts and RecommendationsWe’ve covered quite a few methods or monetization. So, is that all that there is to consider? No, of course not. In addition to thestyle(s) of monetization, there are several other issues/factors to be addressed or considered:

●● On-boarding/set-up charges●● Additional billing factors: payload size, value, response codes●● Credit/Debit●● International Currency●● Taxes●● PCI Compliance●● Invoicing/Billing●● Refunds●● Audit●● API Consumer Profile Management

Monetization is very attractive to the business and many API initiatives are started or funded based on the ability to monetize assets. If you have a valuable asset and you have worked through the value chain and found that all parties benefit then you shoulddefinitely monetize it! But don’t be penny wise and pound fool-ish. If you will earn more through customer acquisition than charging for an API call, then Indirect monetization is the betteroption. Consider both direct monetization styles and indirect styles in your portfolio of APIs. Not every API should be priced.

Beware complex pricing—if you are difficult to understand/deal with, API consumers will go elsewhere. You should definitely start simple. But, different APIs may need different pricing or pricing might vary by audience. So, add variation as needed, but carefully. Remember developers always need some way to try your API and test their code before paying. So, set up free usage levels or Sandbox methods to allow developers to test their code with your API.

To get started with monetization for your API initiative—Plan, Execute, Analyze, and Iterate. First understand what your busi-ness goals are for the initiative and the monetization options you might use. Evaluate the value chain for the API(s). Do all parties benefit? What is the monetization opportunity, and what is the best approach?

Second, execute the initiative. Set up the infrastructure for mon-etization and test it. Promote the API! “If you build it—they will come.”—does not work. You need to market the API to the target audience and continue to interact and support the API consumers.

Third, analyze how the initiative is working. Understand what is working well and what can be done better. Take feedback from the consumers and the asset owners. And finally, iterate and make the necessary adjustments.

API Monetization is an important focus for many businesses starting API initiatives. IBM can help you achieve success with your API initiative including monetization providing end to end knowledge and skills from strategy through implementation. Contact your local IBM representative for more information.

For more informationTo learn more about the API economy, please contact your IBM representative or IBM Business Partner, or visit the following website: ibm.com/middleware/integration/en-us/api-economy.html

Additionally, IBM Global Financing provides numerous pay-ment options to help you acquire the technology you need to grow your business. We provide full lifecycle management of IT products and services, from acquisition to disposition. For more information, visit: ibm.com/financing

11Cloud

About the authors

Alan Glickenhouse – API Connect Business Strategist glick@us.ibm.com @ARGlick

Larry England – Distinguished Engineer – Client Technical Leader for Anthem englandl@us.ibm.com @englandl

Alan Glickenhouse is a Business Strategist on the API Connect offering management team. He joined IBM in 1981 and has held numerous positions including Sales, Technical Sales, Marketing, Development, and Technical Support. On the API Connect team Alan assists clients with their business strategy for APIs, understanding their business direction, existing environment (both business and technical) and helps businesses successfully adopt an API strategy that fits their environment. Alan meets with many clients in all industries, all geographies, and of all sizes. He brings a capability to communicate at both the business and IT level with his clients and is able to explain both how and why a business will benefit from IBM solutions.

Alan has an A.B. from Vassar College in Computer Mathematics and has several SOA certifications.

Larry England is an IBM Distinguished Engineer at IBM’s Silicon Valley Lab in San Jose, California. He is currently the Client Technical Architect for Anthem (a large US HealthCare Payer). Prior to the CTA position, he had architectural responsibilities for application development tools on System z. England has worked in a number of areas during his IBM career including, VM/370, MVS, Language Environment, Multi-Media, Text search and retrieval, Database Management systems, and PL/I and C/370 Runtime and Test. He is also an IBM Master Inventor at the 7th plateau.

England has a BS in Mathematics and Computer Science from University of Illinois, MS in Computer Science from Oregon State University, and post-graduate work at University of California Santa Cruz. When not working at IBM, he can be found running a trail in the California hills.

© Copyright IBM Corporation 2016

Software Group Route 100 Somers, NY 10589

Produced in the United States of America April 2016

IBM, the IBM logo, and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml

This document is current as of the initial date of publication and may be changed by IBM at any time. Not all offerings are available in every country in which IBM operates.

THE INFORMATION IN THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT. IBM products are warranted according to the terms and conditions of the agreements under which they are provided.

KUW12387-USEN-00

Please Recycle