Skip to main content
Authmatech confirms a customer’s mobile identity silently — no OTP — and adds trust scoring, fraud protection, and behavior intelligence on top. The questions below cover the essentials. If you don’t find your answer, reach the team at support@authmatech.com.
Sign in to the Authmatech dashboard. You’ll find your Client ID (sent as X-CLIENT-ID) and can generate an API key (sent as X-API-KEY). The raw API key is shown once at generation — store it in a secrets manager. If you lose it, rotate to issue a new one. See Authentication.
  • API key (X-API-KEY) — server-side secret for all /v1/api/** calls. Never ship it to the browser.
  • Client ID (X-CLIENT-ID) — identifies your account; sent on every request.
  • SDK token (X-SDK-TOKEN) — narrow-scoped, browser/mobile token that can only register sessions at /v1/api/sdk/session. Safe for client code.
  • Client secret — long-lived secret that unlocks sensitive operations like API-key rotation.
See Credential types.
On a mobile data connection, the Authmatech SDK obtains an operator-signed proof that the device controls a specific number (header enrichment). Your backend sends that proof plus the claimed number to POST /v1/api/verify, and Authmatech confirms the match. No SMS is sent and the customer types nothing. See How silent verification works.
No. Silent verification needs the network identity from an active mobile data connection. On Wi‑Fi, VPN, or some roaming networks, the SDK can’t produce a proof. Plan a fallback — Stuck+ is built to recover these customers without dropping back to an OTP.
Use the sandbox with sandbox credentials from the dashboard. Request shapes and headers are identical to production. You can call any endpoint with cURL, Postman, or your HTTP client. See Testing & environments.
E.164: a leading +, the full country code (no leading zero), and the subscriber number with no spaces, dashes, or parentheses.
RegionCorrectIncorrect
Jordan+9627912345670791234567
UAE+971501234567050 123 4567
Saudi Arabia+9665123456780512345678
A bad format surfaces as 400 Bad Request with INVALID_MOBILE_NUMBER.
400 covers more than malformed JSON. The most common causes are a product that isn’t enabled for your account (e.g. calling Shield without Shield enabled) and insufficient or expired balance. Read messages[].message in the response — it tells you which. See Errors.
Every response uses the same envelope: { "success": ..., "messages": [...], "data": ... }. Read your result from data, and treat success: false or a non‑200 status as an error. Note that a verification returning data.validNumber: false is a successful call with a negative verdict — not an error. See Errors & responses.
Each account has a generous per-client request budget (1,000 requests per minute by default). If you ever exceed it, the API returns 429 Too Many Requests — handle it with exponential backoff. If you expect sustained high volume, contact sales@authmatech.com to raise your limit. See Rate limits.
The suite includes Verify, Web, Trust, Shield, Detect, Stuck+, Connect, and Target. Products are enabled per account — check GET /v1/api/me/products or the dashboard. To enable a product, contact sales@authmatech.com. See the product suite.
Yes — the Web SDK (authmatech-sdk-web) is on npm and handles browser verification end to end. Native iOS, Android, and Flutter packages are provisioned per integration; see Mobile SDKs.
Sensitive values are protected throughout the flow: the SDK only exposes a masked form of the identity token client-side, the raw proof is verified server-side with your API key, and identity tokens are hashed when sessions are stored. Keep your API key and client secret server-side at all times.
Email support@authmatech.com. The team is based in Amman, Jordan and responds during MENA business hours (Sun–Thu, 09:00–18:00 Amman time). For sales and product enablement, contact sales@authmatech.com.