Practice successful monetization API based on Azure API Management
Hello!
Today we want to discuss the topic of management API. When it makes sense to open your API, who has the ability to monetize your API and how to implement a management API system so that the costs, both for initial implementation and for its operation, are minimal.
We want to share our experience in developing an API management system based on Azure API Management. Let's start from the beginning.
1.1. When to open API?
If you understand that your data, content or unique business logic may be useful to other companies and people - the API can be opened.
')
Once you understand that your APIs help your users grow their business, you can offer access to the API for a fee.
If you have few users, you can provide access and collect fees manually. And if a lot, you probably need an API Management system. (API Management system).
1.2. Why do you need API Management system?
In short, we can say that the purpose of the API Management system is to turn the API into a product, i.e. provide purely technical substance with real business content. Most API Management systems, at present, can do the following:
Our customer is a large meteorological company, a large part of whose business is in the provision of paid data from meteorological stations. A few years ago, she was one of the first in the industry who also decided to open and provide her APIs for free. And at the moment it offers customers 14 types of API products, differing in which API sets are included in the product, and what limit on the use of the product set is set.
To understand the scale of the project, currently the customer API is used by 4200 developers, 2400 companies.
Our joint history is the third attempt of the customer to implement the API management system for the successful monetization of their services. The first time was a solution based on Mashery, the second time Apigee, and then Azure API Management. As usual, in the Russian tradition, from the third time, as a rule, everything works out. It happened that way.
As a result, we essentially made a custom API management solution, in which:
2.1. And what was wrong with the first two?
We need to start by saying that the company chose market leaders Mashery and Apigee both times. And after a year of use they left each of them. It sounds strange. Are these leaders ?!
In fact, the requirements for the API management system can be summarized in two main points:
And it is precisely in these parameters that the system leaders were not accepted by the customer.
2.2. Cost of use
The monetization scheme of Mashery did not allow us to obtain a predictable estimate of costs in advance, and they very quickly became very high.
The cost of using Apigee with the built-in payment system was immediately just space and in fact took away all the proceeds from the sale of the API.
I must say, Azure APIM does not have a built-in payment system. At first glance it seems that this is a huge minus, however, after the negative experience with integrated payment systems, which turned out to be expensive to maintain, the customer appreciated this as an absolute plus.
2.3. Ux
In addition, customers admitted that they thought the Apigee UI was too complicated and confusing. For comparison, we present the logical architecture of Apigee and Azure API Management:
As you can see, the architecture of Azure API Management is simpler. It has fewer objects. Therefore, it is easier for administrators and users to understand.
The architecture of our solution looks like this:
3.1. At the heart of everything is the identification and subscription management (EM) system.
It operates with the following objects:
3.2. The user interacts with it through the portal interface (EM Web Front). Azure API Management manages access to a set of our APIs.
The main objects here are:
Azure Management API - from the technical side, represents the WEB-proxy, which is presented to the user and redirects calls to the appropriate API on the Backend side, taking into account the application.
3.3. The APIM block allows you to painlessly map users from EM to users in Azure.
3.4. Separately allocated universal payment processing unit - Payments, which so far supports recurring payments (Recurring Payments). So far it is integrated only with PayPal. In the future, it is planned to connect Apple Pay and Google Pay here.
As a result, the user is currently on the portal at a time:
The subscription management system in real time receives payment data and activates access.
The user and developers from his organization have access to the Developers Portal, which has documentation and examples of using the API.
Let's be honest - any “ready-made” platform, when meeting with a real business, usually requires some work. Although the out-of-the-box functionality provides all the necessary basic tools that you can and should use to test your business ideas.
While users are few, you can control access to the API by manually taking the product out of the box without costume modifications.
In principle, all the steps are clear enough:
The subscription scheme for providing Azure API Management in this case is very convenient - it allows you to test the concept without significant financial investments in the API Management system and integration.
And suppose that there are more users. Our client has over 4,000 active subscribers. As you understand, the amount of manual labor for synchronizing and providing / disabling access becomes frankly high. However, we also receive more money from the sale of API access, and now we can invest in automating these steps:
If you are just thinking about whether or not to provide paid access to your API services, the Azure API Management subscription scheme allows you to quickly and easily verify your business concept.
When there is an understanding that there is enough demand for your API, a custom solution based on Azure API Management will allow you to provide:
Today we want to discuss the topic of management API. When it makes sense to open your API, who has the ability to monetize your API and how to implement a management API system so that the costs, both for initial implementation and for its operation, are minimal.
We want to share our experience in developing an API management system based on Azure API Management. Let's start from the beginning.
1. LIKBEZ. WHEN YOU NEED TO MANAGE THE API
1.1. When to open API?
If you understand that your data, content or unique business logic may be useful to other companies and people - the API can be opened.
')
Once you understand that your APIs help your users grow their business, you can offer access to the API for a fee.
If you have few users, you can provide access and collect fees manually. And if a lot, you probably need an API Management system. (API Management system).
1.2. Why do you need API Management system?
In short, we can say that the purpose of the API Management system is to turn the API into a product, i.e. provide purely technical substance with real business content. Most API Management systems, at present, can do the following:
- To organize access to the API.
- Define API usage policies (completeness of requests, their frequency and limit per unit of time).
- Provide API documenting tools.
- * Organize paid access to the API based on policies.
2. NOT ALL SYSTEM MANAGEMENT SYSTEMS EQUALLY USEFUL
Our customer is a large meteorological company, a large part of whose business is in the provision of paid data from meteorological stations. A few years ago, she was one of the first in the industry who also decided to open and provide her APIs for free. And at the moment it offers customers 14 types of API products, differing in which API sets are included in the product, and what limit on the use of the product set is set.
To understand the scale of the project, currently the customer API is used by 4200 developers, 2400 companies.
Our joint history is the third attempt of the customer to implement the API management system for the successful monetization of their services. The first time was a solution based on Mashery, the second time Apigee, and then Azure API Management. As usual, in the Russian tradition, from the third time, as a rule, everything works out. It happened that way.
As a result, we essentially made a custom API management solution, in which:
- Integrated Azure API Management with a client identity and subscription management system.
- Provided a single login to work with the customer portal and portals Azure API Management.
- We made payment via PayPal and CRM integration with SalesForce.
2.1. And what was wrong with the first two?
We need to start by saying that the company chose market leaders Mashery and Apigee both times. And after a year of use they left each of them. It sounds strange. Are these leaders ?!
In fact, the requirements for the API management system can be summarized in two main points:
- cost of use
- UX, and UX as user and administrator
And it is precisely in these parameters that the system leaders were not accepted by the customer.
2.2. Cost of use
The monetization scheme of Mashery did not allow us to obtain a predictable estimate of costs in advance, and they very quickly became very high.
The cost of using Apigee with the built-in payment system was immediately just space and in fact took away all the proceeds from the sale of the API.
I must say, Azure APIM does not have a built-in payment system. At first glance it seems that this is a huge minus, however, after the negative experience with integrated payment systems, which turned out to be expensive to maintain, the customer appreciated this as an absolute plus.
2.3. Ux
In addition, customers admitted that they thought the Apigee UI was too complicated and confusing. For comparison, we present the logical architecture of Apigee and Azure API Management:
As you can see, the architecture of Azure API Management is simpler. It has fewer objects. Therefore, it is easier for administrators and users to understand.
3. ARCHITECTURE OF OUR SOLUTION
The architecture of our solution looks like this:
3.1. At the heart of everything is the identification and subscription management (EM) system.
It operates with the following objects:
- Organization and its users (Authentication).
- Subscription product catalog, including API products.
- Subscription (Authorization) - the relationship between the user and the product.
3.2. The user interacts with it through the portal interface (EM Web Front). Azure API Management manages access to a set of our APIs.
The main objects here are:
- An API is a logical entity representing your API.
- Policy - restriction on the use of API. For example, the number of requests per month or the amount of data transferred.
- The user - in the most frequent case, is a developer who will use your API in his application.
- Subscription - a bunch of user with the product.
Azure Management API - from the technical side, represents the WEB-proxy, which is presented to the user and redirects calls to the appropriate API on the Backend side, taking into account the application.
3.3. The APIM block allows you to painlessly map users from EM to users in Azure.
3.4. Separately allocated universal payment processing unit - Payments, which so far supports recurring payments (Recurring Payments). So far it is integrated only with PayPal. In the future, it is planned to connect Apple Pay and Google Pay here.
As a result, the user is currently on the portal at a time:
- selects one of three sets covering all 14 possible API products,
- selects a tariff that determines the allowed frequency of requests and the total limit of requests per month,
- proceeds to payment.
The subscription management system in real time receives payment data and activates access.
The user and developers from his organization have access to the Developers Portal, which has documentation and examples of using the API.
4. WHEN NEED POSTAL AUTOMATION?
Let's be honest - any “ready-made” platform, when meeting with a real business, usually requires some work. Although the out-of-the-box functionality provides all the necessary basic tools that you can and should use to test your business ideas.
While users are few, you can control access to the API by manually taking the product out of the box without costume modifications.
In principle, all the steps are clear enough:
- Synchronize user lists in Azure API Management and EM systems.
- Sync products in EM and related products in the Azure Management API.
- On the EM portal, we link to PayPal to purchase a subscription.
- When you receive a message from PayPal - we start a subscription in the EM - system, as well as the corresponding subscription in the Azure Management API.
- When the subscription expires, we remove the user from the subscription in the Azure API and EM systems if payment has not been made.
The subscription scheme for providing Azure API Management in this case is very convenient - it allows you to test the concept without significant financial investments in the API Management system and integration.
And suppose that there are more users. Our client has over 4,000 active subscribers. As you understand, the amount of manual labor for synchronizing and providing / disabling access becomes frankly high. However, we also receive more money from the sale of API access, and now we can invest in automating these steps:
- To synchronize user lists in Azure API Management there is a delegation mechanism. When you log in to the developers portal, it allows you to redirect the user to our portal, from where he returns already authorized. Details described azure.microsoft.com/en-en/documentation/articles/api-management-howto-setup-delegation
- Next, we write a special service that allows you to map products in Azure API Management with products in the EM system catalog.
- As well as in the manual mode, on the EM portal we redirect to the PayPal website to purchase a subscription. Here we set up the possibility of recurring payments.
- The next task is to make a subscription when passing a payment. PayPal - can send a payment confirmation notification in the form of a call to our service, in the EM system. This service, gets, subscription in EM, and broadcasts changes in Azure API Management. The message handler starts a subscription using the Azure API Management Rest API: msdn.microsoft.com/en-us/library/azure/dn776325.aspx
- And finally, after the expiration of the subscription of the user must be removed. For this, in the EM system we added the attribute “expiration date” to the subscription. And all we need to do is write a JOB, which periodically checks the subscription validity period in EM, and blocks access to Azure API Management.
5. TOTAL
If you are just thinking about whether or not to provide paid access to your API services, the Azure API Management subscription scheme allows you to quickly and easily verify your business concept.
When there is an understanding that there is enough demand for your API, a custom solution based on Azure API Management will allow you to provide:
- Ease of management. The architecture of the Azure APIM platform allows you to manage the API as easily as possible.
- Deep integration of the server side with the portal.
- Flexible integration with external customer-friendly payment systems.
- And, of course, the economic efficiency of paid API provision. In our case, in comparison with Mashery, permanent bones have decreased 10 times! Yes, there were one-time project development costs. And the client deducts the payment system a commission from each operation. But it already costs from profit. Which finally appeared.
Source: https://habr.com/ru/post/303738/
All Articles