API Product and API Monetization

A free video tutorial from Rajeev Sakhuja
11xAWS Certified, Consultant, Mentor, Innovation evangelist
Rating: 4.5 out of 5Instructor rating
8 courses
112,371 students
API Product and API Monetization

Lecture description

Students will learn about the good practice that states "Treat your API like a product if you would like to sell it like a product". 

Also the student will understand the

  • concept of monetization
  • various monetization models
  • technology considerations from the realization perspective

Learn more from the full course

REST API Design, Development & Management

Learn the REST API Concepts, Design best practices, Security practices, Swagger 2.0/OAI, Hands on API Management

07:35:14 of on-demand video • Updated August 2020

Design and Develop RESTful API by applying the best practices & REST constraints
Create practices for API security, versioning, lifecycle management, documentation and other important aspects
Write specifications in Swagger2.0/OAI specifications in YAML format
Create an API management strategy for your enterprise
Leverage some of the common API management platforms for building API proxies (APIGEE, IBM API Connect, Mulesoft Anypoint)
English [Auto]
E-product and monetization. In this lecture, I'll cover a good practice that states that you must treat your API as a product. I'll also cover the API monetization models and the technology considerations around rolling out the monetized APIs. Let's start with the definition of a product. A product is anything that can be offered to a market that might satisfy the need or want of the customer. API fits this definition very well. Let me give you an example today. Application developers are looking for ways to build some cool advanced communication features in their applications so they have a need and the need is fulfilled by a company called Twilio. They offer advanced communication APIs that the application developer can easily integrate or use in their applications. For example, video conferencing, SMS, texting, chatting. All these APIs are available from Twilio because there is a demand for it. Another example is the Amazon Web Services. Amazon Web Services fulfill the infrastructure needs of the application developers. Both these organizations are selling API as a product. Let me give you an example of another organization that has nothing to do with technology but are still treating their APIs as product. This is the Capital One Dev exchange portal. Capital One offers some great APIs to the developers for free. Their goal is the generation of indirect revenue and brand recognition. As you can see, their website looks nowhere near a typical dev portal and that is the marketing aspect. They also have a community built around their API and they also offer other support channels and I believe they have a dedicated team for the API for continuous improvement and enhancements. So the Capital One is not only calling their APIs API products, they are treating them as products. Bottom line is that to sell an API as a product, you need to treat the API like a product. Let's dig a little bit deeper into what I mean by treating a API like a product. Let's say you are a car manufacturer and you would like to release a new model of your car in the market. In order to do that, you'll have to follow the typical product life cycle, which is. First, you need to create a business case to justify the need for a new model and how your company will make money by releasing this new model. Second thing you'll need to do is carry out some research. Who is going to be the target customers for this new model and what are their needs and wants? Next thing is you will dedicate some resources, create some teams who would build this car model. And then there is marketing. You would make sure that the new car model is promoted to the target segment in the best possible way, and then you will launch the car and be ready for the post-launch support. Now, this was about the creation of a new car model. Let's see how the same cycle can be applied to the creation of APIs. So treating the API like a product, like a car would mean that we will have to follow the same steps for planning and releasing that we followed for the car from the business case perspective. You need to come up with a reason why the organization should release an API. Is it for new revenue? Is it for brand awareness or is it for new partnership models? Or they may be other reasons why you may want to do it. Once you have a good business case, the next thing is research. Who is going to be the consumer for the API? What is their need and wants? And why would they use your API? What kind of an incentive would you need to provide in order to make them use your API? After the research comes the creation of the API. The typical delivery and planning and some kind of a pilot to ensure that you're moving in the right direction. Next thing is marketing. So how would the consumers come to know about your apps? It is not possible to just create the APIs and expect consumers to start using it. You have to do something about the marketing also. So some examples are you can generate some buzz with events such as hackathons you can promote by way of blogging, maybe even press release and paid advertisement launch. And post-launch in this, you have to think about how you're going to launch your APIs. So example is you can create some cool application on using your APIs and release it to open source. And then post-launch you need to think about how you're going to support the application developers for your APIs. Bottom line is that you have to treat the API like a product in order to sell it as a product. So typically the data and services are exposed as API, and this API can be sold as an API product to the developers to generate direct or indirect revenue. So this is the API monetization where you are generating revenue by selling the product. Let me give you an example of direct and indirect revenue. Salesforce.com and Amazon.com charges their customer for the use of their APIs and that's the example of direct revenue. They're getting the money from the customer, whereas Capital One and BestBuy, they are not getting any revenue generated by way of selling the APIs directly to developers. But revenue is generated when the developers are using the APIs to promote their services or to sell their merchandise. There are multiple monetization models. I'll go through some of the common ones. First one is the free and the free model. The API provider offers their API for free to the developer community. These are the examples Facebook, Twitter, LinkedIn by way of these free APIs, they are expanding their reach, they are expanding their brand recognition. So that's the reason free APIs are very commonly available for social platforms. Next is the freemium model and the freemium model. The API provider creates tiers of product, and the first tier is the free tier that the developer can use for free, obviously. And the premium tiers are paid tiers and the developer who is using the free tier can anytime switch to the premium tier. Google Maps, IBM, Watson, Apigee are the examples that use the freemium model for their APIs. Next one is the enterprise Pays model. In this model, the organization offering the APIs pays the developer to use the API. For example, Amazon Associates, Amazon Associates are the developer who are using these APIs in their application to sell Amazon products, and if they are able to make the sale from their apps, then they get paid by Amazon. Same thing is true for eBay and Expedia. Last one is the developer pays. Now the developer pays, as the name indicates here, the developer is paying the provider organization for their use of the API. There are a couple of models under this one. First one is pay as you go Amazon Web Services. You can use the services offered by Amazon and then depending on what you use, you get a monthly statement. Next one is subscription model. Subscription model is you pay a license fee for certain number of users or certain number of licenses. And that's the subscription model. Salesforce is an example of that. And then you have transaction based model in which the developer pays per transaction. For example, PayPal and other payment services like Stripe, they use this model. So till now I have discussed the business aspect of monetization. Now let's go through some technology consideration aspects that as an API provider you'll have to keep in mind. First is how would you create the tiered product definitions? Fortunately, almost all API management products support the concept of products and plans which allow you to create these tiered definitions for the products usage metering. How would you measure the usage of the APIs by specific developer subscription manager and show that there are no overages and ways by which you can handle those overages reporting? There has to be some kind of reports to be generated for the business as well as for the consumers of the API. In order to support the indirect revenue model, you'll need to track your partners and also track the revenue generated by your partners. Unfortunately, the kind of features you need for monetization. Are not available out of the box on most of the management platforms, but a number of these management platforms sell these add on modules for moderate monetization. Let's summarize in this lecture. I covered the product and monetization. If you want to sell your API as a product, you must treat it as a product. Monetization is about business and technology. Once you have decided to monetize your APIs, you need to decide on a business model and then you also need to think about the technical aspects to support the business model that you have decided to go with.