Soliton Identity Verification

Two ways to integrate.

Both start with the same backend: your server creates a verification and fetches the verdict, server-to-server, with your API key. Choose Standard, Medium, or High liveness in that server request, then choose how your user reaches the camera step. The same verification link works either way, in sandbox and production.

Choose your hand-off

Pick one; you can switch later without backend changes.

Set liveness_tier on POST /api/v1/verifications: standard uses the camera, medium adds sound, and high adds sound and light. Omitting it keeps the existing High behavior. Both methods below automatically use the selected tier; no separate SDK or endpoint is needed. See the tier contract.

Server + redirect

The v1 REST API. Create a verification from your backend, redirect your user to the hosted page, fetch the verdict server-to-server. No frontend code, and the simplest path to production.

Web SDK (embedded)

Keep the user on your page: the same hosted flow in a full-screen overlay iframe instead of a redirect. A small browser library on top of the exact same backend API.

Not sure? Start with Server + redirect: it is the least code and needs nothing in the browser. You can move to the Web SDK later without touching your backend integration.

Before you start

What we need to provision your account.

Your account has two environments, sandbox and production, and your API key’s prefix chooses between them: sk_test_ is sandbox, sk_live_ is production. Each environment has its own credentials, its own verifications, its own redirect and iframe allowlists, and its own webhook endpoint with its own signing secret. Nothing crosses between them.

Accounts are provisioned by hand during the invite-only pilot. Send your Soliton contact whichever of these apply, and tell us which environment each value is for, and we will issue your credentials.

Redirect domains — the domains we may send your user back to after a capture. Required if you use redirect_url; without them that parameter is rejected. Registering a domain also covers its subdomains. Per environment: registering example.com for production does not register it for sandbox.
Iframe origins — required only for the Web SDK. The exact origin (scheme + host + port) of every page that will embed the flow. Not needed for the redirect integration. Also per environment, which is the point: https://dev.example.com can embed your sandbox links without being able to embed your production ones.
An HTTPS endpoint for completion webhooks — optional, and you can add it later. Polling works without it. One endpoint per environment, each with its own signing secret, so your staging receiver never has to handle (or be able to validate) production events.

Both allowlists are security boundaries rather than paperwork: the first stops your verification links being turned into open redirects, the second stops other sites embedding your flow and driving a camera capture under our permission grant. They are separate lists — registering one does not register the other — and they stay attached to your account when a credential is rotated. Wildcards are not accepted, and adding an iframe origin can require a Soliton deployment, so send them before you begin testing.

You can start with nothing registered at all: a sandbox credential exercises the full API, real captures, deterministic fixtures, portraits, and webhooks out of the box. The user simply lands on a “you may close this window” screen instead of being redirected. See Sandbox.