Integration Architecture

This section provides an end-to-end view of how the Portal interacts with client applications, from initial session creation to final result retrieval. It covers both technical flows and the rationale behind each step.


Client Application Interaction

Before delving into the technical steps, it’s important to understand how end users interface with the system. This subsection clarifies the user journey and tokenization process.

  1. Access Request
    • Users attempting to view age-restricted material are routed to the Facial Age Estimation Portal.
    • Portal URL or embedded SDK triggers the camera-based verification.
  2. Session Tokenization
    • Session tokens uniquely identify each verification flow.
    • Short expiration windows prevent replay exploits and session cloning.

Session Creation

Session management is central to a secure, stateless architecture. This subsection details how to initiate a session with the Portal via REST.

POST/session

Create Session

  POST /session

Request Body

Contains parameters like

  • Name
    redirectUrl
    Type
    string
    Description

    Redirect URL after flow finishes.

  • Name
    ageThreshold
    Type
    number
    Description

    Age threshold.

  • Name
    locale
    Type
    string
    Description

    Language

  • Name
    requirements
    Type
    Array[face, identity_document]
    Description

    Requirements are the flow to be shown in age estimation. If requirements both have face && identity_document , it will do age then compare the face from document id and get age from DOB extraction. When it only have identity_document it will just do document and DOB extraction.

  • Name
    callback
    Type
    object
    Description

    Webhook Callback Handler

    • Name
      url
      Type
      string
      Description

      URL of the webhook callback handler

    • Name
      headers
      Type
      object
      Description

      Headers for the API Webhook call (Add it here if needed)

Headers

  • Name
    x-api-key
    Type
    string
    Description

    Required. Your API key for authenticating with the service.

  • Name
    Authorization
    Type
    Bearer <JWT>
    Description

    Optional. Used if authenticating with Google IAM or a custom identity provider.

Example Payload

{
  "redirectUrl": "https://example.com/finished",
  "ageThreshold": 18,
  "locale": "en-US",
  "enableDesktop": true,
  "requirements": ["face"],
  "callback": {
    "url": "https://your_callback_url",
    // add headers if needed for your callback url
    "headers": {
      "Authorization": "bearer auth123",
    },
  },
  "metadata": {
    "userId": "external_user_123"
  }
}

Example Response

{
  "token": "e35af54d-5527-4529-9d86-8745782f428c",
  "launchUrl": "https://yourdomain.com/age/start?sessionId=e35af54d-5527-4529-9d86-8745782f428c",
  "expiresAt": "2025-04-22T14:16:57.081Z"
}

On-Device Processing and Liveness Check

The core value proposition of the Portal is local processing. This subsection explains how the user’s camera feed is handled, validated, and measured for liveness.

  1. Camera Integration
    • The Portal initiates device camera feed in-app or via browser.
    • WebAssembly or Native SDK processes frames in real time, ensuring no latency from server round trips.
  2. Spoof Detection
    • Texture analysis, blinking detection, and head-movement tracking confirm that the subject is a live human.

    • Immediately flags suspicious inputs (e.g., flat images, digital screens, 3D masks).

  3. Age Estimation
    • The MobileNetV2-based model executes inference locally, producing an estimated numeric age.
    • Outputs are encrypted with AES-256 for secure transmission to the backend.

Encrypted Transmission and Results

Once inference is complete on the device, the minimal results must still be securely communicated. This subsection covers how encryption and minimal payload design protect user data.

  1. Minimal Payload
    • ~2 KB payload containing:
      • Age estimation or threshold decision (above/below age).
      • Session ID for reference.
      • Optional metadata (user ID, timestamps).
  2. Backend Storage
    • The Portal only stores ephemeral session logs and encrypted results.
    • Retention policies can be configured to automatically purge data after a specified timeframe (e.g., 24 hours).

Result Retrieval

The final step is retrieving the user’s age verification outcome, which the host application uses for access control or further processing.

GET/session/{SESSION_TOKEN}/result

Get Result

  GET /session/{SESSION_TOKEN}/result

Success Response

A successful response returns a JSON payload including a unique session identifier and useful data for age prediction process.

Return data will include:

  • Name
    flowStatus
    Type
    COMPLETED, CANCELLED, EXPIRED
    Description

    Status of the flow.

  • Name
    sessionStatus
    Type
    AGE_ABOVE_THRESHOLD
    Description

    If person is above the threshold.

  • Name
    userId
    Type
    string
    Description

    Incorporates any user-defined metadata. Used for cross-referencing

Webhook Response Sample

  • Name
    token
    Type
    string
    Description

    Token

  • Name
    sessionId
    Type
    string
    Description

    Session ID

  • Name
    status
    Type
    string
    Description

    Status of the session.

  • Name
    result
    Type
    object
    Description

    Age estimation result object

    • Name
      age
      Type
      number
      Description

      Estimated Age

    • Name
      confidenceScore
      Type
      number
      Description

      Face plus document face compare score threshold.

    • Name
      documentAge
      Type
      number
      Description

      Age taken from document OCR.

  • Name
    thresholds
    Type
    object
    Description

    Thresholds object from create session

    • Name
      ageThreshold
      Type
      number
      Description

      Age threshold for pass or fail.

    • Name
      compareThreshold
      Type
      number
      Description

      Face plus document face compare score threshold.

  • Name
    metadata
    Type
    object
    Description

    Metadate passed from created session.

Multi-Device and Failover Support

Some users may begin verification on one device and complete it on another. This subsection details how tokens and session data are preserved across devices.

  • QR Code or URL Handoff

    Allows a user to move from desktop to mobile for camera-based verification if desktop lacks a camera.

  • Session Continuity

    Reuses the same sessionToken to sync the flow across devices.

Scalability and Hosting

For enterprises handling large volumes of user traffic, reliability and scalability are paramount. This subsection discusses how the Portal’s microservices can be horizontally scaled.

  • Containerized Microservices

    Deployed with Docker and orchestrated via Kubernetes for auto-scaling.

  • Load Balancing

    Integrates with NGINX, HAProxy, or Cloud Load Balancers for efficient request distribution.

  • Edge Deployments

    Supports on-premise or field-edge usage in shops or kiosks.

Third-Party Integrations

Many organizations rely on additional verification layers. This subsection covers optional integrations, such as government ID checks or CRM systems.

  • Government ID Verification

    Connects seamlessly with external ID scanning services, enabling side-by-side verification for high-assurance verticals (e.g., pharmaceuticals).

  • CRM and KYC Systems

    APIs facilitate data exchange for advanced user management, loyalty programs, or compliance reporting.

Was this page helpful?