This is the first in a series of articles which explore network API pricing and why the simple question “What price are telcos charging for network APIs?” does not have one simple answer.
Early movers have some reference pricing for the most mature network APIs
One of the most frequently asked questions that we receive following the recent publication of our network application programming interface (API) monetisation forecast is: “What price are telcos charging for network APIs?”. This is a topic we have had to grapple with extensively in our forecast, as we modelled the opportunity for 18 network APIs bottom-up across 42 use cases over the 2023 to 2030 period. It is not unusual to see transparent prices upfront on websites for x-as-a-service API providers in other domains and with some telecoms communications platform-as-a-service (CPaaS) providers, so how hard can it be to give a straight answer?
Network APIs enable a developer to retrieve information via a telecom operator’s network or provide control over the network services they consume. They go beyond APIs that simply deliver communications products such as SMS or calls (these come under the CPaaS umbrella), but rather leverage the network as a unique source of information or offer instruction of it.
Few telcos or would-be network API aggregators have nailed their colours to the mast with public pricing for anything but the most mature network APIs with close proximity to the existing CPaaS market. In particular:
- There are early offers from telcos on the Azure marketplace for some CAMARA-compliant identity APIs, such as SIM swap or number verify, whose price ranges between US$0.04 and US$0.07 per call.
- The same identity APIs may be available on some CPaaS platforms (e.g., Vonage) but with no public pricing information on these specific APIs.
- Nokia has gone furthest, giving specific prices per call (around US$0.01 without bulk discounting) for location and device status API calls. For quality-on-demand, Nokia has some pricing for its credits system, but does not define these credits or tie them to usage (at least not publicly).
It is useful to point to these early reference points, but these are far from the complete answer. There is only fully transparent public pricing information for the identity APIs that compete directly with the CPaaS one-time password services, or one-shot APIs whose consumption model is easily conceptualised. Nobody has yet tackled how to price the more transformative network performance or edge APIs. The other unknown is what discounts are actually applied to these public prices and how pricing effectively used in commercial agreements deviates from public pricing.
The APIs with the earliest pricing information available are in line with the maturity profiles of the different API families in our modelling:
Figure 1: Average maturity profiles of network API families
Source: STL Partners network API monetisation forecast
Beyond issues of maturity, answering the question “What price are telcos charging for network APIs?” is further complicated by the fact that, despite its simplicity, it usually hides at least three preconceived assumptions behind it:
1. Network APIs will be charged per call.
2. All of the underlying service value is attributable to the API.
3. The value of an API is determined by supply.
In this article series, we will unpick and challenge these assumptions in turn because we think that they rely on misconceptions that might create severe barriers to realising the network API opportunity.
Assumption #1: Network APIs will be charged per call
To price an API, it is necessary first to define the unit to be used: US$ per what? We grappled with the possible units extensively when we designed our network API monetisation forecast model. This is not as simple as it seems.
APIs are often talked about in terms of calls. An API is a form of communication between a user requesting some information or an outcome from a provider, so the analogy to calling is effective. And indeed, charging per call works for APIs with a narrowly-defined purpose: for example, with a location retrieval API, the user asks “What are the geographical coordinates of the device associated with this SIM card?” and the provider returns the requested coordinates or a response indicating that this is not possible to retrieve. However, this simple one-to-one relationship between calls and the desired usage or API outcome is not applicable to all the network APIs we have modelled.
First, different calls to the same API do not always carry the same value, as this can depend on other factors, such as time or level of demand. This is particularly applicable to network APIs that enable premium services, such as 5G-enabled hyper-precise location, slice configuration, or quality-on-demand. Here, the API triggers the start and end of the service, so the pricing model cannot rely on calls alone and needs a per-second component. Additionally, an API-like quality-on-demand can have variants in terms of service levels or tiers, such that not all seconds of use are priced equally. In our network API monetisation forecast model, we consider three flavours of quality-on-demand with defined bandwidth or latency profiles and prices that depend on network conditions such as congestion.
Second, achieving a desired outcome of a network API may require multiple calls to that API, or calls to several APIs. For example, we have an “edge mobility” API in our model that is slightly different to the edge discovery API defined by GSMA, CAMARA and others. Our version extends it beyond a discovery service, which only identifies the logically closest edge node for a requested endpoint, to include the other operational APIs needed to migrate a workload over to the identified node. We decided to define this edge mobility API in our model because the real value to the developers gets realised not just by looking for the nearest node but when the edge service at that point is spun up. The point at which the API drives revenue is therefore shifted to the successful outcome of a string of further processes and API calls and this does not correlate with the number of calls of the initial API. The concept we are using here is that of outcome-based pricing models, which are different to the per call transaction models that have so far been assumed for APIs.
We have found that per call seems to be the assumed unit when we discuss network APIs with telecoms industry players and, for the reasons listed above, this is not the most appropriate unit in many cases. For a number of APIs, it is not clear what the appropriate standard unit should be, or if there needs to be a standard, so giving a typical price for some APIs is difficult. But more fundamentally, there is the question as to whether network APIs should be conceptualised as a volume-based product at all. Doing so would turn network APIs into a commodity, and bring with it the risk of price erosion that telcos absolutely want to avoid (though it may be unavoidable for the most basic and transactional APIs).
There are hints in the industry of alternative business models for network API commercialisation that do not go down this road, including the aforementioned outcome-based pricing models, but this involves shifting how value is attributed or realised and challenging the concept of APIs as a product with a fixed price tag.
In the next article, we will continue to unpick the remaining assumptions.
Download this article as a PDF
Do you want to know more about our research in this area?
Read more about Enterprise Platforms
The new Ericsson joint venture (NewCo): an important piece of a complex puzzle
Our view is that overall, this is a positive move for the industry – and a smart one by Ericsson, but there are still a lot of other pieces of the puzzle that have to fall into place.
Network API pricing: How long is a piece of string? (Part 2 of 2)
This article provides an assessment of where the market is to date post-MWC Barcelona, and what telcos can do to accelerate the opportunity.
Telco APIs and Open Gateway: You can’t make an omelette without breaking some eggs
This article provides an assessment of where the market is to date post-MWC Barcelona, and what telcos can do to accelerate the opportunity.