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, the mobile network can confirm the number tied to that connection. Authmatech uses this to silently confirm number ownership and return an encrypted identity result — with no code sent, received, or typed. Your customer never sees a code. There is nothing to wait for and nothing to type. Confirmation typically completes in about a second.
Because the check runs over 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, such as manual entry or retrying on mobile data.

​
The end-to-end flow

This is the native mobile flow. The browser flow is transaction-based — see Web verification.
1

The SDK runs the silent check

On the device, the Authmatech SDK runs the silent check over the mobile-data connection. The mobile network confirms the number and the SDK receives an encrypted identity code (authmatechCode) plus the operator id (MNOID).
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. Only a masked form of the identity code is ever shown client-side.
3

Your backend verifies

Your app forwards authmatechCode, MNOID, and sdkSessionId to your backend. Your backend calls POST /v1/api/verify with the secret X-API-KEY, passing the claimed mobileNumber alongside the encrypted code.
4

Authmatech confirms the match

Authmatech validates the encrypted code 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. mobile verification

Authmatech exposes two verification paths for two situations:
  • Mobile (POST /v1/api/verify) — the native mobile SDKs confirm the number on the device and return the encrypted code (encryptedMobileNumber) and operator id. Your backend submits those to complete the verification.
  • Web (POST /v1/api/verify/{transactionId}) — the Web SDK runs the silent check for a transactionId, and your backend resolves the confirmed number for that transaction. See Web verification.

​
Why it’s hard to spoof

  • The identity code is bound to the live mobile-network connection — it can’t be replayed from a different device or fabricated client-side.
  • The raw code is never trusted from the client 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, one device linked to many numbers).

​
What you receive

A verification returns a compact verdict:
Add ?maskMobile=true to also receive a masked copy of the confirmed number for display or audit:

​
Next steps

Verify guide

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

Web verification

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