Number Verification

Silently verify that the phone number a user claims really belongs to the SIM in the device making the request without the need for OTPs, app prompts, or any type of user interaction.

Overview

Number Verification is a network-based authentication API built on top of the CAMARA open standard. It lets your application confirm, in real time, that the phone number a user provides matches the MSISDN of the SIM currently in the device making the request by relying on the mobile network's own identification of the subscriber.

In practice, this means the verification happens silently in the background: there is no SMS to wait for, no code to type or link to click. The user is identified by the cryptographic identity of the SIM itself, which the operator resolves to an MSISDN during the network handshake. Your application only ever sees a true/false answer.

Why it matters

Phone numbers are still one of the most common identity anchors on the internet: they gate sign-up flows, password recovery, payment confirmations, two-factor authentication and customer onboarding. At the same time, the dominant way of verifying them, the SMS OTP, was never designed as a security primitive, and the attack surface around it has grown steadily: SIM swap fraud, SS7 and signalling attacks, phishing and social engineering. Not to mention the issues in delivery and UX friction: SMS OTPs can be late, undelivered or blocked by carrier filters.

Number Verification removes the SMS from the loop entirely. Because the answer is produced by the user's own mobile network, based on the active data session of the device, there is no code to intercept, no message to phish and no delivery to fail. The verification is also passive from the user's point of view: in most cases all they see is a brief "verifying…" state before the flow continues.

Test Application

Plumma® Connect ships a hosted demo application that walks through the Number Verification user experience end-to-end. It is reachable from the Number Verification page in your sandbox, and its purpose is to show what a silent authentication looks like from the user's point of view, side-by-side with the OTP flow it replaces.

The demo simulates the full client journey: the user enters a phone number, sees a brief "verifying…" state, and is then forwarded to the post-authentication screen. It is meant to illustrate the flow and the absence of any code, link or prompt; it is not a functional test of the API.

Technical Information

Plumma® Connect exposes Number Verification as a single, unified API that is compliant with the CAMARA specification. Behind the API, Plumma® Connect aggregates multiple network sources and routes each call to the most appropriate one based on country, operator and service availability. This routing is handled internally by Plumma® Connect: you target one endpoint, against one set of credentials, and we take care of the rest.

End-to-end flow

Number Verification uses a two-phase pattern: a frontend authentication phase that establishes the user's network identity, followed by a backend API call that consumes the resulting access token.

The phone number to be verified is supplied by the integrator in the request body. How and when your application obtains it, whether at onboarding, at login, or anywhere else, is up to you.

1. Client-side authorization request. Your mobile application opens an authorization request to Plumma® Connect's authorization server.
2. Silent network authentication. The authorization server identifies the subscriber through the mobile data session on the device. The operator confirms the identity of the SIM through its own network-level authentication.
3. Access token issued. Plumma® Connect returns a short-lived, 3-legged access token bound to the verified subscriber identity.
4. API call. Your backend sends the access token to the Number Verification API and submits a candidate phone number for matching against the device's verified number.
5. Result. Plumma® Connect returns a boolean result.

The candidate number can be submitted either in clear E.164 format through the phoneNumber field, or as a SHA-256 hash through the hashedPhoneNumber field. Exactly one of the two must be present in each request.

Request body (plain):

{
  "phoneNumber": "+393331234567"
}

Request body (hashed):

{
  "hashedPhoneNumber": "32f67ab4e4312618b09cd23ed8ce41b13e095fe52b73b2e8da8ef49830e50dba"
}

Response (200 OK):

{
  "devicePhoneNumberVerified": true
}

Authentication

Number Verification requires a 3-legged OpenID Connect access token, obtained through a frontend authorization flow that runs over the user's mobile data connection.

Network requirements

Because the user's identity is established through the mobile network itself, the authorization step has some requirements on the underlying data connection:

These requirements reflect today's baseline. Newer authentication methods that lift the Wi-Fi restriction are being adopted across the industry, and Plumma® Connect will expose them as upstream coverage allows.

• The device must be connected through its mobile data network (4G, 5G NSA or 5G SA) at the moment of the authorization request.
• Wi-Fi connections are not supported for the authorization step, including Wi-Fi calling.
• VPNs are not supported: a VPN tunnel hides the mobile data session from the operator and breaks the identification.
• Mobile hotspot / tethering is not supported: the device requesting authentication must be the one with the SIM, not a device connected through someone else's hotspot.

Once the access token has been obtained, the API call itself is a regular HTTPS call from your backend and has no special network requirements on Plumma® Connect's side.

OTP fallback

Number Verification depends on two conditions being met at the same time: the user's operator must be reachable through Plumma® Connect's network coverage, and the device must be on a compatible mobile data session. When either condition fails, the verification cannot be completed silently. To keep your integration robust, Plumma® Connect performs an automatic OTP-based verification, and returns the verification result using the same response shape.

Phone number format

All phone numbers handled by this API must be in E.164 international format: a leading +, followed by the country code, followed by the subscriber number, with no spaces, dashes or parentheses. For example, an Italian mobile number is represented as +393331234567, not 003393331234567 or 3331234567.

When supplying a hashed number, the input to the SHA-256 function must be the E.164 string itself, including the leading +. The resulting hash must be lowercase hexadecimal, exactly 64 characters long.

Errors

Errors follow the standard Plumma® Connect error envelope. See the Status and Errors page for the full list of codes and their meaning.