> ## Documentation Index
> Fetch the complete documentation index at: https://docs.authmatech.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Silent Mobile Verification Works (No OTP)

> Understand how Authmatech confirms a customer controls their mobile number over the network — with no SMS, no one-time passcode, and nothing for the user to type.

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**.

<Note>
  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.
</Note>

## The end-to-end flow

This is the native mobile flow. The browser flow is transaction-based — see [Web verification](/guides/web-verification).

<Steps>
  <Step title="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`).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

```mermaid theme={null}
sequenceDiagram
    participant U as Customer device
    participant SDK as Authmatech SDK
    participant NET as Mobile network
    participant BE as Your backend
    participant AM as Authmatech API

    U->>SDK: Start verification
    SDK->>NET: Silent check (over mobile data)
    NET-->>SDK: Encrypted identity code + operator id
    SDK->>AM: POST /v1/api/sdk/session (X-SDK-TOKEN)
    AM-->>SDK: sdkSessionId
    SDK-->>BE: authmatechCode, MNOID, sdkSessionId, mobileNumber
    BE->>AM: POST /v1/api/verify (X-API-KEY)
    AM-->>BE: { validNumber: true }
    BE-->>U: Access granted
```

## Web vs. mobile verification

Authmatech exposes two verification paths for two situations:

* **Mobile (`POST /v1/api/verify`)** — the native [mobile SDKs](/sdks/mobile) 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](/sdks/web) runs the silent check for a `transactionId`, and your backend resolves the confirmed number for that transaction. See [Web verification](/guides/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](/guides/trust-shield-detect) and [Detect](/guides/trust-shield-detect) use to spot inconsistencies (new device, changed operator, one device linked to many numbers).

## What you receive

A verification returns a compact verdict:

```json theme={null}
{
  "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:

```json theme={null}
{ "data": { "validNumber": true, "mobileNumber": "********67" } }
```

## Next steps

<CardGroup cols={2}>
  <Card title="Verify guide" icon="circle-check" href="/guides/verify">
    The full server-side flow, parameters, and edge cases.
  </Card>

  <Card title="Web verification" icon="qrcode" href="/guides/web-verification">
    Run it end to end in the mobile browser with the Web SDK.
  </Card>
</CardGroup>