Rolling out API Monetization for a Philippines Telecom Giant with Drupal-APIGEE

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.

Understanding Teleco Concerns and Expectations

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:

• A unified and well-architected API programme to allow the client to expand into other avenues faster than before
• An organized API product strategy with an at least 6-18 months outlook, that allows for better-planned release cycles and innovative business models
• Standardized infrastructure and ops for resilient architecture, platform security, and cost savings
• Empowered API teams that can work in an efficient and optimized manner and help migrate selected APIs to the Apigee platform.

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:

Unifying Segmented API Initiatives

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.

API Monetization

The primary objective for client’s API program is to ensure effective monetization for existing and new APIs. To achieve this, Srijan worked to:

• Build an API “store” and developer/provider ecosystems and marketplaces
• Orchestrate a host of monetization and working business models around Developers, Publishers & Consumers
• Create high level rate plans with respect to APIs or API products
• Setup API governance and gateway telemetry to record transactions
• Create an API portal as the touchpoint of monetization experience - with cart/checkout and other eCommerce idioms

Building a Federated API Platform Architecture

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.

Understanding and Optimizing Runtime Ops

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:

• Enhancing the infrastructure stack with container management platform, to declaratively manage scaling, resilience, etc.
• Finding ways to progressively externalize platform features from the microservices so as to make them stateless
• Creating document SOPs and operational processes, R&R so that this stack can be managed by client’s in-house or L2 support tier

Building a Developer Portal on Apigee

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.

• In house lab APIs

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

• In house lab ReDoc

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

• In house lab SmartDocs for an API

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.

• Developer Dashboard

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 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.