sst_ client token can never reach them.
Reading the result
When your client reports completion, fetch the session by id:Response
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
enforcepolicy),decisionis"spoof",checksisnull, andriskis 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.
urlis 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’scapturedFrameSha256. - 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.