Skip to main content
Authmatech Verify confirms that a customer controls the mobile number they present — silently, with no OTP. This guide covers the server-side integration: the request, the response, and the edge cases worth handling.
The encrypted code (encryptedMobileNumber) and operatorId are produced on the device by the Authmatech SDK after the silent check. This guide assumes your client has already obtained them and forwarded them to your backend. For the browser flow end to end, see Web verification.

​
The request

Call POST /v1/api/verify from your backend with both auth headers.

​
Body fields

​
string
required
The number the customer claims, in E.164 format (e.g. +962791234567).
​
string
required
The encrypted identity code returned by the SDK. Authmatech validates this against mobileNumber.
​
string
The mobile operator that confirmed the session (e.g. ZAIN_JO, ORANGE_JO). Optional but recommended.
​
string
The use case driving the verification. One of REGISTRATION, LOGIN, RESET_PASS, UPDATE_DETAILS, or TRANSACTION. Used for analytics and risk context.
​
string
Optional. The session id returned by the SDK after session registration. When present, the verification is linked to the stored device context so Shield and Detect can reason about it.

​
Query parameter

​
boolean
default:"false"
When true, the response includes a masked copy of the confirmed number (e.g. ********67). This corresponds to the Verify N+ product and may be priced differently from a plain validity check.

​
The response

​
boolean
The verdict. true means the customer controls the number they presented.
​
string
Present only when maskMobile=true. A masked copy of the confirmed number for display or audit.
A validNumber: false is a successful API call (HTTP 200) with a negative verdict — not an error. Branch your application logic on data.validNumber, and reserve error handling for non-200 responses and success: false.
1

Collect the code on the client

The SDK runs the silent check and registers a session, giving you encryptedMobileNumber, operatorId, and sdkSessionId.
2

Forward to your backend

Send those values plus the claimed mobileNumber to your own server over TLS. Never call Verify from the browser — the API key must stay server-side.
3

Verify and act

Call POST /v1/api/verify. On validNumber: true, continue the journey. On false, offer Verify+ or a secondary check — the not-matched journey is captured in Stuck+ for win-back.
4

Optionally score the action

Pass the same sdkSessionId to Trust or Shield to add a confidence score or risk decision.

​
Verify+ for mistyped numbers

Customers fat-finger digits, miss a number, or invert a pair. With most flows, that’s the end of the journey. Authmatech Verify+ keeps them moving by returning a secure, privacy-preserving identity hint — a masked copy of the confirmed number — without ever revealing full information. Verify+ is the same endpoint with ?maskMobile=true:
Show the masked ending (********67) so the customer can confirm or correct their entry — guiding them back on track without exposing the full number. Verify+ may be priced differently from a plain validity check; check your plan.

​
Handling failure modes

API: Verify a number

Full reference with an interactive playground.

Web verification

The browser flow, end to end.