CAMARA network APIs: state of play, 2026

CAMARA network APIs: state of play, 2026

CAMARA is the first credible attempt to give developers a portable contract against mobile operator capabilities. Every previous attempt (GSMA OneAPI, individual carrier portals, vendor-specific SDKs) collapsed under the same weight. Each operator exposed its own authentication model, its own schemas, its own rate limits, its own semantics for "device reachable" or "SIM changed recently." Integrating two operators cost more than writing the business logic the integration was supposed to serve.

CAMARA changes the shape of the problem. The API contract is defined in the open. The schemas live in public repositories. Federation happens through GSMA Open Gateway. An integrator writes against the contract and picks up operators as they ship, instead of writing against each operator in turn. That is the design goal. The question this post addresses is how close the project has come to realising it, what is live in production in 2026, and what should still be treated as a spec with aspirations rather than a shipping product.

What CAMARA is, mechanically

CAMARA is a Linux Foundation project launched at Mobile World Congress 2022, jointly backed by GSMA. The project's output is a family of OpenAPI specifications defining network capabilities as REST endpoints: Number Verification, SIM Swap, Device Status, Device Location, Quality on Demand, Carrier Billing, Device Reachability, and several others. Each capability is specified to the level of request and response schemas, authorisation model, error codes, and consent-flow semantics.

GSMA Open Gateway is the commercial layer on top of CAMARA. Open Gateway federates operator implementations of the CAMARA APIs behind a common developer-portal surface and a common authentication model: OpenID Connect, often paired with Client-Initiated Backchannel Authentication for consent-gated APIs. An integrator reaches Open Gateway, Open Gateway federates to the operator that actually serves the subscriber in question, and the operator's CAMARA-compliant implementation resolves the query and returns a CAMARA-schema response.

The first validated API was Quality on Demand, specified for triggering QoS upgrades or guarantees on a specific session. A 2024 IEEE INFOCOM paper using Nokia's Network-as-Code platform demonstrated QoD triggering in a port-logistics testbed on a 5G Standalone network. The round-trip performance was adequate for synchronous integration flows, and the QoD change propagated to the radio layer within hundreds of milliseconds. The demonstration matters for the broader CAMARA thesis: the APIs are real, they resolve to actual network operations, and integrators can rely on the results.

What is live in production, what is in draft

The CAMARA catalogue has roughly three maturity tiers, though the project does not label them that way.

Tier one (shipping at meaningful scale): Number Verification is the clearest example. Multiple operators across Europe and North America have production implementations. The API takes an application-initiated OIDC request, resolves the cellular data session to an MSISDN at the operator's authorisation server, and returns an ID token bearing the MSISDN claim. This is the underlying primitive for silent-auth products from multiple vendors. SIM Swap is approaching the same tier, with the retrieve-date and check endpoints specified and implemented by a subset of operators while the rest federate through Open Gateway partners.

Tier two (specified and demonstrated, deployment uneven): Quality on Demand falls here. Device Location falls here in most geographies. Device Status (reachability, roaming state) falls here in its richer forms. The specifications are stable, and operators who have implemented them work as described, but the set of operators who have implemented them is smaller than tier one. For integrators, the practical implication is that a product built around tier-two APIs needs a clear fallback when the user's home operator is not yet integrated.

Tier three (in draft, early pilots): Carrier Billing variants, richer Device Identifier flows, and Network-as-Code primitives for slicing and QoS composition sit at this level. Integrators should treat these as forward-looking signals of where CAMARA is going, not as production surfaces to build against today.

The accurate way to describe 2026 CAMARA status on a product page is not "available globally" (that is not true of any tier-one API, let alone tier three) but "available on these operators, federated via Open Gateway for these partners, with coverage expanding." The NTT Technical Review survey documents this granular state and names specific early-adopter operators including KDDI and NTT DoCoMo in Japan, alongside European and US carriers with publicly announced participation. Any integrator checking coverage for a specific country should go to the Open Gateway partner list rather than rely on a vendor's aggregated claim.

What the standardisation actually changes

Three things change at the integration layer: portable authentication, portable fraud signals, and portable consent.

Portable authentication: before CAMARA, every operator's authentication-as-a-service product had its own OAuth scopes, its own token format, its own subscriber-identifier semantics. Integrators who wanted coverage in five countries built five integrations. With CAMARA Number Verification, the token format is specified, the MSISDN claim is specified, and the authorisation-server flow is specified as OIDC with the operator in the authorisation-server role. The integrator writes one client and federates through Open Gateway to pick up operators as they participate.

Portable fraud signals: SIM Swap is the template case. Before CAMARA, an integrator wanting cross-operator SIM-swap detection either queried each operator's bespoke API or inferred swaps from HLR probes. With CAMARA SIM Swap, the retrieve-date endpoint returns an ISO-8601 timestamp, the check endpoint returns a boolean, and the response shape is identical across participating operators. The integrator writes one parser and trusts the contract.

Portable consent: several CAMARA APIs are consent-gated, with Device Location as the canonical example. The consent flow is specified as OIDC CIBA, a backchannel mechanism where the subscriber is prompted on their device to approve the relying party's query. Before CAMARA, consent for each operator looked different (some used SMS confirmation, some used a push to a carrier app, some used none at all), and the relying party could not depend on any common semantics. CIBA does not solve every consent problem, but it specifies one.

What CAMARA does not change

CAMARA does not invent new signalling primitives. SIM Swap still resolves against the operator's HSS provisioning trail. Number Verification still rests on the EPS-AKA exchange at network attach. Device Reachability still pulls from the HLR or HSS as always. CAMARA wraps these operations in a portable contract. The underlying operator infrastructure is unchanged.

CAMARA also does not federate every operator. A country where only one of three operators is a CAMARA participant produces different coverage depending on which operator serves the subscriber. Integrators working in such countries are federating in name but pivoting to fallback paths in practice, because the subscriber often does not happen to be on the participating operator.

CAMARA does not guarantee semantic equivalence across operators. The schema is portable, but the data behind the schema is not uniform. One operator's "SIM changed recently" response might reflect an HSS provisioning write in real time. Another's might reflect a nightly batch of the same data. Both are compliant with the schema. Integrators who depend on sub-hour granularity need to verify which operators provide it.

Buying criteria for 2026

Four practical questions matter when evaluating an operator's CAMARA offering.

Does the operator ship CAMARA-native APIs, or only a translation layer? A native operator maintains schema parity as CAMARA versions advance. A translation-layer vendor lags the spec.

Is the operator a GSMA Open Gateway partner, or outside federation? Outside-federation coverage is useful only for that operator's subscribers. Inside-federation coverage scales as the partner list scales.

Does the operator publish per-endpoint coverage data showing which countries and which operators are supported, or does it claim "global" without a breakdown? The former is a signal of careful engineering. The latter is usually incomplete.

Does the operator ship the consent-gated tier-two APIs (Device Location, richer Device Status), or only the non-consent tier-one set? Operators that ship only the easy half are partial partners.

How Tensormobile ships CAMARA

A licensed operator building APIs in 2026 has a choice: ship the CAMARA schemas as the native API surface, or ship a proprietary schema and offer CAMARA as a translation layer on top. The choice is not just technical packaging. It signals whether the operator is committed to the portable-contract thesis.

Tensormobile ships CAMARA-native where CAMARA has a tier-one or tier-two specification. SIM Swap, Number Verification, Device Reachability, and the consent flow for Device Location follow CAMARA schemas directly. The proprietary TensorShield and TensorAuth endpoints are secondary surfaces. Integrators who want pure CAMARA compliance get it as the default. Integrators who want the proprietary extensions (richer fraud signals, bundled risk scores, custom error codes) opt in explicitly.

The argument for going CAMARA-native: every month a new operator ships CAMARA compliance, an integrator working against the same schema picks up that operator without a code change. The counter-argument, that a proprietary schema would be richer, does not hold up against the spec. CAMARA schemas are simple, composable, and extensible through well-defined patterns. The richness lives in the composition, not in any individual endpoint, and the composition works better when the endpoints are portable.

For integrators evaluating CAMARA in 2026, the project is the industry's first real attempt at portable network APIs and the first one with a credible chance of succeeding. The shipping APIs are real, the schemas work, the federation is partial but growing. The accurate frame is work-in-progress with a specific coverage footprint, not a finished standard with uniform global availability.