The Network API Opportunity

For decades, telecom operators have been connectivity pipes -- they sell bandwidth but cannot expose granular network capabilities to application developers. 5G changes this with the Network Exposure Function (NEF), defined in 3GPP TS 23.502 and TS 29.522, which provides a northbound API gateway for external applications to interact with core network functions.

The problem is that each operator historically designed proprietary APIs, creating fragmentation that deterred developer adoption. The CAMARA project (under the Linux Foundation) and the GSMA Open Gateway initiative solve this by standardizing a common set of network APIs that work across operators globally.

As of early 2026, the GSMA Open Gateway has 65+ operator signatories representing over 75% of global mobile connections. CAMARA has published 20+ API specifications in various stages of maturity, with Number Verification and SIM Swap Detection reaching General Availability.

Architecture: From NEF to Developer

API Exposure Architecture

The NEF is the critical bridge between the external world and the 5G Core SBA. It validates external requests, maps them to internal NF service operations, and enforces exposure policies. For example, a QoS-on-Demand API call flows through:

1. Developer sends REST API request to operator AEP
2. AEP authenticates via OAuth2.0, rate-limits, and forwards to NEF
3. NEF translates request to internal Npcf_PolicyAuthorization service operation
4. PCF creates or modifies a PCC rule for the target UE's PDU session
5. PCF pushes updated PCC rules to SMF via N7 interface
6. SMF installs QoS flow with new QFI on the UPF via N4 (PFCP)
7. UE receives updated QoS parameters via NAS signaling

This entire flow -- from API call to QoS enforcement -- takes 200--500 ms in production deployments.

CAMARA API Portfolio

API Catalog (as of March 2026)

Worked Example 1 -- QoS-on-Demand API Call

Scenario: A cloud gaming provider wants to guarantee 20 Mbps downlink, 50 ms latency for a gaming session between the server and a mobile user. API Request (CAMARA QoD v0.10): `json

POST /qos-on-demand/v0.10/sessions

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Content-Type: application/json

{

"device": {

"phoneNumber": "+14155551234"

},

"applicationServer": {

"ipv4Address": "203.0.113.50"

},

"qosProfile": "QOS_L",

"duration": 3600,

"notificationUrl": "https://gaming-app.example.com/qos-callback",

"notificationAuthToken": "c8974e592c2fa383d4a3960714"

}

` QoS Profile Mapping: Internal 5GC Flow: `

1. NEF receives request, validates device identity against UDM
2. NEF calls Npcf_PolicyAuthorization_Create on PCF:

- Media component: DL flow to 203.0.113.50

- QoS reference: 5QI=80 (GBR, 50ms latency, 20 Mbps DL)

- Duration: 3600 seconds

1. PCF creates PCC rule with QoS data:

- QFI: 2 (new GBR QoS flow)

- 5QI: 80, GBR DL: 20 Mbps, PDB: 50 ms

1. PCF pushes PCC rule to SMF via Npcf_SMPolicyControl
2. SMF creates QoS flow: sends PFCP Session Modification to UPF
3. SMF triggers PDU Session Modification to UE via AMF/gNB
4. UE establishes new QoS flow (QFI=2) for gaming traffic

` API Response: `json

{

"sessionId": "a1b2c3d4-e5f6-7890",

"qosProfile": "QOS_L",

"device": {"phoneNumber": "+14155551234"},

"qosStatus": "REQUESTED",

"startedAt": "2026-03-28T10:00:00Z",

"expiresAt": "2026-03-28T11:00:00Z"

}

`

Within 200--500 ms, the gaming traffic flow receives dedicated 20 Mbps GBR with 50 ms latency guarantee.

Worked Example 2 -- Number Verification for Fraud Prevention

Scenario: A fintech application wants to verify that the phone number entered by a user during account creation actually belongs to the device making the request. This prevents SIM-based fraud. API Request (CAMARA Number Verification v1.0): `json

POST /number-verification/v1/verify

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Content-Type: application/json

{

"phoneNumber": "+447700900001"

}

` How It Works:

The Number Verification API uses the OIDC (OpenID Connect) authorization code flow with the mobile network as the identity provider. The critical difference from traditional OTP verification is that no SMS is sent -- the network itself confirms the match:

1. The user's device initiates the OIDC flow via the mobile data connection (not Wi-Fi)
2. The operator's IDP authenticates the device based on the SUPI/GPSI binding in the UDM
3. The operator confirms whether the claimed phone number matches the SUPI associated with the data session
4. Response is a simple boolean -- no PII is exposed to the developer

API Response: `json

{

"devicePhoneNumberVerified": true

}

` Fraud reduction impact: Telefonica reported that integrating Number Verification into their partner fintech apps reduced account takeover fraud by 78% compared to SMS OTP, while improving user experience (no waiting for SMS, no code entry).

Business Models and Revenue

API Monetization Models

Operator Revenue Data

Telefonica (Open Gateway) -- 2025 Results:

• Number Verification API: 2.3 billion API calls across Spain, Germany, Brazil, UK in 2025
• Revenue from network APIs: EUR 45 million (2025), projected EUR 120 million for 2026
• Top verticals: Fintech (42%), e-commerce (28%), ride-hailing (15%), gaming (10%)
• Developer partners: 850+ active developers on the Telefonica Open Gateway platform
• SIM Swap API adoption: 340 million calls in 2025, primarily from banking partners for fraud prevention

Deutsche Telekom (T-API) -- European Rollout:

• QoD API: Deployed in Germany, Austria, Greece, and Hungary
• Average QoD session revenue: EUR 0.15 per session (30-minute average)
• Monthly QoD sessions: 4.2 million across all markets (Q4 2025)
• Partner integration time: Average 3.5 days from API key to production (down from 45 days with proprietary APIs)

Aggregation Platforms

The GSMA Open Gateway model relies on aggregation partners that provide a single integration point for developers to access APIs across multiple operators:

• Vonage (Ericsson): Largest aggregator with 35+ operator integrations. Provides unified SDK for CAMARA APIs.
• Twilio: Integrated Number Verification and SIM Swap APIs from 12 operators.
• Google Cloud / AWS: Partnered with operators to expose network APIs via their cloud marketplaces, enabling developers to consume network APIs alongside cloud services.

Technical Challenges

1. Cross-operator consistency: Despite CAMARA standardization, operators implement different API versions and have varying QoS enforcement capabilities. A QoD session that works on Operator A may behave differently on Operator B. GSMA Open Gateway compliance testing aims to reduce this variability.

1. Latency for real-time APIs: Device Location Retrieve requires signaling through GMLC, AMF, and gNB to obtain a fresh position fix. End-to-end latency is 1--5 seconds, which is insufficient for real-time tracking applications. Caching and event-based subscription models (per 3GPP TS 29.572) help.

1. Privacy and consent: Location and identity APIs raise GDPR and regional privacy compliance concerns. CAMARA mandates the OIDC consent flow where the end user must explicitly authorize data access. Operators must implement consent management platforms that log and enforce user permissions.

1. Roaming API continuity: When a UE roams to a visited network, the home NEF may not have direct access to visited network resources. 3GPP TS 23.502 Section 4.15 defines NEF-to-NEF interaction for roaming scenarios, but production implementations are still maturing.

Key Takeaway: CAMARA and GSMA Open Gateway are transforming operators from dumb pipes into platform providers. Standardized network APIs -- particularly Number Verification (2.3B calls at Telefonica), QoD (4.2M monthly sessions at Deutsche Telekom), and SIM Swap Detection -- generate new revenue streams while enabling developers to build network-aware applications in days instead of months. The NEF, defined in 3GPP TS 29.522, is the critical 5GC NF that bridges external APIs to internal PCF, UDM, and GMLC operations. With 65+ operators onboard and 850+ developers building on these APIs, the network-as-a-platform model is becoming reality.