Public Sessions
KYC Workflows & Sessions
Public Sessions
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.
Each step can also include optional display and behavior fields such as
Do not send this request to the KYC API host.
After confirmation, use
After a corrected step is completed, its open correction requests are marked
Add
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
Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /public/sessions/{access_token} | Get session state |
GET | /public/sessions/{access_token}/workflow | Get workflow definition |
POST | /public/sessions/{access_token}/upload/init | Initialize direct S3 upload |
PUT | {upload_url} | Upload file bytes directly to S3 |
POST | /public/sessions/{access_token}/upload/confirm | Confirm direct S3 upload |
POST | /public/sessions/{access_token}/upload | Legacy base64 upload |
POST | /public/sessions/{access_token}/documents | Legacy base64 upload alias |
POST | /public/sessions/{access_token}/extract | Extract document data |
POST | /public/sessions/{access_token}/step/{step_id}/complete | Complete a step |
POST | /public/sessions/{access_token}/liveness/start | Start a liveness check |
POST | /public/sessions/{access_token}/liveness/complete | Complete a liveness check |
POST | /public/sessions/{access_token}/subsessions | Create a subsession |
GET | /public/sessions/{access_token}/subsessions | List subsessions, optionally filtered by step_id |
POST | /public/sessions/{access_token}/subsessions/{subsession_id}/regenerate | Regenerate subsession link |
DELETE | /public/sessions/{access_token}/subsessions/{subsession_id} | Delete an unfinished subsession |
Authentication
No authentication required. Access is controlled via theaccess_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
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:- Call
/upload/initwith file metadata and the workflow step context. - Upload the raw file bytes to the returned
upload_urlusing HTTPPUT. - Call
/upload/confirmso the API registers the uploaded S3 object in the session.
Initialize Upload
Endpoint
Request Body Parameters
Request Example
Response Format
Upload To S3
Upload the file bytes toupload_url with an HTTP PUT. Use the same Content-Type passed to /upload/init.
Request Example
upload_url is a presigned S3 URL returned by /upload/init.
Confirm Upload
Endpoint
Request Body Parameters
Request Example
Response Format
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
| Field | Description |
|---|---|
step_id | The completed step ID |
status | Step status after completion |
next_step_id | ID of the next step, or null if this was the last step |
session_completed | True if all steps are now completed |
Correction Mode
If a reviewer requests corrections, the session status becomesawaiting_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: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:
| Mode | Result |
|---|---|
manual_review | Session returns to manual_review for a reviewer decision |
auto_process | Session moves to completed and processing is triggered |
completed | Session moves to completed without automatic processing |
Liveness Checks
Liveness steps use AWS Rekognition Face Liveness. The frontend starts a liveness session, passes the returnedliveness_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
| Code | Description |
|---|---|
| 200 | Success |
| 201 | Created - presigned upload initialized, liveness session started, or subsession created |
| 400 | Bad Request - Invalid parameters or validation failed |
| 403 | Forbidden - operation not allowed |
| 404 | Not Found - Invalid access token or step not found |
| 500 | Internal Server Error |
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 asubsession_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
?step_id={step_id} to list only subsessions created for one subsession_collection step.
Regenerate Subsession Link
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_atbefore 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→ S3PUT→/upload/confirm) for new integrations - Legacy Uploads: Use base64
/uploadonly for old clients that cannot upload directly to S3 - Progress Tracking: Use
current_step_indexandtotal_stepsto 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 opencorrection_requestsand allow edits only for those steps - Subsession Management: For subsession_collection steps, check
max_allowedbefore creating new ones - Subsession Completion: If
require_completion_before_proceedis enabled on the step, all subsessions must be completed before the parent session can proceed