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 proof (encryptedMobileNumber) and operatorId are produced on the device by the Authmatech SDK after header enrichment. 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. 
curl -X POST "https://service.authmatech.com/v1/api/verify?maskMobile=false" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "X-CLIENT-ID: YOUR_CLIENT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "mobileNumber": "+962791234567",
    "encryptedMobileNumber": "BASE64_ENCRYPTED_BLOB_FROM_SDK",
    "operatorId": "ZAIN_JO",
    "serviceType": "LOGIN",
    "sdkSessionId": "b1f2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d"
  }'

​
Body fields

​
mobileNumber
string
required
The number the customer claims, in E.164 format (e.g. +962791234567).
​
encryptedMobileNumber
string
required
The encrypted proof of possession returned by the SDK. Authmatech decrypts and validates this against mobileNumber.
​
operatorId
string
The mobile network operator that enriched the session (e.g. ZAIN_JO, ORANGE_JO). Optional but recommended.
​
serviceType
string
The use case driving the verification. One of REGISTRATION, LOGIN, RESET_PASS, UPDATE_DETAILS, or TRANSACTION. Used for analytics and risk context.
​
sdkSessionId
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

​
maskMobile
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

{
  "success": true,
  "messages": [
    { "type": "SUCCESS", "code": null, "message": null, "httpStatus": "OK" }
  ],
  "data": {
    "validNumber": true,
    "mobileNumber": "********67"
  }
}
​
data.validNumber
boolean
The verdict. true means the customer controls the number they presented.
​
data.mobileNumber
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 proof on the client

The SDK performs header enrichment 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, fall back to Stuck+ or a secondary check.
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: 
curl -X POST "https://service.authmatech.com/v1/api/verify?maskMobile=true" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -H "X-CLIENT-ID: YOUR_CLIENT_ID" \
  -H "Content-Type: application/json" \
  -d '{ "mobileNumber": "+962791234567", "encryptedMobileNumber": "…", "operatorId": "ZAIN_JO", "serviceType": "REGISTRATION" }'

{ "data": { "validNumber": true, "mobileNumber": "********67" } }
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

SituationWhat you’ll seeWhat to do
Customer controls the number200, validNumber: trueContinue
Number doesn’t match the proof200, validNumber: falseOffer Verify+ as a hint, then Stuck+ or retry
No mobile data / Wi‑Fi onlySDK can’t produce a proofFall back to manual entry + Stuck+
Missing/invalid credentials401Check X-API-KEY and X-CLIENT-ID
Product disabled or balance expired400 with a messageCheck plan/balance; see Errors

API: Verify a number

Full reference with an interactive playground.

Web verification

The browser flow, end to end.