APIs securely expose digital assets and services that are of real value to end users and partners. Since they provide value to end users, it makes more sense to monetize the services and the APIs and build a business model for them. Having the right monetization model for APIs helps businesses reap the benefits of their investment in APIs. In this chapter, we look at the various API monetization models and how an API management platform can monetize APIs and open the doors to new revenue opportunities.
Which Digital Assets Can Be Monetized?
APIs share your data and services with front-end applications in an easy and scalable manner. With APIs, you can track usage and billing information in real time. But what kind of data or services can be monetized via APIs? Here are some examples:
Digital content such as maps, images, and analytical data are assets that developers are willing to pay to get access to
Digital services such as address verification, credit checks, messaging, and location services
Payment gateway providers charge a certain percentage fee for every payment transaction processed through their gateway
APIs facilitating the sale of products on an ecommerce platform
How to Increase Revenue Using APIs?
Now let’s look at how APIs can be used to increase revenue.
Increase Customer Channels
APIs expose enterprise services to third-party consumers. Developers build apps that consume these services via the APIs. These apps solve different business problems for different use cases. New avenues of customer interaction are opened up by these apps. Traffic through the APIs increase as more number of third-party applications are built and consumed. APIs can also be used by other applications for faster integration with your services. With this integration, additional traffic gets routed to services. Thus, with a variety of apps and newer integrations using APIs, the inbound traffic to your services continues to grow as they are used by end consumers.
To summarize, APIs can be used to increase the inbound traffic as follows:
To provide extensions to build apps that can be used by end users
To build a platform for integration on which numerous apps can be created and marketed
Using APIs to build a platform for integration takes advantage of the cross-marketing potential of the app economy. For example, APIs provided by Uber can be used by travel aggregators within their applications to book cabs and provide a completely integrated travel experience for customers. This helps the aggregator to provide a better customer experience and also brings in increased traffic and revenue for Uber.
The goal of an API provider should be to create a growing ecosystem of third-party developers who can build innovative apps using APIs that provide a richer customer experience. This helps multiply the chances of acquiring new consumers and increasing revenue. It also reduces business risks due to referral traffic brought in by other third-party apps using you APIs.
Increase Customer Retention
Customer retention is the next important factor in generating more revenue and profit. After a certain point, business coming from repeat customers is more than that from new customers. Hence, customer retention becomes a key to the success of your business. The more people use apps that rely on your API, the higher the market share for that type of API. After a critical mass of users using an app is reached, it becomes difficult for the third-party app developer to migrate them to another API provider. When end users become accustomed to your apps and APIs, it is even harder for competitors to beat you. Thus it becomes harder for uses to switch to the competition, which increases your retention rate. For example, Evernote is showcasing the work done by third-party developers in their app center. This promotes the work done by third-party developers and encourages users to build products using Evernote APIs. This increases user engagement and retention for Evernote.
As an API provider, you need to build a platform that grows the customer base and increases retention. Build APIs that are easy to use. A smooth and easy developer onboarding process with well-documented and easy-to-use APIs encourages more third-party developers to use your APIs. A well-designed developer portal aids the process. Happy and engaged developers who build good apps increase customer retention and company revenue.
Upsell Premium and Value-Added Services
Value-added and interesting API features can be made available at a premium to those who have purchased access. For example, a communication app may provide two-party voice services for free, but a multi-party voice conferencing service is available at a cost. Alternatively, customers may be charged after they have exceeded a particular limit. For example, the Google Maps APIs is available for free and with paid options. By default, Google Places API users get free access to 1,000 requests per day. Enhanced access requires credit card validation. This model attracts users to use the API and they pay for increased usage only if they see a value in it.
To use this model, the business should be well established in the market and have a good consumer base. Alternatively, the service provided by the API should be of high business value to the consumer.
Increase Affiliate Channels
As an API provider , sometimes it makes sense to turn third-party developers building apps using company APIs into an affiliate. With an affiliate program, the third-party app developer is also motivated to build apps for your APIs and drive more traffic. This promotes your APIs and drives additional revenue for the company. If any of the apps from the affiliate partners become successful, it can drive tremendous revenue to the API program.
A reverse model can also be adopted, in which the API provider becomes the affiliate for the app. As an API provider, you may want to showcase how various apps have integrated your APIs. From the showcase page, you may drive traffic to your partners and gain a finder’s fee for yourself. In this way, third parties help you with app development and joint marketing, and even pay you to drive customers to them.
Increase Distribution Channels
Often a company’s business depends on the number of people that get access to its contents and services. The greater the number of people interacting or using the content, the more revenue generated. In this situation, it makes sense to increase the number of distribution channels for its content. New distribution channels via APIs can be used to share the content. Smaller companies may use APIs provided by large API providers to access data and resources shared by them in a revenue-sharing model. For example, small travel companies may use APIs provided by Expedia and Booking.com to provide hotel information within their web sites. Expedia and Booking.com use APIs as a distribution channel to share the hotel information in a revenue-sharing model with others looking to use it. This model of content distribution helps the API provider increase their revenue though integration of their APIs into a third-party platform that needs to use their services. Smaller companies can quickly start their business by integrating these APIs into their platforms, while large companies providing these API gain from the additional business brought in through the integration of these newer distribution channels .
API Monetization Models
An organization’s data and services can be exposed and shared with partners via APIs. APIs extend the reach of an organization’s core assets and bring in new channels of revenue. The monetization model can be simple or complex depending on the value and use of the assets. However, they can be broadly classified into the following four categories.
Free model: This model is used when the organization has a set of lower-value assets that it wants to advertise through different channels and devices. This model can be used even when the asset has a high demand, but the organization does not yet have the budget to develop and market all use cases for asset use. APIs that provide information about a store branch, or a store location, or product catalog information are examples.
Fee-based model: This model can be used when the organization had assets that are of high value to the consumer. The consumer of this API is ready to pay for the value derived from it. The value to the consumer can be based on per use or based on the kind of data provided. APIs for payment processing, or credit checks, or that provide valuable analytics data are examples.
Revenue-sharing model: In this model, the organization shares revenue earned from the use of its service or product with the app developer consuming the APIs. This serves as an incentive for the developer to build apps for the API provider that can expand its customer reach. An advertising API is a good example. Developers can embed advertisements within their apps by using the advertising APIs. The revenue earned by the organization through advertisements served on these apps can be shared with the app developer. Revenue sharing can also be through an affiliate program. Affiliates get paid a share of the revenue as long as the customers brought in through their network programs remain customers of the API provider. For example, the Rdio affiliate program paid a cut of the subscription fee to their affiliates as long as the subscriber recruited by an affiliate remained a Rdio subscriber. The revenue sharing for an affiliate program can also be based on the type of service the subscribers sign up for.
Indirect model: In this model, the API provider and the consumer mutually benefit. For example, using Facebook and Twitter APIs provide an easy way to sign up users, which helps to continuously expand their consumer base.
The first three monetization models can be further categorized, as described in the next few sections.
Free Model
Free APIs are available for consumption at no charge to the consumer or the end user. Making APIs available for free drives adoption and popularity. As the adoption increases, the brand value of the provider organization goes up. This can also help the API provider expand into newer channels to increase customer reach. Facebook APIs are an example of free APIs. The company’s Like and Share APIs embed the Like and Share buttons into any web site or app. This helps Facebook expand its reach and enrich the company’s social reach and position. Facebook is a leader in the social recommendation space. As of 2015, Facebook had about 2.7 billion likes per day and around 2.5 billion web sites using its Like button.
The freemium model is a variation of the free model. The different variations are based on duration, quantity, or a combination thereof. In a freemium model, the API consumer gets to freely access the API for a certain duration or usage quantity, or a combination of both. Another approach to freemium model is based on the API’s features. With a photo API, the free model may provide photos with watermarks or in a lower resolution. However, a paid model may provide images with higher resolution without any watermark.
Duration-based free model: In this model, the consumer is not charged for API usage for a certain duration. For example, the consumer may sign up and get free access to the APIs for the first month and then be charged from the second month onward.
Quantity-based free model: In this model , the API provider provides free access to the API for a certain number of calls. For example, Pearson provides 5,000 API calls for free for its FT Press API. This means that the developer does not get charged for the first 5,000 calls, which gives them the flexibility to try out the APIs before they decide to buy. The Google Maps API provides geocoding services for free for up to 2,500 requests per day. So if a consumer app is making up to 2,500 requests per day, it continues to use the API for free, but has to pay if the daily traffic exceeds this limit.
Hybrid free model: In this model, the API provider combines duration and quantity with free access. The consumer is charged as soon as either of these thresholds is reached. For example, an API call can be free for the first 5,000 calls or the first 30 days. In this case, the API consumer is charged as soon as 5,000 calls are made or after 30 days have passed, whichever occurs first.
Fee-Based Model (a.k.a. Developer Pays Model)
An organization often exposes many assets of high value to its consumers. An organization assigns a price point to its digital assets that consumers are willing to pay to get access to it. For example, Amazon Web Services (AWS) provides a host of services, including storage, databases, computing power, deployment, and management options via APIs. Consumers are willing to pay to use these services rather than hosting them in their own data centers. A fee-based model is perfect for monetizing these assets via API. With a pay-as-you-go model, Amazon generated $750 million in revenue in 2011. NASA saved $1 million after it moved its IT assets to AWS. A fee-based model can be used to monetize APIs that provide access to such assets. Analytical data or payment processing services are examples. The fee-based model can also have different variations, as follows.
One-time fee: In this model, the provider charges the consumer a one-time fee for subscribing. The consumer then gets unlimited access to the APIs that she paid for.
Subscription fee: In this model, the consumer is charged at a regular interval—weekly, monthly, or any other period that the API provider chooses—for use of APIs. A subscription fee for a group of APIs is a typical example of this model. The volume of API calls allowed in a time period may be fixed or volume-banded, in which the subscriber pays for the excess use of APIs beyond the set limit.
Pay-per-API transaction: In this model , there is no minimum fee and the consumer pays for the number of API transactions made. AWS uses this model to monetize its APIs; developers pay only for what they need to use.
Pay by transaction volume: This monetization model is based on the volume of API calls made or the volume of data accessed or returned in the response. This leads to a tiered approach for monetization, in which the rate applied depends on the usage tier. Google charges its AdWords API consumers a certain fee for every 1,000 API calls.
Tiered pricing model: With a tired pricing approach , the consumer is charged different rates for different bands of API calls. For example, 0 to 1,000 API calls in a month may cost $0.02 per API call; whereas 1,001 to 5,000 API calls may cost $0.01 per transaction; and an even lower rate for more than 5,000 calls within the same time period. Typically, higher-usage band rates are less per call than lower bands. Charging lower rates for high-volume usage promotes developers/partners to use higher volumes. The API provider may also set other custom attributes for payment, such as the number of records accessed or returned in the response or the number of bytes/megabytes stored.
Revenue-Sharing Model
In a revenue-sharing model , the API provider exposes its digital assets with partners who sell them on their web sites and via apps. The provider shares a percentage of the revenue earned through the sale of these assets with the third party. Companies like Walgreens, Expedia, and Sears have successfully used this model to sell their products through third-party apps and web sites hosted by their affiliate partners. This model helps the API provider extend reach by expanding business through various digital channels, increase sales through affiliates, and reduce overhead cost with reduction in physical branches. There are various types of revenue-sharing models, as follows.
Cost per action (CPA): The API provider pays only when a specific action happens, such as a product is purchased or a video is watched.
Revenue sharing: The API provider shares a part of the revenue earned through API traffic routed from third-party apps. The revenue sharing can be as follows.
Fixed revenue share: The API provider shares a fixed percentage of the sales revenue earned.
Flexible revenue share: The API provider shares a variable percentage of the sales revenue earned through API sales. The percentage varies based on the volume of sales made over time.
One-time revenue: In this model , the affiliate partner gets a one-time referral payment for every subscribing customer routed through its web site or app.
Recurring revenue: In this model, the affiliate partner receives a recurring referral payment for every customer routed to the API provider through a web site or app until the subscriber remains a customer of the API provider. For example, Rdio paid their affiliates each time a new subscriber signed up.
In a revenue-sharing model , the API provider needs to generate periodic billing documents and apply a commonly used tax model to the generated statement.
Monetization Concepts
In order to set up monetization of your APIs, you need to be aware of the various concepts for API monetization. This section explains the basic concepts of API monetization.
API Product
APIs should be sold as a product that developers or consumers are willing to use and pay for. An API product is a collection of APIs. Related API resources can be bundled together into an ‘API product’ and published to the developer community. Developers sign up to use APIs in an API product of their choice.
An API provider can create different products by combining APIs for different use cases. So instead of providing all APIs as a list of resources, related APIs that solve a specific business need can be combined into separate API products. For example, in the telco industry, APIs for sending SMS and MMS and retrieving their statuses can be clubbed together into a single Messaging APIs product, whereas billing-related API resources can be combined into a Billing APIs product.
API products can also control access to a specific bundle of API resources. Internal APIs resources can be bundled into one API product, while external APIs can also be bundled into another product. API product attributes can also be used to limit the number of API calls allowed for a consumer within a given time interval. So, multiple API products can be created to club the same resources, with different limits set for each of them. For example a Silver API product might allow a consumer to make 1,000 API requests per day, while a Gold API product could allow unlimited API requests in a day. Another way to configure API products is to club APIs that provide read-only access to resources into a free API product, while APIs that provide read/write access to resources are in a paid API product.
Developers can register their apps and select one or more API product to associate with their apps. The API key associated with an app gets access to all the API resources available within the associated API product.
API Package
An API package is a collection of API products that an API provider wants to monetize. An API provider may create one or more API packages with different combinations of API products. An API package is presented to the developer, who selects the rate plan that they want to sign up for. One or more rate plans for monetization may be associated with an API package.
Rate Plan
A rate planspecifies the monetization approach of your APIs. It specifies how you want to charge developers for API usage or share revenue. The rate plan can be a prepaid or a post-paid plan with a charging model that is a fixed fee, or a variable fee, or a freemium model, or may even be customized for the developer. The rate plan depends on the model followed for monetizing the APIs. At the time of registration, developers select an active rate plan associated with the API package. If an API package does not have an associated rate plan, then developers can use the APIs within that package without any fee.
The rate plan can have an associated scope, which controls the availability of the plan to all developers, a select group of developers, or a developer category. This controls the rate plans, which a developer logged into a developer portal can view and select while registering an app.
A rate plan normally defines the following:
The name and a brief description of the rate plan
The developers (or the developer category) who can view the plan
The currency for payment of the rate plan
Frequency of payment for the rate plan, such as weekly, monthly, quarterly, or yearly
Payment due dates
Any recurring or setup fee information
Figure 8-1 below shows the relationship between the API Product, API Package and Rateplan.
Figure 8-1. Relationship between components for API Monetization
Billing Documents
Billing is another important aspect of API monetization. Once APIs have been monetized, it is the necessary to generate consumer bills at regular intervals. Some API management platforms provide an integrated billing solution that automatically generates billing documents such as invoices and revenue share statements at prescheduled intervals. These documents may be viewed in draft state before publishing to their intended recipients. An API provider may want to first make adjustments to the billing documentsto increase or decrease the revenue share or fees for a variety of reasons. API monetization also requires that the API provider manage credits, prepaid balances, and refunds. Credits can be provided by reducing the charge in the invoice or by reducing the usage count of the developer’s API traffic. API monetization should also allow the API provider to refund a developer’s purchase transactions.
Monetization Reports
Monetization without adequate reporting facilities creates havoc. API monetization should also be supported with reports that help reconcile the data, if required. The following are some of the reports that should be generated:
Billingreport: This report should provide details of the developer activities that are charged. The report could cover a single billing month or a configurable period.
Prepaid balance report: This report should provide a view of the balance refills that a prepaid developer has done in a month so as to be able to reconcile the payments received from the payment processor
Revenue report: This report should provide a view of the activities that result in revenue through API usage. It helps to analyze the performance and popularity of the API package across developers.
Variance report: This report helps to compare the activities and the revenue generated for two date/time ranges. It shows if there has been any upward or downward trend in API usage.