Skip to main content
GET
Sessions
Manage KYC onboarding sessions for end users. Sessions track progress through workflows, store document uploads, and manage the onboarding process from creation to approval.

Overview

Sessions represent individual KYC onboarding processes for end users. Each session:
  • Links to a Workflow: Defines the steps and requirements
  • Tracks Progress: Monitors which steps are completed
  • Stores Documents: Uploaded documents are stored securely
  • Runs Validations: Automated checks (watchlists, crypto, adverse media, face match)
  • Public Access: End users access sessions via public access tokens

Endpoints

Authentication

Requires kyc:create permission for creating sessions and kyc:read permission for retrieving sessions. Include your Bearer token in the Authorization header.

Create Session

Create a new KYC onboarding session for an end user.

Endpoint

Request Body Parameters

Subject data

Use subject_data to declare facts your integration already knows about the subject before the end user opens the public link. Values are stored on the session, echoed in GET /kyc/sessions/{session_id}, and consumed during processing. Each value may be a plain scalar or an envelope object:

Website URL (web validation)

If any of the following keys holds a non-empty URL string, the platform runs web validation for that URL when the session is processed — even when the end user never fills a website field in the public form: Duplicate URLs are validated once. If the workflow also has an auto-validated URL form field and the user submits the same URL, you are not charged twice. Optional companion keys improve the web validator context (same semantics as POST /kyc/web-validation):
Declaring a URL in subject_data consumes one web_validation_checks unit at session creation, the same as when the workflow defines an auto-validated URL field. Processing runs automatically when the session completes if the workflow has auto_process enabled (default for most templates).
Web validation summary (triggered automation rules) is delivered in session webhooks. The full web_validation_results payload is available via the Sessions API after processing — see Web validation results.

Individual KYC (pre-declared person)

For individual identity workflows (IDV / KYC), pass attributes you already know about the person in subject_data at creation time. The platform stores them on the session and uses them during processing — before the end user completes the public form.
subject_data is tenant/backend data. It is not returned by the public session API and does not pre-fill the end-user form. Cross-validation compares what the user declared in the public form against extracted document data — not your pre-declared subject_data.
Example — create a session when you already know the subject is Federico Gil:
After the session completes and is processed, check processing_results.external_validations.lists_check — when the workflow has validation_config.run_lists enabled, screening includes a subject with "source": "subject_data" even if the user has not yet filled the public form:
Unlike website URLs, declaring a person name in subject_data does not consume extra quota at creation. Sanctions screening only runs when the workflow has run_lists: true (or equivalent automation configuration).

Request Example

Response Format

The custom_tags field is a snapshot of the workflow’s custom_tags at the time the session was created. If you later update the workflow’s tags, existing sessions retain their original tags. These tags are included in all session webhook payloads.

List Sessions

Retrieve all sessions for your tenant with pagination, filtering, and optional summary statistics.

Endpoint

Query Parameters

Request Example

Response Format

Summary Statistics

When include_summary=true, the response includes aggregate statistics for all sessions matching the filters (not just the current page):
The summary requires scanning all matching sessions, which may increase response time for tenants with many sessions. Use filters (workflow_id, date range) to limit the scope when possible.

Get Session Details

Retrieve detailed information about a specific session.

Endpoint

Request Example

Response Format

Process Session

Process a completed session - extract document data, run cross-validation, face matching, and external validations. This is the main endpoint to call after a session is completed to get final results.

Endpoint

Request Example

Response Format

Processing Results Fields

Web validation results

Each entry in processing_results.web_validation_results corresponds to one URL that was validated — from a workflow form field with auto_validate, or from subject_data at creation time. Retrieve results with:
  • GET /kyc/sessions/{session_id} — after status is processed, approved, rejected, or manual_review
  • POST /kyc/sessions/{session_id}/process — triggers processing manually and returns the same processing_results object
Session webhooks include web validation decisions inside automation_result.triggered_rules (e.g. web_ssl, web_industry, web_score), not the full web_validation_results array. See Session webhooks — web validation.

Update Session Status

Manually update the status of a session. Use this endpoint for reviewer decisions and operational transitions such as reactivating a session.

Endpoint

Request Body Parameters

Request Example

Response Format

Request Client Corrections

Request remediation from the end user for specific workflow steps, fields, or document types. The session moves to awaiting_client_correction, affected steps move to needs_correction, and the existing public access link remains valid. Use this when a reviewer needs the customer to fix submitted data or replace documents instead of approving or rejecting immediately.

Endpoint

Request Body Parameters

Each item in corrections supports:

Request Example

Response Format

When corrections are requested, any current terminal final_decision fields are cleared so the session is no longer displayed as currently approved or rejected while remediation is pending.
Generate or regenerate the public access link for a session. Use this to get a new link if the previous one was compromised or needs to be refreshed.

Endpoint

Request Example

Response Format

Extend Session Expiration

Extend a session’s public access link. This is useful before requesting corrections if the original link has expired.

Endpoint

Request Body Parameters

Request Example

Run Validation Checks

Manually trigger validation checks for a session without full processing.

Endpoint

Request Example

Response Format

Get Document URL

Get a presigned URL to download a document from a session.

Endpoint

Request Example

Response Format

Delete Session

Delete a session and all associated data.

Endpoint

Request Example

Response Format

Session Statuses

Canonical Compliance Statuses

List responses include compliance_status, a stable operational status for queues and dashboards. It groups low-level session statuses into reviewer-facing inbox states.

Step Statuses

Status Codes

Subsessions

Subsessions allow you to collect verification from related parties (UBOs, submerchants, directors) during the main onboarding process. Each subsession is a complete, independent session linked to a parent session.

Create Subsession

Create a new subsession for verification of a related party.

Endpoint

Request Body Parameters

Request Example

Response Format

List Subsessions

Get all subsessions for a parent session with completion status.

Endpoint

Request Example

Response Format

Generate a new access link for a subsession if the original was lost or compromised.

Endpoint

Request Example

Response Format

Delete Subsession

Remove a subsession from a parent session.

Endpoint

Request Example

Response Format

Typical Workflow

  1. Create Session: Create a session linked to a workflow. Optionally pass subject_data (e.g. website for merchants, or full_name / nationality for individual KYC) with data you already know
  2. Share Link: Send the access_link to the end user
  3. User Completes Steps: User uploads documents and fills forms via public API
  4. Subsessions (if applicable): User creates subsessions for UBOs/submerchants via the public API
  5. Process Session: Processing runs automatically when the session completes if the workflow has auto_process enabled; otherwise call POST /process
  6. Review Results: Read processing_results via GET /kyc/sessions/{session_id} (full detail) or act on kyc.session.processed webhooks (automation summary)
  7. Request Corrections (optional): Move the session to awaiting_client_correction with POST /corrections
  8. User Resolves Corrections: The public link shows only the affected steps and open correction guidance
  9. Final Decision: Update status to approved or rejected if manual review is needed