Network API monetization – how hard can it be?
APIs unlock new potentials in connectivity standards, innovative solutions, and new partner ecosystems. This also opens the possibilities of new business models and revenue streams for CSPs and enterprises.
How can businesses capitalize on network APIs? While the challenges are evident, the reward for successful initiatives is invariably greater. We evaluate some of the key considerations for forward-thinking strategies & the clear benefits of network APIs.
When I listen to the market on network APIs, monetization is not really talked about much. Maybe this is because it appears so simple – you count the number of API calls, right? I believe this is a mistaken view and things are somewhat more complex. Or maybe it is because API development is led by the technical side of the business and monetization just is not the number one priority – yet without a solid commercialization strategy, APIs will not be a sustainable business.
Let’s look more deeply at the two questions; how and who to charge.
There are many ways that API usage could be charged for. At the simplest end, you could charge for each call being made. An example would be to request the location of the device; so, you make an API call and are charged a fee. But what if the device is turned off or not on this network, do you still charge? Also, what if you have a subscription for a maximum number of calls in a day and you exceed this, what is the charging policy? And what about five API calls for a location or one API call with a list of 5 devices? Typically, API gateways offer this simple approach which I believe does not really meet the need.
At the more complex end, you may charge for outcomes. Many API calls may be made to set up a high-quality service and connection, and these would likely not be charged for. However, what would be charged for is the service they establish, say a dedicated slice, or the duration of a service that operates at a requested higher quality level. An example of this is an airline ticket purchase scenario where you use APIs to select and order a ticket, and you do not pay for the API calls made, just the ticket price. I believe this will become a very common approach to charging. This would also support scenarios where the API is an item in a bigger service bundle.
Who should be charged is not always simple. An example could be where an end user, uses an application that makes an API call – who is charged? Is it the subscriber because they selected the option in the application, or the application vendor because they embedded the network aware feature, or is it the aggregator that sat between the application and the telco? Further to this, sponsors may take a share of certain API charges. As is the case for traditional data, voice, and messaging services, roaming API charges will also be important.
And let’s not forget that the same API at different volume levels may be charged in different ways. Say an individual’s occasional use of a location API to locate a phone, versus an enterprise taxi service’s high-volume usage of the same location API.
Despite all this talk about monetization, we should not forget some of the internal benefits of having well-defined APIs for the network. They will enable automation and create a layer of loose coupling between the telco business and network systems. This will help to drive efficiency and agility within the telco’s IT systems estate. It is worth remembering that it is unlikely that there will be charging for this type of API usage.
With so many charging choices across many different APIs, who is best placed to determine the approach? I think the network team should be focused on rapidly creating innovative APIs that could be released, and that they should not be determining monetization approaches and levels. The telco service product managers should take on this monetization and API packaging challenge in a uniform way across the telco, just like they have for the other services the telco sells.
Today it is unclear which specific network APIs will be popular, which specific applications will become heavy users, or which specific user communities will be paying for the API usage. What is clear is that the service provider will need to have in place a flexible approach to API charging and API bundling. And that a rich & agile monetization capability will be critical in being able to establish a strong revenue stream from network APIs.
