Skip to main content
Both calls on this page require your secret key. The sst_ client token can never reach them.

Reading the result

When your client reports completion, fetch the session by id:
Response
The verification rule: the user is verified only when status is "complete" and decision is "real". Everything else — "spoof", failed, expired, or a value relayed by the client — is not verified.

The risk object

  • signals.duplicate_image — this exact capture was already submitted in another of your sessions; a soft signal worth reviewing.
  • attestation — status of device attestation (e.g. Play Integrity) when provided by the SDK.
  • Injection-blocked sessions: when a capture was rejected for suspected injection (e.g. a known virtual camera under the enforce policy), decision is "spoof", checks is null, and risk is exactly { "injection_blocked": true, "reason": "suspected_injection" }. Scores and signal details are deliberately withheld so a flagged session can’t be used to probe the detectors.

Retrieving the captured selfie

Liveness and deepfake checks say the face is real — not whose it is. If you match the capture against an ID document, keep KYC records, or run manual review, retrieve the exact image the models scored:
  • The image is available as soon as the decision is — it uploads during capture, so there’s nothing to poll.
  • url is a signed link valid for 5 minutes. Fetch the bytes immediately; don’t store the link.
  • Verify your download against sha256 — it hashes the exact bytes the models scored, and matches the SDK’s capturedFrameSha256.
  • Every retrieval is written to your organization’s media access log, keeping biometric access auditable.

When media isn’t available

GET …/media returns 404 MEDIA_NOT_AVAILABLE, and the session read’s media block explains why: Media storage, retention windows, and erasure are controlled per organization in the console’s compliance settings.