With a successful API monetization strategy, enterprises can expand their business capabilities to new customers through the rapid consumption of business assets.
However, with APIs offering dozens of ways to monetizing data, content and technology, it can become overwhelming for enterprises to deal with the entire process.
In this blog post, we’ll take you through the technical knowledge needed to build a robust API monetization platform for a Philippines Telecom Giant, which seamlessly drove new opportunities and broadened their marketplace.
The Philippines Teleco Giant, with an estimated market capitalization of 3.8 billion USD and a subscriber base of almost 67 million, is the leading solution provider in regional market.
It has a programme running on Apigee aimed at expanding the ecosystem and effective productization for increasingly complex APIs. The client was seeking out to create a prototype for API monetization.
We helped them achieved the following key goals:
Srijan initiated the process by formulating a transformation plan - understanding current and required capabilities, and objectives to be achieved. By evaluating the present state of each of these aspects, we arrived at the immediate or future challenges they might pose in client’s API program. The next step was to chart out how to mitigate those challenges, and that became the blueprint for the transformation plan.
Here’s how:
In house labs and the Apigee API platform were working as separate initiatives, which if continued, would dilute the effectiveness of the API program. It would lead to two different source-of-truth and cross-program governance would be complicated and inefficient.
In order to prevent this and build a unified API platform, Srijan worked on migrating the existing APIs into Apigee, in the first phase. This also involves industrializing the Apigee layer to showcase the range of new APIs and business models that are possible.
The primary objective for client’s API program is to ensure effective monetization for existing and new APIs. To achieve this, Srijan worked to:
As the API program expands, an API platform becomes a must. Srijan is helping the client create a federated API platform for internal and partner APIs. This is mainly to handle cross-cutting concerns like authentication, authorization, configuration management, messaging brokering etc. In the absence of a singular platform, these functions have to re-developed or internalized for each API, leading to significant duplication of time and effort and mis-governance.
Srijan proposed a full audit and introspection of runtime operations and setting up baseline observability & telemetry stack, to help teams understand how things work. Post this, the next steps were:
A platform was built which could help the client to ideate, develop, and take feedback within planned timelines, with the ability to create new revenue models with an offering for both service providers and end-customers while vastly cutting down development time and costs.
Srijan teams built a unified developer portal which made APIs available to developers to communicate with the actual data in microservices through an Apigee API platform.
The Apigee platform ensured secured use of APIs and acted as the intermediate between developers and the microservices.
Architectural diagram showing communication between developers/admin and microservices
Now, let’s understand the features of the project and the various related terminologies.
The developer portal renders several APIs which can be public, private and internal. These are then implemented on Apigee. The screenshot attached below shows a comprehensive list of Public APIs available to an anonymous end user.
Developer portal exposing various APIs for developer use
ReDoc offers a customizable and incredibly nice theme. It is actively maintained by its developer team to offer a better user experience. It has a custom script written for better readability of a developer.
Here’s the sample doc rendered for:
1. Request
2. Response
SmartDocs comes as a part of the Drupal-based Apigee dev portal. It provides smart documentation for an endpoint along with a tryout feature so the developer can tryout the endpoint on the page itself.
A logged-in developer on the developer portal dashboard can choose to create a new app, go to the apps transactions page or see the wallet balance.
1. Developer App
Screenshot of creating new app interface
A developer can create an app by giving it a unique name, with a particular API product(s) and a callback URL. He/she can select different API types (which are basically API products on APIGEE which gets synced to dev portal) by simply selecting the check boxes.
In case of Consent App, a 'Consent' is a prompt when a subscriber sees while opening an app. The app accesses the list of permissions marked selected by the subscriber.
2. Developer Wallet
Developer can add balance to their wallet via online/offline transfers. The wallet is categorised into two types: prepaid and postpaid.
A developer can have any wallet (prepaid or postpaid) and can even be switched from one to another upon request. The developer will have SMS MO balance attached (see the image below), show the credit/balance history of the transactions done.
3. Navigate Transaction page
The transaction page displays the transaction types and the related balance details.
Screenshot of Transaction page interface
Admin OperationsAdmin does the configurations to communicate between different layers in the entire system. Micro services implement the automated processes across the system wherever needed.
Micro services consists of all the APIs which does any internal operation in the system, and the response is brought back to APIGEE and then to portal/developer App.
Srijan is working with leading enterprises across the US, Europe and APAC regions, assisting them with their API lifecycle management with Apigee - creating and exposing APIs and building custom developer portals. Contact us to get started with your requirements.