Hosted or headless

Get started

Two ways in, one rail underneath. The difference is who writes the screen the person sees and who handles the proof — not what gets enforced, and not what the receipt says.

Hosted Headless You need An API key and a redirect An API key, the SDK, and a frontend The screen Ours, white-labelled as yours Yours, every pixel The proof Never touches your code The SDK hands it to your server You get the result session.completed + GET /sessions/{id} In the endpoint response Receipts Identical Identical Price Identical. White-label included in the free tier. Identical

The hosted flow

01 Your server calls POST /sessions with a mode and a return_url . 02 You redirect the person to the returned url . Single-use, 30 minutes. 03 The reading happens on their device, on our screen. Nothing biometric reaches either of us. 04 We fire session.completed and send the person to your return_url . 05 You read GET /sessions/{id} and continue. That response is the truth; the query string is a hint.

White-label

The hosted screen is yours visually. Logo, accent colour, headline, footer note and your own hostname — set branding on the session. Included in the free tier, not an upgrade.

branding

"branding": { "logo_url": "https://acme.example/logo.svg", "accent": "#2DD48F", "domain": "id.acme.example", "headline": "Authorise your assistant", "footer_note": "Acme never sees your documents." }

For domain , point a CNAME at Sidaxis and register the host in the console — the same allowlist that governs return_url . The certificate is issued for you. Which one to pick Start hosted. It is the shortest path to a real mandate and it removes the part of the integration you would otherwise have to maintain — camera permissions, retries, accessibility, device quirks. Move a flow to headless when the screen itself is the product. See also Reference: create a session → Reference: read a session result → Webhooks →