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 connect@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 token the native mobile SDKs use to register a session at /v1/api/sdk/session; it can’t call any other API. Safe for app code. (The browser Web SDK is transaction-based and uses no credential client-side.)
  • Client secret — long-lived secret that unlocks sensitive operations like API-key rotation.
See Credential types.
On a mobile-data connection, the Authmatech SDK silently confirms with the mobile network that the device controls the number, and receives an encrypted identity code. Your backend sends that code 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 complete the silent check. Plan a fallback — for example, manual entry or asking the customer to switch to mobile data — rather than 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.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 connect@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 connect@authmatech.com. See the product suite.
Yes — the Web SDK (authmatech-sdk-web) is on npm for silent verification in the mobile browser. Native iOS, Android, and Flutter SDKs are provisioned per integration; see Mobile SDKs.
Sensitive values are protected throughout the flow: the SDK only exposes a masked form of the identity code client-side, the raw code is verified server-side with your API key, and identity codes are hashed when sessions are stored. Keep your API key and client secret server-side at all times.
Email connect@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 connect@authmatech.com.