Bouncer

Sessions

Understanding verification sessions in Bouncer

Sessions

A session in Bouncer represents a single age verification attempt. Understanding the session lifecycle is crucial for integrating Bouncer effectively.

Session Lifecycle

Status Flow

CREATED → PENDING → VERIFICATION_STARTED → COMPLETED

                    VERIFICATION_KYC → COMPLETED

Session Statuses

StatusDescription
CREATEDSession created via API, user not yet redirected
PENDINGUser has visited the verification page
VERIFICATION_STARTEDUser has begun the liveness check
VERIFICATION_KYCUser is performing ID document scanning
COMPLETEDVerification finished (check success field for result)
CANCELLEDSession was cancelled

Session Parameters

When creating a session, you can configure:

ParameterRequiredDescription
age_targetYesTarget age to verify (8, 13, 16, 18, 21, 25, or 30)
redirect_urlYesWhere to send the user after verification
webhook_urlNoURL to receive real-time status updates
force_kycNoAlways require ID verification
metadataNoCustom data to attach (e.g., order ID)
expiration_timeNoSession timeout in seconds (60-3600)

See the Create Session API for complete request/response details.

Session Expiration

Sessions have a configurable expiration time:

  • Default: 300 seconds (5 minutes)
  • Minimum: 60 seconds
  • Maximum: 3600 seconds (1 hour)

Expired sessions cannot be completed. If a user's session expires, you'll need to create a new one.

Verification Flow

Age Estimation Flow

  1. User visits verification page
  2. Liveness check is performed
  3. System estimates age from facial features
  4. If estimated age ≥ target age → SUCCESS
  5. If estimated age < target age → Redirect to KYC

KYC Flow

When KYC is required (age estimation failed or force_kyc: true):

  1. User captures ID document (front and back)
  2. System verifies document and extracts birth date
  3. Age calculated from document birth date
  4. If age ≥ target age AND all checks pass → SUCCESS
  5. Otherwise → FAILURE

Failure Reasons

When a session fails, common reasons include:

ReasonDescription
underageUser's verified age is below the target
face_mismatchFace doesn't match ID photo
spoofed_documentFake or digital ID detected
liveness_failedLiveness check failed

Polling vs Webhooks

You can check session results two ways:

Polling

Query the Get Session Status API periodically until status is completed.

Configure a webhook_url when creating the session to receive real-time notifications. See Webhooks for details.

Best Practices

  1. Always set a redirect_url: Users need somewhere to go after verification
  2. Use webhooks for production: More reliable than polling
  3. Handle expiration gracefully: Provide users a way to restart verification
  4. Store session IDs: Map sessions to your internal user/order IDs
  5. Validate success server-side: Never trust client-side success indicators

On this page