Skip to main content
Silent verification confirms that a customer genuinely controls the mobile number they present — without sending an SMS, without a one-time passcode, and without any action from the user. This page explains the mechanics so you can reason about your integration and its edge cases.

​
The core idea

When a device is on a mobile data connection, its traffic passes through its mobile network operator (MNO). The operator can confirm the number associated with that connection. Authmatech uses this — a process commonly called header enrichment — to obtain a cryptographic, operator-signed proof that the device controls a specific number. Your customer never sees a code. There is nothing to wait for and nothing to type. Confirmation typically completes in under 400 ms.
Because the proof comes from the mobile network, silent verification requires an active mobile data connection. On Wi‑Fi, VPN, or some roaming connections, the network identity may not be available — plan a fallback. Stuck+ is designed for exactly these cases.

​
The end-to-end flow

1

The SDK runs header enrichment

On the device (mobile app or mobile browser), the Authmatech SDK triggers an enrichment request over the cellular connection. The operator returns an encrypted identity token (the proof of possession) and an operator identifier.
2

The SDK registers a session

The SDK calls POST /v1/api/sdk/session using the narrow-scoped X-SDK-TOKEN header. Authmatech stores hashed device context linked to the session and returns an sdkSessionId. The raw identity token is never exposed in client logs — only a masked form is shown.
3

Your backend verifies

Your client forwards the encrypted token, operator id, and sdkSessionId to your backend. Your backend calls POST /v1/api/verify with the secret X-API-KEY, passing the claimed mobileNumber alongside the proof.
4

Authmatech confirms the match

Authmatech decrypts and validates the proof against the claimed number and returns a simple verdict: validNumber: true or false. Optionally it returns a masked copy of the confirmed number.

​
Web vs. direct verification

Authmatech exposes two verification paths for two situations:
  • Direct (POST /v1/api/verify) — used when the SDK already holds the encrypted proof (encryptedMobileNumber) and operator id. This is the standard mobile-app and Web SDK flow.
  • Web transaction (POST /v1/api/verify/{transactionId}) — used for browser flows that resolve the identity through a network transaction. Your backend supplies the transactionId, and Authmatech retrieves the confirmed number for that transaction. See Web verification.

​
Why it’s hard to spoof

  • The proof is operator-signed and bound to the live network connection — it can’t be replayed from a different device or fabricated client-side.
  • The raw identity token is never trusted from the browser for the final decision; your backend performs verification with the server-side API key.
  • The sdkSessionId ties the verification to a specific device context, which Shield and Detect use to spot inconsistencies (new device, changed operator, impossible travel).

​
What you receive

A verification returns a compact verdict: 
{
  "success": true,
  "messages": [{ "type": "SUCCESS", "httpStatus": "OK" }],
  "data": { "validNumber": true }
}
Add ?maskMobile=true to also receive a masked copy of the confirmed number for display or audit: 
{ "data": { "validNumber": true, "mobileNumber": "********67" } }

​
Next steps

Verify guide

The full server-side flow, parameters, and edge cases.

Web verification

Run it end to end in the browser with the Web SDK.