Zero-retention sessions

​

Enable it

1. Ask support to enable ephemeral sessions for your tenant: sessions.create in data_processing_config.allowed_ephemeral_endpoints, or the tenant in ephemeral mode.
2. Use a workflow marked zero_retention_ready. These workflows only contain form_fill, document_upload (image identity documents), selfie and terms_acceptance steps.
3. Create the session with the X-Data-Retention: ephemeral header (or "data_retention": "ephemeral" in the body):

curl -X POST https://kyc.legaltalent.ai/kyc/sessions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-Data-Retention: ephemeral" \
  -H "Content-Type: application/json" \
  -d '{ "workflow_id": "YOUR_ZERO_RETENTION_WORKFLOW_ID" }'

​

What changes in the flow

• Every step is captured locally; the applicant can go back through the pages until the request is sent.
• Liveness is the passive on-device check on the selfie. The server only runs the 1:1 face match. No capture clips are recorded.
• Images are downscaled (~1600 px JPEG) and EXIF is stripped before sending.
• After the last step the SDK sends one request and shows a “verifying” page. The server budget is 20 seconds.
• A transient failure (503 / 504) is retried once with the same bytes; retries are not charged twice. A 413 is re-encoded smaller and retried.

​

Receive the result

LegalTalentFlowView(
    accessToken: token,
    environment: .production,
    showsSingleSubmitOutcome: false,
    onComplete: { _ in dismiss() },
    onSingleSubmitResult: { outcome in
        switch outcome {
        case .decided(let result, let sentImageHashes):
            // result.status, result.reasonCodes, result.extracted,
            // result.faceMatch, result.risk, result.imageSHA256, result.attestation
            backend.store(result, sentImageHashes: sentImageHashes)
        case .decidedAfterTimeout(let sessionID):
            // Decided after the SDK's timeout: read it with GET /kyc/sessions/{id}
            backend.fetchOutcome(sessionID)
        }
    }
)

• status is only approved or rejected. There is no manual review: anything that would have gone to a reviewer comes back rejected with reason codes, and your app decides what to do.
• reason_codes are stable strings such as face_match_failed, list_match, document_invalid, document_forensics_suspicious or rule:<rule_type>. Screening results never include list names or matched identities.
• By default the applicant sees a neutral “done” page. Set showsSingleSubmitOutcome: true to let the SDK show the verdict; reason codes are rendered as applicant-safe sentences and screening hits are never disclosed.

​

Verify integrity

1. sentImageHashes (SHA-256 of the exact bytes the SDK sent) match result.imageSHA256.
2. result.attestation.signature verifies against result.attestation.public_key_pem (ECDSA_SHA_256). The signature can be null with an unsigned_reason in environments without a signing key.

​

Errors