Beyond Individual APIs: How Can Network Capabilities Work Together?

The first stage of Network API adoption focused on exposing individual capabilities.

Location. Number Verification. Geofencing. Authentication.

Each capability can solve a specific application requirement. But real business workflows are rarely built around a single network signal.

A digital service may need more than one piece of information before it can complete a verification, provide a service, or make a decision.

This creates the next question in the Network API journey:

What happens when different network capabilities become part of the same digital workflow?

From Individual Signals to Network Context

Consider a simplified workflow:

Subscriber → Device → Location → Network Context → Service Decision

Each part can provide a different piece of information.

For example, an application may need to establish:

• Is this the expected subscriber?
• Is the device associated with that subscriber?
• Is the device in the expected location?
• Should the requested service be allowed?

These questions do not necessarily require one large API. They can be addressed through different capabilities that are consumed by the application and combined within its own business logic.

This creates a broader model:

Network Capability A + Network Capability B → Application Context → Business Decision

The network provides the signals. The application determines how those signals should be used.

Why One Network Signal May Not Be Enough

A single network capability can provide useful information, but the context around that information can determine how useful it becomes.

Consider location.

A Location Verification API can determine whether a device is within a specified geographical area. Number Verification can provide information about the relationship between a mobile number and a device. Geofencing can provide notifications when a mobile line enters or exits a predefined geographical area.

These capabilities address different requirements, but they can become inputs to a broader application workflow.

For example:

Number Verification → Location Verification → Application Decision

The first result provides one type of network context. The second provides another. The application can then use both results according to its own service logic.

The important point is that the network does not necessarily make the final business decision.

Network capabilities provide the information. The application provides the decision logic.

From APIs to Connected Workflows

This changes the way Network APIs can be viewed.

Instead of:

Application → One API → One Result

the model can become:

Application → Multiple Network APIs → Multiple Results → Business Workflow

This does not mean every application needs multiple APIs.

The value is that an enterprise can select the capabilities relevant to its particular workflow.

For example, a service involving identity and location could use network-based verification together with location information.

An IoT workflow could use location-related capabilities together with application data about an asset.

A service-access workflow could combine authentication or entitlement information with application-specific eligibility rules.

The exact combination depends on the use case.

Where Does PAiCore Fit?

PAiCore’s portfolio provides building blocks across different parts of this architecture.

The Network API Gateway provides the API and telecom interworking layer. It supports CAMARA-aligned capabilities including Location Retrieval, Location Verification, Geofencing Subscriptions and Number Verification, with integration to PAiCore GMLC and signaling platforms.

The GMLC & CAMARA LBS capability provides network-based location services.

The Entitlement Configuration Server Lite (ECS Lite) provides SIM-based authentication and entitlement capabilities aligned with GSMA TS.43.

These are separate capabilities rather than one combined API.

That separation is useful because different applications can consume the capabilities they actually need and apply their own business logic around the results.

A Practical Network API Workflow

A connected workflow can be represented as:

Application → Network API → Network Capability → Result

When more than one capability is required, it can become:

Application → API 1 → Result 1

Application → API 2 → Result 2

Result 1 + Result 2 → Application Logic → Service Decision

For example, an application may first verify a mobile number and then use location information as another input to its workflow.

The underlying network capabilities remain separate, while the application brings the results together.

This is different from creating a single API that tries to represent every possible business decision.

The API provides a specific network capability.

The application decides how that capability fits into the wider service.

Why Standardisation Matters

Combining network capabilities becomes more practical when applications can consume them through consistent interfaces.

This is one of the reasons GSMA Open Gateway and CAMARA are important to the Network API ecosystem.

GSMA Open Gateway provides a global framework of common Network APIs designed to give developers and cloud providers more consistent access to mobile operator networks. CAMARA develops and tests standardised APIs for telco capabilities that underpin many of these services.

Standardisation does not make the underlying operator networks identical.

Instead, it helps create a more consistent application-facing layer while operators continue to use their existing network infrastructure.

This makes it easier to think about Network APIs as building blocks that can be incorporated into broader application architectures.

From Individual Capabilities to Network Intelligence

This represents an important step in the Network API story.

The first question is:

“What capability can the network expose?”

The next is:

“How can an application use that capability?”

The broader opportunity is:

“How can multiple network capabilities provide useful context for the same digital workflow?”

This is where the concept of network intelligence becomes more relevant.

The network can provide different signals.

The application can combine those signals with its own data and business rules.

The resulting service can then respond to the specific situation.

The Resulting Architecture Can Be Viewed As

Mobile Network → Multiple Network Capabilities → Standardised APIs → Application → Business Logic → Service Decision

At the network level, different capabilities remain responsible for their respective functions.

At the API level, those capabilities become accessible to applications.

At the application level, the results can be combined according to the requirements of the service.

This creates a modular approach rather than forcing every use case into a single API.

Why This Model Matters for Operators and Enterprises

For operators, the opportunity is to make selected network capabilities available as reusable building blocks rather than treating each capability as an isolated technical function.

For enterprises, the benefit is the ability to incorporate network-derived information into existing digital workflows.

For developers, standardised APIs provide a simpler interface to network capabilities without requiring them to directly implement the underlying telecom integration.

GSMA’s recent work also increasingly frames Network APIs around real enterprise problems and business outcomes rather than the API catalogue alone.

The direction is therefore moving from:

Individual API → Individual Use Case

toward:

Network Capabilities → Connected Context → Digital Service

Explore PAiCore

PAiCore provides multiple building blocks that sit across the Network API, location, authentication and telecom infrastructure layers.

Explore the PAiCore Network API Gateway

Explore PAiCore Products

Industry Standard References

• GSMA Open Gateway — What is GSMA Open Gateway?
• GSMA — Understanding Network APIs
• GSMA — How Standardised Network APIs Are Driving Business Value and Opportunity
• GSMA — Open Gateway Case Studies
• CAMARA Project

The next step for Network APIs may not be exposing more capabilities individually, but making the right capabilities work together within the same digital workflow.