Attestation

Attestation is how your backend convinces itself — and eventually an auditor — that a verdict really came from iLive, not from a user tampering with the redirect.

What ships today

The current design treats the session_id plus its session token as the handle, and the server-side fetch as the source of truth:

1. Your backend creates the session via POST /api/v1/managed-session using your API key. The response includes a session_id and a single-use token. Store both.
2. The user completes the flow. iLive redirects them back to your redirect_url with the session_id in the query string and — if configured — POSTs a verdict notification to your webhook_url.
3. Your backend pulls the verdict from GET /api/v1/session/{id}/result?token=.... The token is constant-time compared server-side; anyone without the token gets a 401/404.
4. Your backend pulls the photo from GET /api/v1/session/{id}/photo?token=.... The URL is also token-guarded.

Because the definitive verdict read goes straight from your server to iLive over TLS with the session token, a tampered redirect cannot change the result. Treat the webhook as a push-notification convenience and the /result call as the authoritative answer.

What's on the roadmap

Signed verdict payloads are the next step. The plan:

• What's signed. The verdict tuple (session_id, verdict, confidence, timestamp, photo_sha256).
• Algorithm. Detached Ed25519 signatures, base64url-encoded in a signature field alongside the verdict body.
• Key distribution. A published JWKS document at a stable URL, with key rotation supported via kid headers.
• Verification. A short, copy-pasteable snippet in the language tabs on this page, analogous to the webhook receiver examples.

When that lands, you'll be able to verify verdicts entirely offline — no round-trip to /result required. Until then, the session_id + token + server-side fetch pattern above is the supported way to establish trust.

Related: Managed sessions · Webhooks.