Download
Listen
Network-as-a-service (NaaS) and network APIs are often treated as separate market conversations. But both point to the same broader strategic shift towards telco-as-a-platform: making network capabilities more programmable, modular, consumable and monetisable. Operators should not treat these as siloed services; instead they should apply a shared platform mindset to both – or risk reducing them as isolated products and missing the bigger prize.
NaaS and Network APIs: Defining their roles in the telco-as-a-platform agenda
There is a terminology issue when it comes to network-as-a-service (NaaS). One interviewee from a research programme cited that “We don’t use the term NaaS since there are so many different meanings that no one knows what they’re talking about when they use it.”
At STL Partners, we define NaaS to describe the broader shift towards a cloud-like platform model for network services – essentially applying platform principles to network services. It is not a single product category. Instead, it is both a technical foundation and an operating and commercial model: a way to make network capabilities more programmable, configurable, assured, consumable, and monetisable. Technically, NaaS is enabled by cloud-native architectures, automation, orchestration, network exposure and increasingly autonomous operations. Commercially, it changes how customers and partners consume network services — moving from static, bespoke connectivity contracts towards more customisable, self-service, flexible models, including pay-as-you-go, usage- and outcome-based models.
The structural pillars and mindset of a successful platform strategy
Source: STL Partners
This makes NaaS the foundation for next-generation network services in two ways.
1. It supports the evolution of existing connectivity services. This reflects common industry usage where “NaaS” most often refers to fixed enterprise and wholesale connectivity propositions delivered in a more cloud-like way: Ethernet, IP/optical services, SD-WAN, cloud connect, managed WAN/LAN, SASE, on-demand bandwidth and hybrid private networks. However, these services should not automatically be treated as NaaS: basic resale or managed-service versions of SD-WAN or SASE, for example, may remain traditional connectivity offers. They become NaaS-like when they are genuinely modular, self-service, API-enabled, dynamically configurable and supported by more flexible commercial models.
2. It provides the foundation for net-new services that depend on programmable network capabilities. This includes network APIs, IoT deployment management, edge-enabled propositions and application-aware performance services. In this sense, NaaS is not only about selling connectivity in a new way; it is also about creating the programmable, assured and commercially flexible foundation on which new services can be built.
APIs fits into two roles within NaaS and the telco-as-a-platform agenda:
1. Internal and partner-facing APIs enable NaaS propositions by connecting network, OSS/BSS, orchestration, assurance, product and portal systems so that operators can create, provision and monetise these dynamic services. These interfaces are often shaped by TM Forum Open APIs, MEF/Mplify LSO APIs and other service lifecycle or orchestration standards.
2. External network APIs productise selected telco data and capabilities for developers, enterprises and platforms. In industry usage, “network APIs” increasingly refers to this second category: external, standardised APIs (typically in the mobile network domain) associated with CAMARA, GSMA Open Gateway and related initiatives. STL groups these into two families: network information APIs that report real-time data from the network (such as device location, device status, SIM swap signals and performance), and network configuration APIs that instruct the network (such as Quality on Demand, slice configuration and device onboarding).
Our view is that NaaS and network APIs should therefore be understood as connected parts of the same telco-as-a-platform agenda, not as disparate growth opportunities for operators. Operators have already invested heavily in 5G, cloudified cores, automation, orchestration and service assurance. Those investments will not deliver full returns simply because networks become faster or more software-defined. They will deliver when customers, developers and partners can discover, consume, configure and pay for network capabilities in more flexible, software-led ways.
NaaS applies platform principles to connectivity services and the network capabilities that support them. Network APIs turn selected network capabilities into consumable services for developers, enterprises and partners. In both cases, APIs make network capabilities accessible; the platform operating model makes them scalable, assured and monetisable.
The strategic prize for telcos is therefore not simply to build an API catalogue or a self-service NaaS portal. It is to become a more software-oriented organisation: one that can expose capabilities through reusable interfaces, ship smaller propositions faster, refine them through customer and developer feedback, and monetise the network beyond the traditional connectivity contract.
Two opportunities, one platform mindset
For most of the past decade, the industry has developed NaaS and network APIs on separate tracks. NaaS has been discussed in the enterprise and wholesale connectivity context: fixed, IP, optical, SD-WAN and multi-cloud networking. Network APIs have been discussed in the mobile context: number verification, SIM swap, location, Quality on Demand (QoD), device status and network slicing, exposed through standardised developer interfaces.
The separation is understandable. The standards bodies, customers and commercial motions are different. NaaS is associated with TM Forum, MEF/Mplify, enterprise portals, on-demand bandwidth and automated service ordering. Network APIs are associated with CAMARA, GSMA Open Gateway, developer platforms, aggregators and application-led use cases.
But the separation can be misleading because it encourages operators to treat NaaS and network APIs as separate product categories, rather than different expressions of the same platform mindset. NaaS and network APIs are not the same proposition: an SD-WAN or cloud connect service delivered through a self-service enterprise portal is not the same commercial motion as a CAMARA-style Number Verification API. But both depend on the same underlying shift: making the network observable, controllable, consumable and billable as software. NaaS does this for enterprise and wholesale connectivity. Network APIs do it for developers, platforms and application providers. The customer interface differs, but the platform mindset should be shared: build reusable capabilities, expose them through software, package them around customer outcomes and support them with flexible commercial and ecosystem models.
Why the platform shift matters commercially
The telecoms industry has a narrow window to make programmable connectivity commercially meaningful before competition increases. Enterprises and digital platforms want better fraud prevention, lower onboarding friction, differentiated connectivity, more resilient application performance and easier access to trusted network intelligence. They do not want to negotiate bespoke integrations with every operator or wait months for provisioning, approvals and contracting.
Based on our recent telco-as-a-platform research, operators have made more progress on the technical service architecture, which is needed to expose and automate network capabilities. The harder work is in the revenue and ecosystem layers: pricing, entitlement, usage tracking, settlement, partner onboarding, developer experience and customer-facing packaging.
A telco that can expose capabilities through standardised interfaces, package them around customer outcomes and support them with automated assurance moves faster than one that treats every new capability as a bespoke product launch. It also reuses more of the same underlying platform across multiple offers. A QoD API, an SD-WAN assurance product, a private network portal and an edge connectivity proposition should not each require a separate operating model.
The platform mindset is also important because the financial logic is broader than a typical product P&L. In NaaS, the value is not only in charging for a single connectivity product. In network APIs, the value is not only direct API revenue. APIs can create new revenue streams, but they can also strengthen existing enterprise services – from B2B connectivity to identity, cybersecurity services – improve customer experience, reduce operational friction and make 5G capabilities more valuable to partners. A narrow product P&L view risks missing this. The right question is not only “which API can we sell?” or “which NaaS product can we launch?” but “how can programmable network capabilities make the existing business stronger and create new routes to market?”
Case study: Orange and Colt show the platform logic in practice
At MWC Barcelona 2025, Orange, Colt and MEF demonstrated a cross-operator Quality on Demand use case at the GSMA Open Gateway Showcase. The demo combined CAMARA APIs with MEF NaaS network APIs so that a single application-level request could trigger coordinated network behaviour across two domains: Orange’s mobile network and Colt’s fixed network.
The key takeaway from this demonstration was that the application did not have to manage the underlying split between mobile and fixed connectivity to call a QoD request. The application asked for an outcome, and the relevant network domains coordinated behind the scenes. This is the essence of true programmable connectivity: the customer or developer interacts with a capability, not with the organisational complexity of the operators that deliver it.
This matters because many enterprise and application use cases will not sit neatly inside one network domain. A broadcaster uploading live video from a crowded venue may need mobile QoD for the uplink, fixed connectivity for onward transport, cloud connectivity for processing and assurance across the full service path. The customer does not need a generic promise of better 5G but does need stable uplink performance during the live session. Enabling this specific and flexible need with QoD APIs and fixed network integration demonstrates the method to commercialisation.
Historically, delivering that kind of cross-domain capability would have required bilateral agreements, bespoke interfaces, manual coordination and unclear accountability. This creates multiple barriers to scale. A standards-based federation layer under the guidance of CAMARA and Mplify offers a better route: one interface for the customer, orchestration across the relevant domains and the possibility of common commercial and operational rules underneath. The future value is not in selling isolated endpoints, but rather in making connectivity programmable across domains. That requires operators to move beyond siloed product teams and think of the network in terms of reusable, modular capabilities that can be assembled, assured and monetised across fixed, mobile, cloud and partner environments.
What this means for operators
Four practical implications follow from treating NaaS and network APIs as connected parts of the telco-as-a-platform agenda.
1. Move from product roadmaps to a programmable platform roadmap. Operators should stop treating fixed NaaS, mobile network APIs, private networks, SD-WAN assurance, edge exposure and enterprise portals as unrelated product initiatives. These propositions may have different buyers, internal owners and go-to-market motions, but they should sit within a shared roadmap for programmable network capabilities.
2. Treat NaaS as a necessary operating shift, not only an opportunity for net-new revenues. NaaS should not be seen only as a “fancy” new product category or a discrete growth bet. At its core, it is about changing how network services are built, configured, delivered and adapted. That makes it relevant even where the immediate goal is not a new standalone NaaS proposition, but faster provisioning, lower operational friction, better service assurance or a more flexible customer experience.
For many operators, the first value of NaaS may be speed rather than direct revenue: faster time to quote, faster time to provision, faster service modification, faster partner integration and faster creation of new propositions. This matters because enterprise customers increasingly expect network services to behave more like cloud services: configurable, transparent, scalable and available through software-led channels.
3. Design propositions around customer outcomes, not interfaces. Customers do not buy NaaS because a portal exists, or QoD because the API exists. They buy faster site turn-up, more resilient applications, lower fraud, better live media performance, more flexible cloud connectivity, safer remote operations or simpler multi-site networking. Operators should therefore use NaaS and network APIs to simplify how customers consume network capabilities. That means abstracting away the internal complexity of fixed, mobile, cloud and partner domains, and packaging capabilities around outcomes that customers recognise and care about.
4. Build for modularity and reuse before chasing the full platform vision. Operators do not need to build the full telco-as-a-platform vision from day one. But they should ensure that each NaaS or network API initiative contributes to a more modular foundation. A cloud connect portal, a QoD API, a private network offer or an SD-WAN assurance feature should not be built as one-off technical or commercial islands. The priority should be to build reusable capabilities that can support multiple propositions over time. This is where the platform mindset matters: build once, reuse often, and design capabilities so they can be recombined around different customer outcomes. Operators should also apply this in an agile way: start with a focused use case, learn quickly, drop what does not work and scale what does. The aim is not to wait for the perfect platform blueprint, but to make each initiative a step towards a more reusable and software-led network business.
The operators that truly embrace the telco-as-aplatform agenda will be better placed to compound their 5G and cloud investments across every offer they build. Those that keep the tracks separate will pay twice for the same platform, ship more slowly than enterprise customers now expect, and cede the developer and platform relationships that turn connectivity into a software business. The window to embed progress is open now but it will not remain indefinitely.
Do you want to know more about our research in this area?
Read more about NaaS & Network APIs:
Aduna Summit 2026 takeaways: Customers want more – and faster
Early adopters are seeing tangible value and benefits from network APIs – but to scale adoption, customers want broader coverage, faster timelines and commercial models that work for real customer …
Quality on Demand and network slicing APIs: The differentiated connectivity opportunity
As operators look for new ways to monetise network capabilities, Quality on Demand (QoD) and Network Slicing APIs stand out as two of the most important emerging approaches to differentiated connectivity. The challenge now is turning trials and early deployments into scalable commercial offers.
Beyond anti-fraud for financial services: Where will the next wave of network API growth come from?
Network APIs are gaining real commercial traction, led by strong early results from identity and anti-fraud use cases. As these APIs mature, operators face a new challenge: how to scale adoption beyond financial services. This article explores early success stories and the emerging opportunities in new verticals.
Bridging the NaaS commercialisation gap: From ambition to reality
While telcos understand the technical foundations of NaaS, many still lack a clear commercial strategy, especially when it comes to pricing models and identifying the right buyers beyond traditional procurement channels.
Network APIs market insights pack
Our overview pack explores how the telecoms industry can drive growth and scale for the network API opportunity.
Telco APIs: The network is a gold mine
Telco APIs promise operators a new route to growth by shifting the way customers, whether enterprise customers or software developers, engage with telecom services and assets. In this article, we lay out the different roles players can take in the ecosystem to monetise these APIs using the analogy of the network as a gold mine.