This is the second in a series of two 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.
This is the second article in a series of two which addresses an often-asked question: “What price are telcos charging for network APIs?”. In the first article, we explain why per-unit pricing for network APIs may be applicable for some but not all APIs and why moving to outcome-based pricing models will help telcos in particular extract the most value out of exposing their networks. In this article, we explore the validity of two other frequent assumptions behind many questions about network API pricing.
Assumption #2: All of the underlying service value is attributable to the API
Telcos are still thinking of network APIs as a product to be monetised, with a stream of revenue directly attributable to their commercialisation. In reality, the API is more of a connection or access point to a wider set of services and capabilities with which to create value. The API connection does have value, but the broader service also has its own value, which the value brought by the API is only a part of. This point is probably one of the reasons why the network API monetisation forecasts available vary so widely: some have attempted to attribute a portion of the revenue that APIs could potentially “unlock” back to each API while others, including ourselves, quantify only the value that the API itself brings or adds to a service (we call this enablement value in our model), rather than the value of the whole service.
Defining how much value to attribute to the API in a broader service is hard, and depends on several factors:
- How essential the API is to delivering the broader service (i.e. if there are alternative delivery methods).
- The extent and interconnectedness of other technical features of the service that make it hard to disentangle the precise value of the network API in question.
- The broader customer context, such as whether the API is paid for standalone or within the context of another service (such as a private network).
Based on these factors, the amount of overlap between an API function and the underlying service it enables exists along a spectrum.
Figure 1: Spectrum of overlap between API function and underlying service enabled
At one end, the API connection and the service itself are so intrinsically linked that it makes sense to equate the two. For example, it is hardly possible to conceive of an anti-fraud SIM swap check being provided in any other way than via an API call, and calling this API is itself the service that is being charged for. Unsurprisingly, these are the APIs that are most mature and their monetisation models are easiest to grasp: all revenue is attributable to the API, which is in effect a product. But even for those “simple” identity APIs, the commercial model and value associated with it may vary depending on the context in which it used. For instance, a one-shot location check API would typically be billed by the call in an anti-fraud service (same as the SIM swap just mentioned). But the same API could be used in an industrial use case, for instance for asset tracking on a site with a private network. In this circumstance, the enterprise would pay for the API as part of, not on top of, the bill for the overall private network solution. The API benefits this solution and can have theoretical value allocated against it to reflect this (we call it enablement value in our model) but it does not come from any price list as such.
Similarly, the edge mobility API mentioned in our first article enables an edge computing proposition which exists separately from the API in question, i.e. with or without the API, the edge computing service will work, but it will work better if the API is available. Most of the value sits in the edge computing service and the API adds some incremental value by improving the delivery of the service. So, the API has an attributable value even if in practice there is unlikely to be a specific monetary flow between the telco and the solution developer for the API itself (i.e. it will be included in the overall bill for using the edge node, same as in the private network API mentioned before). Defining this enablement value, i.e. to what extent a premium connectivity service relies on an API as a mode of delivery is a subjective exercise.
Another example where judgement is needed to decide what value to attribute to the API, when it is part of a service with other technical components, would be network slicing: there will be an API that facilitates the spinning up/down of the slice itself, in our model this API is network slice configuration, but network slicing will need more than the API to function, i.e. custom integrations, setting up of dashboards, etc. In our forecast, we only consider the value which can be allocated to the network slice configuration itself, and not the non-API-led aspects of the network slicing service, even though these would also generate revenue for the telco. So there is a mental exercise required to disentangle the value of the API from the value of the rest of the service it enables.
In fact, even in the CPaaS anti-fraud world, there seems to be a move away from seeing each API as a self-contained product with a set price. This is certainly how we interpret Vonage’s lack of individual pricing for, say, SIM swap and number verify, while it publishes pricing pages and calculators for more traditional CPaaS APIs. Indeed, Vonage describes its number insight service (part of its protection suite) as a combination of tools to “identify phone numbers […] assess risk, prevent fraud, block fake accounts, and increase acquisition”, with SIM swap listed as one of the technical capabilities underpinning this. That even the most productisable APIs are being considered enablers to broader services may indicate the direction network API commercial models are (should be?) taking, i.e. what needs to be envisaged is the value that the API contributes to the overall service, rather than seeing the API as a commodity billed per unit.
Within telcos, network APIs also need to be considered for the value they bring in the delivery of use cases. We are seeing telcos with dedicated API teams or units. This is a welcome move as long as these initiatives do not result in siloed programmes that consider each API as a product line with its own P&L. If network APIs remain independent revenue-generating products, the bigger picture of revenue enablement that APIs bring may be missed: some APIs will be more profitable than others but they may support each other to create more value (or indeed make a use case possible) so culling one because it does not generate good margin in comparison to others will not make sense in the bigger picture. Network APIs are a lever which telcos can use to connect various propositions across their organisations and create flexible, customisable, as-a-service consumption models of their services. Network APIs are not about selling technical capabilities but leveraging technical capabilities to fulfil customer needs.
Assumption #3: The value of an API is determined by supply
The final assumption we come across when we are asked to benchmark the price of APIs is that the price of an API is supply driven, i.e. that it should depend on the difficulty, and cost, of providing it. This is what we call a cost-plus model which is in the DNA of telcos in relation to service pricing. It is the pricing model used for some of network APIs’ nearest cousins, for instance A2P SMS.
The problem with cost-plus pricing is that it does not reflect the perceived value of the service to the customer and how well it fulfils their needs. The “plus” element in CPaaS API pricing does vary widely between markets, which may indicate that there is a demand-driven element to it. However, it is more likely that these price differences reflect variations in negotiated wholesale SMS deals, reflecting the varying cost that operators place on delivering SMSs due to infrastructure investment or other regional specificities, all factors that are supply-side-driven and anchored in the competitive landscape. Competition-based pricing works for commodities and products arriving at the end of their lifecycle and tends to create price erosion over time. It is by and large what has been used for telecoms pricing historically and has been one of the contributors to telcos being reduced to dumb pipes. Telcos want to avoid past mistakes when it comes to network APIs and cost-plus pricing is one of the pitfalls they must avoid.
So what is the alternative? Is there a viable demand-driven pricing model that fairly reflects the value of network APIs in different contexts and avoids reducing them to another connectivity commodity?
We have already heard murmurs of defining network API consumption models in terms of business outcomes. In this model, rather than a customer paying for the resources that they use, they would only pay when a successful outcome is achieved. AI services, such as some customer experience chatbots, use such a model: they charge per successful ticket resolution rather than in minutes of use or some other measure of technical resource allocated. Defining pricing in terms of business outcome is a logical way to keep pricing transparent and make the value proposition clear to customers, in particular when the outcome (ticket resolution) requires a complex chains of action to be undertaken.
It is still early to tell what demand-driven pricing models may look like for network APIs. But it could be that, for instance, a location API might be charged for by successfully completed drone flight or per autonomous vehicle trip or per tracked delivery, rather than based on the number of API calls needed to complete that flight/trip/delivery. The difference may seem subtle, but it paves the way for defining business outcomes that are more specific to a customer or vertical and easily quantifiable for the customer in terms of return on investment. This makes for an easier sale, as the value of a network API use case can be directly related to the savings compared to other methods of achieving a similar outcome and represents a fairer valuation of the service as a whole in a specific context, including industry vertical. It also encourages the development of truly valuable use cases anchored in customer needs and reflecting those customers willingness to pay for the service.
Pricing in this way will require extensive vertical-specific knowledge, and a familiarity with customer pain points to define business outcomes that matter and relate these to their usual costs. There is a clear need to get closer to the developer community and end user in target verticals to develop this knowledge. There will also need to be a solid basis of provider-customer trust on which to build this strategy, as this model is a form of revenue sharing that incentivises efficient resource use to enable the use case. However, it is one of the key levers which telcos can use to retain control over the value created by their networks.
More questions than answers
As is so often the case for nascent opportunities, answering a seemingly simple question seems only to unearth more questions. The three hidden assumptions inherent to the question of “What price are telcos charging for network APIs?” have thrown up some fundamental issues with how to bring network APIs to market:
- Which APIs should be charged per call, per second or in some other unit that depends on network conditions? How do you deal with use cases involving multiple APIs? Are APIs a volume-based product at all?
- How much of the value of an underlying service enabled by a network API can be attributed to that API? In what contexts will an API actually be charged as a line item on a customer’s bill, subsumed as part of a broader service charge or absorbed as a cost by the telco? Should APIs have specific revenue attributed to them at all?
- Are there pricing models that fairly attribute the value that network APIs bring to a use case? Can the various industry players rally around a demand-driven strategy to avoid commoditisation?
In this article series, we have given potential directions that the industry might take to resolve some of these issues. There is a path being tentatively explored by some, that moves away from seeing network APIs as discrete volume-based products with their own independent revenue lines and looks instead to attribute value to these based on business outcomes. What this looks like in terms of how the price of an API is defined is still uncertain.
Download this article as a PDF
Do you want to know more about our research in this area?
Read more about Enterprise Platforms
Network API pricing: How long is a piece of string? (Part 1)
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.
Network APIs: Unlocking new value in the telco cloud
Network APIs may offer an answer to the question of how to monetise recent and upcoming telco cloud deployments. Virtualised networks upgrade APIs and enhance the value they offer to developers and customers. To unlock their potential, telcos should focus on optimising their commercial models.