With the rise of digital transformation, API based business models are getting popular across the globe. In this context, it is important to generate revenue from APIs for the betterment of your business. This is where API monetization comes into play.
Read the articles below and discover how you can transform your APIs into consistent revenue generation streams.
When we get comfortable with what we are doing, we get better at doing it. However, when we get better, we focus only on the things we do well, ultimately distancing ourselves from what’s happening out in the world. Unless we look back and think about additional avenues we can explore, before long, we’ll be taken by surprise, leaving ourselves far behind in the competition.
During an event to announce Microsoft’s acquisition of Nokia, Stephen Elop, Nokia CEO, ended his speech by saying “we didn’t do anything wrong, but somehow, we lost”. Nokia had been a great company and had not done anything wrong; however, the world had changed too fast. Many organizations repeatedly make this mistake, surprisingly, often, even industry leaders do this. If you feel you are in a similar situation, feeling stagnated in the traditional business model, and are
If you haven’t thought about APIs until now, then, it’s time to do so. APIs can be one way to disrupt your business and open doors to a whole new market.
The API economy was just a buzzword sometime back, but not anymore. Now, it's becoming a key part of any organization and the driving force behind agile businesses and digital transformation. APIs are becoming the lifeblood of many businesses as they unlock the hidden opportunities in today’s digitally transformed business arena. All industry verticals are reaping the benefits of APIs, irrespective of business domain or size.
A recent Information Age article [1] shows how modern, digital businesses use APIs as a key revenue stream—e.g., Salesforce generates 50% through APIs, eBay generates 60%, Stripe generates 100%, and Expedia generates 90%. In addition to generating direct revenue and accelerating go-to-market, APIs help organizations achieve the following.
To enjoy these benefits and boost business growth, an organization must first ensure that all of its employees are completely aware of the advantages of an API based business. A good understanding of different API revenue models helps organizations to come up with unique ways of generating revenue from APIs.
Business APIs are mostly offered by companies with a revenue model based on supplying and selling access to their APIs. Typically, these APIs provide specialized services for application development. These can be anything from simple data storage to AI-driven financial advice, which can be used to enhance the capability of applications and user experiences.
Adopting a widely used, proven monetization model will ensure that you can maximize a company’s business revenue in a very short time. Being aware of these models will be beneficial to stand out from the competition. Let’s take a look at some of these well-known, widely used models; these can be adopted right away to maximize API-based revenue.
The pricing usually scales up with the usage of the API but is not limited to that. When talking about monetization models, there are a number of models to select from. To see a more comprehensive list, refer to this talk by John Musser (please see video). After many iterations and trials, only a few monetization models really work well in the API domain.
One of the most common models is a subscription-based model. Here, the consumer has to pay a fixed amount for a certain period of time. There may be multiple subscription plans for exposing a single service. Service owners can decide the plans and rates when they are exposing them to the consumer base. On the other hand, consumers can choose the best possible plan, according to their requirements and budget.
The other model is usage-based payments. In this model, the service provider specifies a rate per API request. When a consumer is utilizing that service, he or she pays based on the usage. In other words, this is also known as a pay-as-you-go pricing model.
In addition to that, indirect revenue models can be implemented without directly charging per API usage. An example would be an e-commerce platform. In this case, charging per API usage does not make sense because when items are sold, both the seller and the selling platform will generate profit.
Some organizations mix these business models and come up with their own business models such as freemium, where they charge for additional features consumed. If we consider previous e-commerce examples, we can think about exposing price forecast APIs with some value additions. While users can consume other APIs free of charge, they have to pay for price forecast APIs. That is one example of a unique revenue model we can create. Similarly, we can generate hundreds of different revenue models based on the use case and domain.
The growth of artificial intelligence machine learning forces us to
Free artificial intelligence-driven APIs are offered by companies in exchange for data they receive from the consumers using them. While you may not get direct revenue from the API, you will be collecting data and improving your models. So, free APIs are not really a burden for organizations with this model. Google’s Cloud Vision and Image Search APIs are examples. Most of these APIs are free to use, and, with the provided data, they will train their models to improve accuracy.
API monetization allows organizations to transform their business capabilities into managed APIs, which generates revenue. To utilize the true power of managed APIs, business stakeholders need to have a clear idea and vision about the API economy. *Note that the primary focus for API gateway-only solutions, which are centered around the system gateway runtime, are not in this domain. Most API management solutions support API monetization. When we consider API monetization capabilities of such products, the ability to integrate with existing billing and usage metering systems is important as it eliminates most of the complex implementations. Moreover, this will help you to reduce the effort of development and spendings because you are using already available solutions. Most of the time, organizations have profile management and self-care portals. When API monetization is introduced to an already-running system, this integration needs to be seamless.
Free and open-source WSO2 API Manager supports API monetization and allows users to generate revenue out of their APIs. Users can implement different API monetization models such as pay-as-you-go, subscription-based usage, etc. It comes with the ability to integrate with Stripe by default, as well as extension support to integrate with any other billing system.
In this post, we have discussed the importance of the API-based economy, how it can assist to increase revenue, and the proven monetization models. We also discussed the advantage of utilizing API monetization within an organization. If you are interested to read more about how small businesses can take advantage of API monetization, please read this article about Boost Revenue with These Four API Monetization Models.
To have a call with a WSO2 technical account manager and see how you can utilize these concepts within your organization, please contact us . We will walk you through some case studies related to your domain and plan a unique solution that suits your requirements.
API monetization enables organizations to advance beyond their business borders and seek new ways to generate revenue through new business models. While there are many API monetization models to select from, choosing the right one is equally important as rolling out APIs; the model you select is critical for your API strategy’s adoption and growth. Out of the many models, we’ve selected the following due to their wide adoption and availability. Find out how to implement them and boost revenue.
In this model, the developer is charged per each single request made. Providing an option like a sandbox environment (where charging doesn’t apply) is useful as the developer needs to test the application before hosting it in production. Since pricing only applies to the exact usage of the APIs, this saves developers from large upfront payments.
This is another popular model, where you offer free access to the API either with restrictions on the quota or on features offered while providing advanced features and quotas for a price. One good example of this would be Google’s Speech-to-Text API, which provides up to 60 mins/month of free API access. Higher quotas are available at a price per unit of usage.
If you are transitioning from a totally free mode to a paying mode, or if you still need to promote API adoption by giving an option to experiment with the API, you can use the freemium model. Another reason would be if you are targeting different user groups, such as individual users and enterprises. While keeping the free option to individual users, the offering for enterprises can be given for a price.
In this model, higher levels of resource and feature access are provided through tiers. This is similar to postpaid mobile plans, where different plans provide different talk times and data bundles are offered at different rates. An API can be offered with different tiers, where the tiers differ by the quota they allow and the features they offer. Developers are usually charged based on the plan they subscribed to, even if they don’t fully utilize the quota allotted for that tier. For example, AccuWeather, which provides APIs to receive location-sensitive weather information, offers multiple tiers that differ by the number of calls allowed and the richness of information it provides. The company charges a standard subscription fee based on the tier.
If you are launching your APIs for the first time, and looking for ways to promote them, then, offering them for free would be the best model to go with. Unless you are providing a clear value addition, attaching a price tag would only stagnate the adoption of your APIs. If you are new to the API business and still discovering the benefits, then, chances are that you’ll be rolling out newer API versions frequently. While these experiments are necessary for business growth, it would still disrupt the consumer experience, which would be only justifiable if APIs are offered for free.
Unless you identify and measure the business value generated, your API program will become wrongly categorized as a cost and will dwindle midstream. So, it is equally important to audit your free APIs similar to how you would monitor and evaluate those you would charge for. The following are some common reasons businesses use free APIs; if your requirement matches any of the following, you can first think of giving free access to your APIs.
The models we discussed above are only a handful out of the many you can choose from. The one that best suits your API strategy depends on the nature of the services you provide and the purpose your consumers use them for. Especially if you are rolling out your APIs anew, it might take a while to figure out the model that suits you the best.
Having the right toolset to manage your monetization strategy is as important as the model you select. You will see greater adoption from the developer community when your APIs become more informative and interactive. Fostering a larger community will, in turn, help you to grow a thriving business around APIs. So, having a platform that fully exposes your API capabilities is key.
The platform should ideally have strong analytics components to measure success and provide actionable insight, flexible features to implement new customizations, and in-built monetization capabilities. While an in-house solution would work for a small number of APIs, it will become a bottleneck as the numbers grow. If you have plans on advancing your business through APIs, you should invest in a standard API management product.
To learn even more about managing the full lifecycle of an API—including creating, publishing, monitoring, and monetizing—head over to WSO2 API Manager or contact us.
From our extensive experience in the API management space, we see that digital-driven organizations are now continuously seeking creative ways to monetize services and assets through APIs. Within this context, API monetization has a broader meaning than simply charging for APIs; in our experience, most companies want to charge for API usage.
WSO2 API Manager 3.0.0 provides first-class support to monetize APIs. It gives the flexibility to plug in any billing engine, and out-of -the-box the product integrates with Stripe—which is a service that allows individuals and businesses to make and accept payments online. Keeping up with market demands, API Manager 3.0.0 supports two widely popular models to charge consumers (i.e., application developers).
A fixed amount is charged from the application developer at the end of the billing cycle, where a certain number of calls are allowed per month. Irrespective of whether they use these or not, they will be charged.
Subscription-based charging can be further broken down into two models. Freemium and tiered pricing.
In tiered pricing, different request quotas can be sold for different prices. For example, when implementing this model, you can create three tiers: Bronze, Silver, and Gold. They can be priced at USD50, USD100 and USD150, which would offer bundles of 1000, 2000, and 3000 requests per hour.
When it comes to the freemium model, you offer a free tier with a stringent limit on the request quota and a paid tier that offers a higher quota. The freemium model allows you to introduce a free tier, with 100 requests per hour. Depending on your requirement, you can choose to either block the additional requests or continue the flow when the quota depletes.
Price is calculated based on the number of requests made. This model is also known as a “pay-as-you-go” model, where there’s no fixed payment. If the pricing is set at USD 0.01 for a single request, and then if 1000 requests are made during the month, a user would be charged USD 10. There is no fee if no requests are made.
With the 3.0.0 release, WSO2 API Manager supports monetization as a first-class feature. This is achieved by leveraging the strengths of external billing engines, such as Stripe, for billing and collecting, while relying on WSO2 API Manager’s capabilities to gather and publish usage data.
If you are familiar with these features and are excited about trying them out, you can download the latest product from here and start following the doc. However, if you find the document too technical, this article aims to provide a more high-level overview, explaining the need for different configurations and how certain features in Stripe are used while implementing billing.
WSO2 API Manager seamlessly integrates with Stripe. With only a few configurations, the product takes care of creating Products, Plans, and Subscriptions needed for billing.
WSO2 API Manager publishes usage data while Stripe performs billing and collecting.
WSO2 API Manager uses Stripe to manage interactions between API providers and Consumers. From Stripe’s perspective, WSO2 API Manager operates as a platform. Therefore, as a part of the configuration, an admin for WSO2 API Manager needs to create an account and configure it as the platform account. API providers would also have to create accounts in Stripe and link it with the platform account using Stripe Connect, which gives the ability to the admin to charge consumers on behalf of an API provider.
When charging for API usage, two parties are involved: the API provider, who hosts the API and who is responsible for the upkeep and management of the API, and the API consumer, the party that uses the API. API consumers would use an API through an application. In a typical paying scenario, API consumers would pay API providers for using the API. We use features like accounts, customers, and subscriptions available in Stripe to depict this relationship.
As the first step of configuring, the admin needs to create an account and configure it as the platform account. API providers would also have to create accounts in Stripe and link it with the Platform Account using Stripe Connect, which gives the ability to the admin to charge consumers on behalf of the API provider. The section on Configuring the Billing Engine provides details on this.
Once you have done the configuration, you can start charging for APIs simply by creating billing plans. You log into the admin portal and create a billing plan, filling in details such as how much you need to charge and what charging model you need to follow. You can also specify the request count and whether to block the invocations once the allotted quota is depleted.
Refer to the section on Creating a Subscription Policy for more details on this.
Creating a subscription-based billing plan on WSO2 API Manager
While creating billing plans, you get to choose whether you are going to charge for the subscription or charge per request. But, based on how you engaged the billing plans, you can provide a freemium model or the tiered pricing model.
Then, API providers would log into the publisher portal and select the billing plans they want to enable. While saving the API, they also have to provide an ID that maps the account at Stripe’s end. By this point, you have created an API that can be charged for.
This is covered in detail under Enabled Monetization.
Applying billing plans for an API
To use these APIs, application developers (API consumers) would have to log into the developer portal and subscribe to those. There are a few additional steps, such as entering payment methods and billing information, but, finally, application developers will be charged based on the plan they subscribe to.
For more details look at Subscribe to a Monetized API.
Now that the basic configuration has been done, let’s consider how charging happens. Even before billing was introduced, WSO2 API manager had the framework to gather usage data and aggregate them according to different requirements. When billing is enabled, the same underlying framework is used to gather usage data. Such gathered data will be published to Stripe in a pre-defined frequency.
This section gives you more details to publish data on Stripe.
If you are interested in seeing a live demo, please contact our marketing team to request one. Or else, if you are excited to try this out yourself, you can download the latest version through this link
DOWNLOAD >You don’t need to understand the internal details about billing to make it work. However, if you are interested about what happens underneath or want to understand the internals with the aim of customizing the flows, this section tries to shed more light on how different elements in Stripe are used to implement billing.
We use the following features/elements available in Stripe.
Product - Represents a real-world product or a service. A single product can be defined with different pricing plans.
Customer - A party who uses a product. In order to proceed with charging, billing details need to be provided.
Subscription - Before using a product or service, a customer needs to subscribe with a pricing plan.
When creating a billing plan through the admin portal, a corresponding pricing plan will be created on Stripe. This will be created via the Platform Account (the account created by the Admin), so that the plans are available to different API providers.
And then, the API provider can enable monetization and select a plan for the API. When doing this, a matching product with the API’s name will be created in Stripe;the selected pricing plans will be added into the product. These products are created in the API provider’s account. Recall that when configuring, we had to specify the connected account ID, which is used in this case to create the products and add pricing plans on behalf of the API provider.
Next is the part performed by the API consumer (or the application developer). When an app developer logs into the dev portal and creates an application, a matching customer object is created in Stripe. So, for each application created, there would be a separate customer object, bearing the payment details specified by the API consumer.
At the time of subscribing to the API, a subscription will be created on Stripe, under the product corresponding to the API, with the billing plan selected. This ensures that the API accesses are charged according to the billing plan as usage data is published.
There’s something to be said about publishing usage data. While the requests flow through the gateway, relevant billing plans and associated data get pushed to the analytics nodes. Now, analytics would summarize this data by different time intervals and update the DBs. But until an explicit command is run to push this Data, Stripe will not receive any updates about the usage. Depending on how frequently you run the billing cycles, you can schedule a job to push usage data.
We hope that you got a good idea about the new monetization feature and how WSO2 API Manager integrates with Stripe. If you have any questions on Monetization or in general about API Management, feel free to contact us through https://wso2.com/contact/.
