Architecture
The golden rule: the API key never leaves your server. The browser only receives a transaction id and a check URL; your backend resolves the result with theX-API-KEY.
The web flow is transaction-based — the browser SDK takes a
transactionId and checkUrl, and your backend resolves the verdict by that same transactionId. (The X-SDK-TOKEN and /v1/api/sdk/session flow belongs to the native mobile SDKs, not the Web SDK.)Step 1 — Issue a transaction id from your backend
Your backend creates thetransactionId for this verification (format prefix-<UUIDv4>, where the prefix is provided by Authmatech) and hands it, plus the checkUrl, to the page. Keep your API key server-side.
Step 2 — Run the silent check in the browser
Step 3 — Verify on your backend
Your endpoint resolves the verdict by transaction id with the secret API key:data.validNumber. A validNumber: false is a successful 200 with a negative verdict — not an error.
Step 4 — Handle the fallback
The silent check needs an active mobile-data connection. On desktop, Wi-Fi, or VPN it can’t complete. Detect that case and fall back gracefully — show manual entry or ask the customer to switch to mobile data, rather than dropping back to an OTP.Requirements & constraints
- Mobile browser, mobile data — the silent check can’t complete on desktop or over Wi-Fi/VPN.
- Secure context — the page must be served over HTTPS, and
checkUrlmust behttps. - Never client-side keys — the browser only ever sees the
transactionIdandcheckUrl; the API key stays on your server.
Related
Web SDK reference
Full configuration and the
initAuthmatechCheck API.API: verify (Web)
Resolve a verification by transaction id.

