RESOURCES / ARTICLE · NETWORK APIS & AI

The device side of network APIs: what operators will need that the network can't see

TELKOA · AUGUST 2026

The telecom industry has decided its next revenue story is APIs. Under GSMA Open Gateway and the CAMARA project, operators are standardising a family of network APIs — location verification, number verification, device identity, fraud signals, quality-on-demand — that expose network capabilities to enterprises and developers in a consistent way, across operators. The commitment is broad and public; the commercial models (per-lookup pricing, revenue share) are forming now.

Most of the discussion focuses on the northbound side: API gateways, developer portals, aggregators. Less discussed is the question that decides whether the products are any good: where does the underlying data come from?

The network sees a lot. It doesn't see everything.

Take the flagship API categories one at a time:

Location. Network-side location knows which cell a device signalled through — on your network. When the device roams, you're dependent on the visited network's cooperation and API maturity. And a standardised location API returns exactly what SIM-resident measurement produces natively: a position with a confidence area. Device-side cell measurements (serving cell plus neighbours) travel with the device across every network, no partner API required.

Device identity and fraud. The network sees a registration; it doesn’t see that the SIM woke up in a different device this morning (IMEI/TAC change), or that a "stationary" CPE has started moving. Those signals originate at the device — and the SIM observes them directly.

Quality. A quality-on-demand or SLA-verification API is only as credible as its measurement. Network counters describe what was served; the SIM measures what was received — including achieved data speeds, graded and comparable across the whole estate, with no app dependency.

None of this makes network-side data wrong. It makes it half the picture. The APIs that win developer trust will be the ones whose answers hold up at the device edge — roaming, offline, multi-network, on hardware nobody installed an app on.

The SIM as the device-side source layer

The SIM is the only vantage point that is simultaneously: present in every cellular device, operator-controlled, OS-independent, and persistent across the device’s life. A SIM-resident intelligence layer produces exactly the data classes the API catalogue needs — location with confidence, device-change and identity signals, quality and availability metrics — plus something the API story rarely mentions: a control path back. The same channel that reads the signals can act on them (steer, switch identity, lock policy), which is what turns an API product from reporting into capability.

This is the architecture logic behind SimX: API-first from day one for the operator's own stack (REST, webhooks, Kafka, a formal OpenAPI schema), and designed so the same data layer can feed operator network-API products as those businesses mature. Exposing SimX capabilities as third-party network APIs is a roadmap direction, not a shipped product — we're building the source layer in the order that makes it real.

What to do about it now

01 · Instrument the estate before you productise. An API business needs data density; SIM-resident telemetry accumulates it from day one, across every device class.

02 · Choose sources that work off-net. Roaming and multi-network fleets are where network-side-only data breaks first — and where enterprise customers pay most for answers.

03 · Keep the control loop in scope. APIs that can act (recover a device, enforce a policy, steer a fleet) command different economics than APIs that only report.

The industry will spend the next few years arguing about API gateways and aggregation models. The operators who win will be the ones whose answers are true at the device — and that data has to come from somewhere.

RELATED READING

Book a technical discovery.