Telco APIs and Open Gateway: you can’t make an omelette without breaking some eggs

Following the launch of the GSMA Open Gateway initiative the industry buzz around Telco APIs, including network and CAMARA APIs, has significantly increased. 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 Market: acceleration or stagnation?

Following the launch of the GSMA Open Gateway initiative the industry buzz around telco APIs, including network and CAMARA APIs, has significantly increased.

Last year we published research on 11, API-driven, network and MEC capabilities specifically around 5G monetisation (so excluding the validation, authentication, billing style APIs). We forecast the market, including service enablement and new revenues, to reach $22bn by 2028… [we’re publishing new data on this with more capabilities included at the end of the month, so keep an eye out]

Since then, many other firms have come out with their own analysis – recent numbers published add a zero (or two) to our forecast but also cover more of the “CPaaS+” API market (which is an existing market and not 5G specific).

This buzz continued at MWC 2024

Last year at MWC 2023 the Open Gateway initiative had 21 signatories – this year, the GSMA promoted it’s up to 47 telco signatures to push forward on the topic of telco APIs.

Furthermore, some of the major aggregators and distributors in the space announced key partnerships. For example:

  • Ericsson Vonage: announced partnerships with Verizon and AT&T to support on the commercialisation of telco APIs, especially around “CPaaS +” number/SIM verification.
  • Nokia Network as Code: announced a partnership with Liberty Global to deliver NaaS capabilities into the port of Antwerp, and set out its vision to be in 30 regions by the end of the year.
  • AWS: announced a partnership with Vonage to sell Vonage through the AWS marketplace.
  • Azure: announced with DT and Broadpeak to look into quality on demand (QoD) services running on Azure’s Azure programmable connectivity (APC) platform.

On top of this, a handful of the telcos who are part of the Open Gateway initiative (including DT, Orange, Telefonica) demoed live network APIs (e.g. in number verification – trying to tap into the existing CPaaS market), as well as highlighting their continued PoCs in QoD (especially in live video broadcast).

But… this was only a small number of the 47 who signed MoUs as part of the initiative and many of the telcos who are a part of Open Gateway didn’t give much, if any, real estate to the topic (mostly in favour of hitting the AI buzz word).

The Telco API Dilemma: navigating the chicken-and-egg scenario

The chicken…

Behind the announcements, there is still some (I think healthy) scepticism from the industry (including the telcos) and a lot of key questions remain on how telco APIs will truly drive revenues for operators and the partners they work with.

This scepticism manifests for operators in a challenge building the business case for rapid, scaled, and continued investment in new, innovative, northbound API capabilities. Before putting more money down and expanding the telco API portfolio, telcos want to see:

  • Proven demand from developers and end users for API driven capabilities and the APIs they’ve already invested in.
  • That there are direct revenues to be made from APIs and that the business case isn’t built on enablement of other services.
  • As much scale and volume of API calls as possible (rather than a focus on higher-value, lower-volume, APIs).

Without a fully fledged business case (by which we mean a validated customer base, route to market, revenue model, ROI with healthy margin), many telcos will be slow to invest in further innovation around northbound API exposure – instead waiting for tangible proof points to de-risk investment and for others (e.g. standards bodies, other operators) to pave the way.

It’s similar to the edge/private networks story – operators want to know what the “killer use case” will be for APIs and this (and only this) is what they want to build for… without the killer app, progress will naturally slow and the flywheel for the opportunity will not turn.

The egg…

The challenge is that if operators are hesitant in building out new capabilities developers will have less to build on…

We are still in exploration mode for what new use cases will spin up as apps become more embedded in and closely coupled to the network – owing to access to previously black boxed network information and (eventually) network orchestration capabilities. Without more and more capabilities for developers to test out there won’t be a “killer use case” or the demand proof points which telcos are looking for.

We have spoken to 100+ developers in 1-2-1 interviews in the past 12 months (including in the build up to MWC) and many were excited about the opportunity to work with these emerging network capabilities. However, a major pain point was that even the big operators only had 2/3 API capabilities available and these were often not consistent across telcos, making working across regions more challenging.

Further to the problem (which will be the focus of a separate piece) many telcos had used CAMARA standard APIs but wanted to expose the capabilities through their own portal/gateway… removing some of the primary aim of standardising in the first place.

See how STL can help you grow your enterprise revenues

Our Growing enterprise solution covers how operators can adopt B2B2X business models to address changing enterprise needs in 5G, private networks, IoT, analytics and more.

Book a demo

Breaking the cycle with telco APIs: unlocking value in NaaS and programmable networks

Without capabilities to build on and test out, developers won’t see the value of API-driven NaaS and programmable network propositions to identify leading use cases… and without a well established/well validated market demand, the telcos won’t invest in further capabilities for developers to build on… thus, the flywheel won’t turn and the opportunity will have stalled before it’s had the chance to scale (much like it did in previous attempts by the telecoms industry to adopt APIs).

So, how does the industry stop this from happening again and break this cycle, giving the market a chance to scale?

Break some eggs…

A bit tongue and cheek, and certainly guilty of mixing metaphors, but what better way to break the chicken and egg scenario than by “breaking some eggs”…

Effectively, telcos need to allow themselves to fail fast in this market. They say they want to “throw stuff at a wall and see what sticks” but if they’re only throwing two or three capabilities at the wall, will they find anything that sticks?

Telcos (certainly versus techcos) haven’t historically been good at “failing fast” – so, what can they do to break eggs in this market?

Following MWC, there were three recommendations that came to mind:

1. Be wary of productising “Telco APIs”

2. Explore telco API opportunities in enterprise, private, fixed, and edge

3. Get their hands messy co-innovating with developers and end customer

1. Be wary of productising “Telco APIs”

Many operators we have spoken to have set up product teams dedicated to telco APIs. These teams are tasked with rolling out telco APIs under the TMF/MEF/CAMARA standards (often driven by technology and not business teams). It is great to have a dedicated resource to get the ball rolling but this brings a few challenges that are barriers to “breaking eggs”…

If telco APIs are built as a product line within the operator, they will likely have their own cost/profit centre built around them. Each product team will therefore need to build (and justify) its own business case built on revenues directly from APIs rather than, for example, from a key service the API is enabling.

Take edge node discovery – given its more expensive real estate, telcos will likely charge a premium for consumption of edge resource. Should telcos then also charge for use of an edge node discovery API on top of this? Or should it just be a core part of the edge proposition/PaaS that makes it worth using? This is especially pertinent since telcos have generally struggled to monetise edge propositions with developers and enterprises.

Adding to this, when we think about the monetisation model of APIs for Hyperscalers, do Azure or AWS care about monetising APIs directly? or do they want to drive compute at the edge and consumption of their cloud resources?

These questions lead to very different business models beyond volume * price for APIs (e.g. value shares, revenues shares, subscription models) but, as stated above, the product teams working on API capabilities may need direct revenues to prove the business case. Furthermore, removing the need for direct revenues and ROI from individual APIs to feed a product team’s business case will allow more freedom to innovate, test the market, and fail fast.

As a continuation of this, telcos and their partners should view APIs not as products but as raw materials on top of which stickier, more compelling network embedded services are built…effectively, they are a network capability that can enhance delivery of use cases, which in turn must solve a business challenge. Eventually developers may have suites of APIs enabling a single use case – but it’s the use case that creates value for the customer, not the API calls…

We think about APIs as enablers of a portfolio of NaaS-driven use cases… telcos should therefore consider shifting the message away from “telco APIs” and instead think about this as a way to monetise programmable networks or enable the shift towards NaaS propositions across a suite of use cases/use case areas.

Doing a quick whip around MWC, only the telcos focussed on “telco APIs” while many vendors in the space used other language, e.g.:

  • Azure: programmable connectivity
  • Nokia: network as code and NaaS
  • AWS: advanced connectivity
  • Amdocs: network exposure

Is using the term “telco API” a little walled garden mentality? It feels like telcos want to own the API and ecosystem around them. They want to show it’s something very new and innovative with the operator at the centre… but is this to the detriment of scale? Developers (and telcos) have been using APIs for many years as part of their routine operations – while exposing network APIs northbound is a new feature, the model and the approach must be consistent with cloud and CPaaS based APIs. By emphasising the telco API language, it may entrench a mindset of telco proprietary standards, rather than convergence with existing models.

2. Explore API opportunities in enterprise, private, fixed, and edge

As a follow on to the point above, having APIs in a product team can lead to siloed thinking when APIs could, and should, play a role across a lot of the existing portfolio for telcos.

This includes not just public network (B2)B2C use cases – where CAMARA has primarily focused to date – but how standards driven APIs will fit into private networks, campus networks, distributed networks, fixed networks… and how they will create value for a variety of enterprise customers, as well as the consumer market.

Of course, a lot of the CPaaS+ APIs apply to business customers (e.g. the verification APIs play in banking to reduce fraud) but a lot of the innovative 5G capabilities (slicing, QoD) are focused on consumer facing use cases (esp. live video broadcast, cloud gaming).

When 5G was first emerging, a lot of the messaging was how it was “designed for enterprise” and, apart from a few telcos like Elisa, most have struggled to increase ARPUs in the consumer segment with 5G. Furthermore, enterprise has been seen as an area for telcos to build a different brand with their customers and take a different role in the value chain.

Yet, we seem to have gone back on this notion as an industry and are expecting that network APIs will suddenly drive significant growth in 5G revenues owing to the potentially higher volume of API calls and pull through connectivity revenues on the public network B2B2C side.

It makes sense that telcos have to start somewhere and testing the market in a higher volume area, with the shorter and less complex consumer sales cycle makes sense… however, enterprise use cases shouldn’t be overlooked and more focus should be put on starting to build the relationships and use cases that work in mission critical enterprise and connecting this to telco strategies in private networks, edge, enterprise IoT etc. – even if it’s harder yards and more hoops to jump through (E.g. around enterprise security).

Otherwise, telcos may find their investments already made in B2B2C don’t translate into the B2B space. This could lead to a sunk cost fallacy that’s difficult to overcome – doubling down rather than being able to quickly pivot and invest in innovation in new domains. Revenue models with partners, technology standards and infrastructure will be more entrenched and may leave value in the enterprise space on the table.

3. Get their hands messy co-innovating with developers and end customers

Techcos are good at innovating in new domains – they can take an approach of “build it and they will come”, innovating around core concepts and then testing the market in an agile, MVP, proof of value led way. Generally, they prioritise first mover advantage over the risk of failed ventures…

Telcos struggle with this model. This is in part due to a complete difference in financial structure – telcos must invest a lot in network capex and comparatively very little in R&D opex/ non-network service innovation versus the techcos. They are seen as a dividend stock, so have limited scope to reinvest for growth. However, it is also in part due to customer centricity.

When techcos innovate, they have the customer problem at the centre of the solution – my gut feel is innovation for them is very rarely just “tech for tech sake” but new innovation areas are identified based on a clear understanding of where customers might want to go, and what they might want to achieve.

Telcos are still too removed from the developer community and the end user – they don’t fully understand how developers want to engage with network capabilities and don’t understand the business challenges their end customers want to address. This means, without proper validation, it’s more difficult for telcos to accurately predict where to innovate and what to build… meaning for them the potential negative impact from “breaking eggs” is a much higher risk. If an innovation area doesn’t scale, it has real impact of shareholder value and telcos’ abilities to pay the routine dividends the market expects.

Therefore, telcos are outsourcing a lot to aggregators to get reach with and engage developers, hoping the aggregators will provide insights on where to invest next. However, if the telco continues to outsource so much of the customer facing/customer centric parts of the solution, what role is left for the telco beyond becoming an API pipe? How will telcos differentiate on their customer experience or on the capabilities they offer if they don’t understand the real underlying needs of the customer they’re building for?

If telcos, as part of CAMARA and beyond, can start participating in co-innovation with aggregators and developers, they’ll build more of an understanding of what the developer ecosystem wants now and might want in the future. They’ll also start to build a better picture of what end enterprises require and the pain points they’re trying to address with NaaS/programmable network use cases.

This will take time and investment but can help make future decisions on which capabilities to invest in more accurate, and help telcos build a stronger role and right to play with customers… this will lead to taking a punt on more wins than losses, and more of the stuff they throw at the wall sticking rather than falling off.

Considering some of the above can help operators place their bets on where to build more effectively – “derisking” investment in new capabilities through customer centricity.

Balancing business model with technological innovation in telco APIs

To summarise, there is a lot of work being done by the telcos, their partners, and the standards bodies on driving the early technological advancement of telco APIs and northbound exposure. However, as laid out above, less is being done on the commercial models (go-to-market strategy, revenue model, 3-year strategy). Without more clarity around this, sustained investment in API-drive capabilities will slow and the flywheel to scale telco APIs may not get turning.

Telcos must align their business and technology teams on the topic and understand how APIs play a role across their portfolio, rather than building them in technology/product silos. Bringing in the business perspective and working backwards from the business challenge can help telcos “break eggs” in a lower risk way and help operators start to build towards a new role with their customers and partners.

Darius Singh

Darius Singh

Darius Singh

Consulting Director & Practice Lead at STL Partners

Darius Singh is the Consulting Director & Practice Lead at STL Partners. He has led a range of client projects within edge computing, 5G, and data analytics

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.

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.