Skip to main content
GET
Public Sessions
Public endpoints for end users to access and interact with KYC onboarding sessions. These endpoints require no authentication - access is controlled via secure access tokens.

Overview

Public session endpoints allow end users to:
  • Access Sessions: View session state and workflow definition
  • Upload Documents: Upload required documents, selfies, and file fields directly to S3
  • Extract Data: Extract data from uploaded documents
  • Complete Steps: Mark steps as completed with form data
  • Complete Liveness: Start and verify AWS Rekognition Face Liveness checks
  • Manage Subsessions: Create and track related-party verification sessions
  • Resolve Corrections: Fix reviewer-requested remediation items using the same access token
These endpoints are designed for frontend integration and require no authentication - access is controlled via the access token provided when creating the session.

Endpoints

Authentication

No authentication required. Access is controlled via the access_token path parameter.

Get Session State

Retrieve the current state of a session including progress and uploaded documents.

Endpoint

Request Example

Response Format

steps_data is sanitized for public clients. Internal storage keys such as S3 object paths, extraction profiles, and internal validation metadata are not returned. When a session is in awaiting_client_correction, only the steps with open correction_requests can be edited. Correction requests expose customer-facing guidance such as message, field_ids, and document_types; reviewer identity and internal audit fields are not returned.

Get Workflow Definition

Retrieve the workflow definition to know what steps and fields are required.

Endpoint

Request Example

Response Format

Each step can also include optional display and behavior fields such as description, instructions, tooltip, document_types, conditional_logic, and subsession_config when configured on the workflow.

Upload Files

The current public-session frontend uploads files directly to S3 using presigned URLs. This is the recommended and default flow for documents, selfies, and file fields because the file bytes never pass through the API Gateway/Lambda JSON body. The upload has three steps:
  1. Call /upload/init with file metadata and the workflow step context.
  2. Upload the raw file bytes to the returned upload_url using HTTP PUT.
  3. Call /upload/confirm so the API registers the uploaded S3 object in the session.
Use the legacy base64 upload only if you are maintaining an older integration that cannot upload directly to S3.

Initialize Upload

Endpoint

Request Body Parameters

Request Example

Response Format

Upload To S3

Upload the file bytes to upload_url with an HTTP PUT. Use the same Content-Type passed to /upload/init.

Request Example

Do not send this request to the KYC API host. upload_url is a presigned S3 URL returned by /upload/init.

Confirm Upload

Endpoint

Request Body Parameters

Request Example

Response Format

After confirmation, use doc_id when extracting data or completing form file fields.

Legacy Base64 Upload

The base64 upload endpoint remains available for backward compatibility, but new integrations should use direct S3 uploads via /upload/init and /upload/confirm.

Endpoint

POST /public/sessions/{access_token}/documents is also supported as a legacy alias.

Request Body Parameters

Request Example

Response Format

Extract Document Data

Extract structured data from an uploaded document using OCR/AI.

Endpoint

Request Body Parameters

Request Example

Response Format

Complete Step

Mark a step as completed, optionally with form data.

Endpoint

Path Parameters

Request Body Parameters

Request Example - Document Step

Request Example - Form Step

Response Format

Response Fields

Correction Mode

If a reviewer requests corrections, the session status becomes awaiting_client_correction and one or more steps become needs_correction. The end user keeps using the original public link; no new token is required.

Public State Example

Resolving Corrections

To resolve a correction, update the requested fields or documents and call the regular step completion endpoint:
After a corrected step is completed, its open correction requests are marked resolved. If other steps still have open corrections, the session remains awaiting_client_correction; otherwise the next status depends on the workflow’s validation_config.correction_resolution setting:

Liveness Checks

Liveness steps use AWS Rekognition Face Liveness. The frontend starts a liveness session, passes the returned liveness_session_id to the AWS Amplify Liveness SDK, then confirms the result.

Start Liveness

Endpoint

Request Body Parameters

Request Example

Response Format

Complete Liveness

Endpoint

Request Body Parameters

Request Example

Response Format

Error Responses

404 Not Found - Invalid Access Token

400 Bad Request - Invalid Step

400 Bad Request - Invalid Document Type

400 Bad Request - Missing Required Fields

Status Codes

JavaScript Integration Example

Subsessions

Subsessions allow end users to create verification sessions for related parties (UBOs, submerchants, directors) during the main onboarding process. These are available when the workflow includes a subsession_collection step type.

Create Subsession

Create a new subsession for a related party (e.g., UBO, submerchant).

Endpoint

Request Body Parameters

Request Example

Response Format

List Subsessions

Get all subsessions created from the current session.

Endpoint

Request Example

Response Format

Add ?step_id={step_id} to list only subsessions created for one subsession_collection step. Generate a new access link for a subsession if the original was lost or needs to be refreshed.

Endpoint

Request Example

Response Format

Delete Subsession

Delete an unfinished subsession from the parent session. Completed, processed, or approved subsessions cannot be deleted.

Endpoint

Request Example

Response Format

Subsession Errors

400 Bad Request - Maximum Subsessions Reached

400 Bad Request - Invalid Step Type

404 Not Found - Subsession Not Found

JavaScript Integration Example - Subsessions

Best Practices

  • Security: Access tokens are UUIDs - share them securely with end users
  • Expiration: Check expires_at before allowing user actions
  • Error Handling: Handle expired sessions gracefully with user-friendly messages
  • File Validation: Validate file types and sizes client-side before upload
  • File Uploads: Use direct S3 uploads (/upload/init → S3 PUT/upload/confirm) for new integrations
  • Legacy Uploads: Use base64 /upload only for old clients that cannot upload directly to S3
  • Progress Tracking: Use current_step_index and total_steps to show progress
  • Step Validation: The API validates required fields - handle validation errors in UI
  • Correction Mode: When status is awaiting_client_correction, show each step’s open correction_requests and allow edits only for those steps
  • Subsession Management: For subsession_collection steps, check max_allowed before creating new ones
  • Subsession Completion: If require_completion_before_proceed is enabled on the step, all subsessions must be completed before the parent session can proceed