Overview

This page explains how the different Trulioo SDK families fit together across Android, iOS, and Web.

Use it when planning an implementation, selecting the right SDK, or explaining what a customer application should expect from each package. Use the platform guides for installation commands and API examples.

Audience And Scope

This document is for implementation teams integrating one or more Trulioo SDKs into a their application.

It covers:

which SDK family to use for each integration need
how shortcode-backed session bootstrap works across SDKs
what the customer application owns
what each SDK owns
platform-specific behavior that affects implementation planning

It does not replace native API reference documentation.

SDK Family Summary

SDK family	Customer use case	Android package	iOS package	Web package
`Trulioo`	Base session bootstrap, Device Intelligence, KYC Data, and eID flows	`com.trulioo:trulioo`	`Trulioo`	`@trulioo/trulioo`
`Trulioo KYC Documents Capture`	Host-owned camera composition for document or selfie capture	`com.trulioo:kyc-documents-capture`	`TruliooKYCDocumentsCapture`	`@trulioo/kyc-documents-capture`
`Trulioo KYC Documents`	SDK-owned hosted document verification UI	`com.trulioo:kyc-documents`	`TruliooKYCDocuments`	`@trulioo/kyc-documents`

Use the base Trulioo SDK when the application needs session bootstrap, device telemetry, KYC Data verification, eID verification, or a session-scoped authorized client.

Use Trulioo KYC Documents Capture when the host application owns the screen shell and wants to embed only the SDK camera and capture operations.

Use Trulioo KYC Documents when the host application wants the SDK to own the full document verification UI and return a terminal flow result.

Product Boundary

+----------------------+
| Customer application |
+----------------------+
          |
          v
+------------------------------------------+
| Shortcode for the active transaction     |
+------------------------------------------+
          |
          +-------------------------+------------------------------+
          |                         |                              |
          v                         v                              v
+-------------------+   +------------------------------+   +-----------------------+
| Trulioo base SDK  |   | KYC Documents Capture SDK    |   | KYC Documents SDK     |
+-------------------+   +------------------------------+   +-----------------------+
          |                         |                              |
          v                         v                              v
Session bootstrap,       Camera runtime, capture        Hosted document flow,
Device Intelligence,     feedback, image verification,  camera UI, submission,
KYC Data, and eID        image acceptance, submission   terminal callbacks

Host owns shortcode retrieval, app navigation, permission handling around SDK
surfaces, and terminal result handling.

All three SDK families start from a shortcode generated for the active customer transaction. The shortcode selects the Trulioo environment and authorizes the SDK session. The customer application should treat the shortcode as transaction-scoped and should not reuse a stale shortcode after resetting, clearing, or completing a flow.

Integration Choice

What does the customer journey need?
|
+-- Device Intelligence, KYC Data, or eID
|   |
|   +-- Use Trulioo
|
+-- Host-owned document or selfie camera UI
|   |
|   +-- Use Trulioo KYC Documents Capture
|       |
|       +-- Customer app owns the page, Activity, or ViewController shell
|
+-- SDK-owned document verification UI
    |
    +-- Use Trulioo KYC Documents
        |
        +-- SDK owns the document flow UI and returns terminal callbacks/results

This split matters for customer expectations:

The base Trulioo SDK does not render document capture UI.
The Capture SDK does not own the whole verification journey UI.
The Docs SDK does not require the host to compose camera controls directly.

Shared Session Model

Most customer integrations follow this shape:

Customer app
    |
    | provide shortcode
    v
Trulioo SDK
    |
    | resolve shortcode session
    | authorize session
    | fetch product configuration
    v
Trulioo APIs
    |
    | initialized or authorized state
    v
Customer app
    |
    | start selected SDK flow
    v
Trulioo SDK
    |
    | submit product-specific data
    v
Trulioo APIs
    |
    | accepted, complete, or structured error result
    v
Customer app

The exact public entry points differ by SDK family and platform, but the model is consistent:

initialize with a shortcode before product operations
let the SDK fetch the session and product configuration
handle terminal success and structured failure results
reset or clear SDK state before starting a new transaction

Base Trulioo SDK Architecture

The base SDK is a session and verification orchestration layer. It is not a document-camera package.

initialize(shortcode)
        |
        v
Session configuration and access token
        |
        +-- collectDeviceIntelligence(...) or getDeviceInformation(...)
        |       |
        |       +-- Device event, device seed, debug trace
        |
        +-- verifyData(...)
        |       |
        |       +-- Terminal KYC Data result
        |
        +-- prepareEid(...) and verifyEid(...)
        |       |
        |       +-- Terminal eID result
        |
        +-- sessionClient(...)
                |
                +-- Approved post-bootstrap routes

Customer applications can expect:

shortcode initialization resolves the session, access token, product configuration, and debug trace
Device Intelligence collection is explicit except where Web auto-collection is intentionally enabled
the SDK owns device basic-information generation
caller-owned subject reference data is optional and provided only when available
KYC Data and eID flows reuse the initialized base session
standard results are intended for app flow decisions and diagnostics, not as a promise of approval outcome

Platform-specific notes:

Platform	Base SDK specifics
Android	Requires application context setup for the device runtime. eID requires one-time Auth Tab registration in the host `ComponentActivity`. Data and eID state can be observed through platform state APIs.
iOS	Distributed as the `Trulioo` Swift package. Several Data and eID APIs are main-thread UI-adjacent operations. iOS can optionally list licensed eID providers for a country before launch.
Web	Distributed through npm. Browser integrations can use explicit collection or intentionally configured auto-collection during initialization. State changes are exposed through callback registration helpers.

KYC Documents Capture Architecture

The Capture SDK is for host-owned camera composition. The customer application decides where the camera appears, when to ask for permissions, and when to submit or abandon the transaction.

Customer app
    |
    | initializeCapture(shortcode)
    v
Capture SDK
    |
    | authorize Capture session
    | fetch Capture configuration
    v
Trulioo APIs
    |
    | transactionId
    v
Customer app
    |
    | createCaptureCamera(config)
    | render camera in host UI
    v
Capture SDK
    |
    | capture feedback or manual capture result
    v
Customer app
    |
    | verifyImage()
    | acceptImage()
    | submitCapture()
    v
Capture SDK
    |
    | submit accepted images for active transaction
    v
Trulioo APIs
    |
    | submission success or structured error
    v
Customer app
    |
    | clearSession() or reset()
    v
Capture SDK

Customer applications can expect:

initialization must complete before creating a camera or submitting
document capture is the default camera mode; selfie capture is selected through capture configuration
image verification and acceptance are separate operations
submitting the transaction does not always clear local runtime state; follow the platform guide for cleanup
Device Intelligence send and debug wait paths do not apply to the Capture SDK

Platform-specific notes:

Platform	Capture SDK specifics
Android	Published as a fused AAR. The host renders the camera through Jetpack Compose and calls suspend functions returning `Result` values. The normal cleanup method is `clearSession()`.
iOS	Published as `TruliooKYCDocumentsCapture` with a runtime bridge package. The SDK returns a camera `UIViewController` for UIKit embedding or SwiftUI bridging. The runtime wrapper exposes `reset()` for local Capture state cleanup.
Web	Published as `@trulioo/kyc-documents-capture`. The host renders the camera into an existing DOM element. The public package includes API, docs helper, and network helper entrypoints where documented. The normal cleanup method is `clearSession()`.

KYC Documents Architecture

The Docs SDK is for SDK-owned document verification UI. It wraps the document journey, including capture screens and submission, behind a smaller launch-and-result contract.

Customer app
    |
    | initialize or launch with shortcode
    v
KYC Documents SDK
    |
    | initialize Capture-backed flow
    v
Capture runtime
    |
    | resolve transaction and configuration
    v
Trulioo APIs
    |
    | ready or launched state
    v
Customer app
    |
    | present SDK-owned UI
    v
KYC Documents SDK
    |
    | capture, verify, accept, submit
    v
Capture runtime
    |
    | submit active transaction
    v
Trulioo APIs
    |
    | complete, handled error, or exception result
    v
Customer app

Customer applications can expect:

the SDK owns the document verification UI and camera flow
the host owns the outer navigation, launch timing, and terminal result handling
the host does not need to integrate the Capture SDK separately for the hosted Docs flow
completion callbacks/results are terminal from the host application's perspective
customization is limited to documented package capabilities for each platform

Platform-specific notes:

Platform	Docs SDK specifics
Android	Published as a fused AAR. The host registers `Trulioo.LaunchKYCDocuments()` with the Android activity-result API and launches with a shortcode. The SDK owns its Activity and returns `KYCDocumentsResult`.
iOS	Published as `TruliooKYCDocuments`. The host initializes with a shortcode and launches either a SwiftUI view or UIKit controller. Completion and handled-error paths are delivered through `TruliooCallbacks`; `reset()` prepares for a new transaction.
Web	Published as `@trulioo/kyc-documents`. The host initializes the flow, launches into an existing DOM element, and handles callbacks through `ListenerCallback` and `EventBuilder`. Desktop-to-mobile workflow is documented for web-led starts.

Ownership Matrix

Concern	Customer application owns	SDK owns
Shortcode	Retrieving a shortcode for the active transaction and passing it to the SDK	Resolving the shortcode into environment, session, and product configuration
Navigation	App screens before and after the SDK flow	SDK-owned internal screens for hosted Docs, and SDK camera surface for Capture
Permissions	Platform permission prompts and host messaging around SDK launch	Camera/runtime use after the host grants required permission
Device data	Optional subject reference data supplied by the host	Device basic-information generation and runtime submission
Document images	User decision to continue, retry, submit, or abandon	Camera runtime, image feedback, verification, accepted image association, submission
Results	Branching the host journey, support logging, retry decisions	Structured success, handled error, exception, debug, or trace payloads defined by the SDK
Cleanup	Calling reset or clear APIs when the transaction is done or abandoned	Clearing SDK-local session state according to the platform contract

Result And Error Expectations

The SDKs return platform-native result shapes, but the integration expectation is the same:

initialization failures block product operations
send, capture, verification, and launch failures are returned as structured errors where the platform surface supports them
terminal success means the SDK completed the requested SDK flow, not that a customer has been approved
debug trace and diagnostic payloads are support evidence, not business source of truth
final host navigation should branch on documented result types, not internal network details

Platform Differences To Plan For

Area	Android	iOS	Web
Distribution	Maven artifacts, including fused AARs for KYC packages	Swift Package Manager products, including binary package policy for public release	npm packages, with documented CDN options for web packages
UI integration	Activity-result contract for Docs; Compose camera rendering for Capture	SwiftUI or UIKit hosted Docs launch; UIKit camera controller for Capture	DOM container launch or camera rendering
Async model	Kotlin callbacks, suspend functions, `Result`, and observable state flows depending on package	Swift callbacks and async/await depending on package	Promises and callback registration
eID	Requires Auth Tab registration in a `ComponentActivity`	Optional provider listing before launch	No separate provider-listing or Auth Tab registration step
Cleanup naming	Base uses `resetSession()`; Capture uses `clearSession()`	Base and Docs use `reset()`; Capture runtime wrapper uses `reset()`	Base uses `reset()`; Capture uses `clearSession()`

Implementation Checklist

Choose the SDK family based on UI ownership: base session features, host-owned camera, or hosted Docs UI.
Confirm the platform package identity and version from the matching guide.
Generate or obtain a shortcode for the active transaction.
Initialize before any product operation.
Wire the platform-native result, error, and callback model into host navigation.
Handle permissions before rendering or launching camera-dependent flows.
Call the documented reset or clear method before starting a new transaction.
Capture diagnostic evidence listed in the platform guide before escalating support issues.