Let a bank or an app verify a number, a SIM change or a location from the network itself, with the customer's consent recorded.
Number verification, SIM swap, know-your-customer, location and device signals are exposed through CAMARA and GSMA Open Gateway interfaces, metered and operated within the operator's API policy.
For Network API business, fraud and digital identity teams, and the developers who integrate the operator's capabilities.
Six things an enterprise actually asks the network for.
Each one uses a published CAMARA API. Choose a task to see the request, what comes back, what refuses it, and who decides afterwards.
Verify a mobile number during onboarding
Somebody is opening an account and typing in a phone number. Nothing yet says the number is theirs, or that the handset in their hand is the one it belongs to.
- Who is asking
- The bank or application's onboarding service, as the API consumer.
- How the subscriber is identified
- The number the customer typed, or a SHA-256 hash of it. The hash form lets the check happen without the number leaving the caller in the clear.
- Permission required first
- The customer authenticates over the mobile network. The specification names silent network authentication; nothing is verified about a device that did not authenticate that way.
- Official API
number-verification2.1.0 · r3.2 (Fall25)
- Requesting applicationEnterprise
The bank or application's onboarding service, as the API consumer.
- Aggregator or HeuriTel orchestrationHeuriTel
Routes the request and records it.
- Operator exposure layerOperator
Authenticates, applies operator policy and consent.
- Network capabilityOperator
The Number Verification API is used by the API consumer to perform real-time checks to verify the phone number of a mobile device being used to access the application.
- Bounded responseOperator
devicePhoneNumberVerified: a boolean. Match, or no match.
- Enterprise decision systemEnterprise
The bank's own onboarding and risk system decides whether to open the account. A match is one input to that decision.
What is called
POST /verify — { phoneNumber } or { hashedPhoneNumber }GET /device-phone-number — the number associated with the access token
OpenID Connect · scope number-verification:verify
What comes back
devicePhoneNumberVerified: a boolean. Match, or no match.
Still to be decided by the caller. Whether to open the account. A true here means the number matches the device that authenticated on the mobile network — it is not an identity check, a credit decision or an approval.
What refuses it
- 400 INVALID_ARGUMENT — the request is malformed
- 401 UNAUTHENTICATED — missing, invalid or expired credentials
- 403 PERMISSION_DENIED — the token lacks the scope
- 403 NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_MOBILE_NETWORK — the device did not authenticate over the mobile network, so there is nothing to compare against
Before any of this can be tried
- An operator or aggregator that exposes the API in this market
- Client credentials and the number-verification:verify scope
- A data-controller position agreed for the number and the hash
- A defined behaviour when the device is not on the mobile network
The specification, and its limits.
A published specification is not a service you can buy. CAMARA defines the API; whether a particular operator has deployed it, in a particular market, on commercial terms, is that operator’s fact to state. None of it is assumed here.
| API | Family | Version | CAMARA maturity | Operator availability | HeuriTel | Source |
|---|---|---|---|---|---|---|
number-verificationNumber Verification | Identity and fraud | 2.1.0r3.2 (Fall25) | stable | Not verified — confirm per operator and market | HeuriTel simulation | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
sim-swapSIM Swap | Identity and fraud | 2.1.0r3.3 (Fall25) | stable | Not verified — confirm per operator and market | HeuriTel simulation | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
one-time-password-smsOne-Time Password (SMS) | Identity and fraud | 1.1.1r3.2 (Fall25) | stable | Not verified — confirm per operator and market | Not started | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
location-verificationLocation Verification | Location and device | 3.0.0r3.2 (Fall25) | stable | Not verified — confirm per operator and market | Not started | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
quality-on-demandQuality on Demand | Connectivity and quality | 1.1.0r3.2 (Fall25) | stable | Not verified — confirm per operator and market | Not started | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
device-reachability-statusDevice Reachability Status | Location and device | 1.0.0r2.2 (Spring25) | stable | Not verified — confirm per operator and market | Not started | CAMARA Project (Linux Foundation)Checked 2026-09-03 |
Fall25, announced 2025-10-07: “With the meta-release Fall25, CAMARA now has 60 total APIs: 10 stable, 27 updated since the Spring25 meta-release, and 23 new initial APIs.” CAMARA Project (Linux Foundation), checked 2026-09-03.
CAMARA describes itself as “an open source project within Linux Foundation to define, develop and test the APIs, in collaboration with the GSMA Operator Platform Group” CAMARA Project (Linux Foundation), checked 2026-09-03.
The other four APIs CAMARA lists as stable in Fall25 are Device Roaming Status, Device Swap, Simple Edge Discovery, Verified Caller. They are named here rather than featured because no task above needs them; the full set is in the API console.
Availability is the first question, not the last.
Every task above begins with an operator that exposes the capability in your market, credentials scoped to it, and an agreed position on who controls the data. A working session establishes those before anything is built.