Platform Architecture

Overview

The Incode Omni Platform is an AI-driven identity ecosystem that provides onboarding, authentication, and identity verification in a modular, configurable way. It is built on a microservice architecture pattern and deployed in a SaaS cloud environment with high availability and redundant infrastructure to ensure all services are always available.

This page describes the platform's architectural layers, the components within each layer, the internal infrastructure through which requests are processed, and how data flows through a complete integration.

Platform Layers

The Incode Omni Platform is organized into three layers. Each layer represents a distinct level of the stack — from the client-facing tools that developers and end users interact with, through the core platform APIs and processing engine, down to the external data sources the platform connects to for verification.

┌─────────────────────────────────────────────────────────────────────┐
│                         Applications Layer                           │
│                                                                     │
│   Web                    Mobile                  Desktop            │
│   Webflow                Native SDKs             Omni Dashboard     │
│   WebSDK                 Hybrid SDKs                                │
│                                                                     │
├─────────────────────────────────────────────────────────────────────┤
│                     Incode Omni Platform APIs                        │
│                                                                     │
│   Platform API    Face Recognition    Liveness Detection    ID      │
│                                                            Validation│
│                                                                     │
├─────────────────────────────────────────────────────────────────────┤
│                  Third-Party Verification Services                   │
│                                                                     │
│              Add-on Verification Services · Trusted Data Sources    │
└─────────────────────────────────────────────────────────────────────┘

Applications Layer

The Applications Layer contains all the surfaces through which developers build integrations and end users complete verification sessions. It is divided into three client contexts: Web, Mobile, and Desktop.

Web

Two distinct tools serve web-based integrations:

Webflow — A fully hosted, no-code verification UI provided and served by Incode. When a developer sends an end user to a Webflow URL, Incode handles the complete user-facing experience from consent through document capture to result. The Webflow UI is minimally configurable and requires no frontend development. It is the right choice for teams that want a working verification flow with the least integration effort.
WebSDK — A JavaScript component library that developers embed in their own web application. The WebSDK handles the capture experience (camera access, liveness detection, document scanning) while communicating with the Omni Platform on the developer's behalf. It gives developers full control over the surrounding application UI and flow logic. The WebSDK requires a session token from your backend to initialize.

**Webflows vs. Workflows/Flows**

These terms are easy to conflate. A Webflow is the hosted UI that end users see and interact with — it is a runtime component served by Incode's infrastructure. A Workflow or Flow is a configuration object created in the Omni Dashboard that defines which verification modules run and in what order. Workflows and Flows are used across all integration types — no-code Webflows, low-code embeds, SDK integrations, and fully API-based integrations all reference a Workflow or Flow to determine their behavior. A Webflow is one way to deliver a verification experience; a Workflow is the configuration that governs it.

Mobile

Mobile integrations use platform-specific SDKs available in two categories:

Native SDKs — Purpose-built SDKs for Android and iOS. These provide the deepest platform integration, the best camera performance, and support for device-specific features such as NFC scanning and offline face authentication.
Hybrid SDKs — SDKs for cross-platform frameworks including React Native, Flutter, Xamarin, Cordova, and Ionic Capacitor. These allow teams working in a single codebase to integrate Incode verification across both iOS and Android.

Desktop

Omni Dashboard — A web application accessed via desktop browser (Safari, Chrome, and others) for administering and configuring the platform. From the Dashboard, operators create and manage Workflows and Flows, configure verification modules, set scoring thresholds, manage API keys, and review completed sessions. The Dashboard is the configuration authority for the platform.

Incode Omni Platform APIs

The API layer exposes the platform's core capabilities as discrete, callable services. All SDK and direct API calls route through this layer.

Platform API — The primary REST API for session lifecycle management: creating sessions, triggering server-side validation steps, fetching scores, retrieving OCR data, and managing identities. Also referred to as the Omni API.
Face Recognition — The API service responsible for comparing facial biometric templates between a selfie and an ID document photo (face match), and between a selfie and enrolled Incode Identities (face authentication).
Liveness Detection — The API service that determines whether a selfie was captured from a live person or is a spoof attempt (printed photo, screen replay, deepfake). Incode's Deepsight suite extends this capability with additional physical, digital, and behavioral checks.
ID Validation — The API service that performs OCR on captured ID document images, classifies the document type, and runs authenticity checks including anti-tampering analysis.

Third-Party Verification Services

The Omni Platform connects to external authoritative data sources to perform verification checks beyond what can be validated from a document or selfie alone.

Add-on Verification Services — External services for eKYC (identity data checks against credit bureaus, telco records, voter registers, and similar sources), eKYB (business registry checks), global watchlists (sanctions, PEP screening), and government system-of-records validation. These services are invoked by the relevant verification modules when they are included in a session's Workflow or Flow.
Trusted Data Sources — The authoritative government registries and private data sources that back the add-on verification services. Examples include INE and RENAPO in Mexico, SERPRO in Brazil, Companies House in the UK, and the OFAC sanctions list. See System of Records Verification, eKYC, and eKYB for full country and source coverage.

SaaS Infrastructure

The Incode Omni Platform SaaS is the cloud infrastructure that processes all requests from the Applications Layer. Understanding its internal structure clarifies how requests are routed, where data is processed, and what security controls are applied before any request reaches platform services.

All traffic from web, mobile, and desktop clients enters the platform through a layered security and routing stack:

Client (Web / Mobile / Desktop)
        |
        | HTTPS
        v
┌───────────────┐
│      WAF       │  Web Application Firewall — filters malicious traffic
└───────┬───────┘
        |
        v
┌───────────────┐
│  API Gateway  │  Authentication, rate limiting, request routing
└───────┬───────┘
        |
        ├──────────────────────────┐
        v                          v
┌───────────────┐        ┌─────────────────────┐
│    Webapps    │        │ Incode Microservices │ ──→ Data Warehouse
└───────────────┘        └─────────────────────┘
                                   |
                                   v
                         Third-Party Verification
                               Services

WAF (Web Application Firewall)

All inbound traffic — from browsers, mobile apps, and the Omni Dashboard — passes through a Web Application Firewall before reaching any platform service. The WAF filters malicious requests, blocks common attack patterns, and provides a security perimeter for the platform.

API Gateway

Requests that clear the WAF are routed through an API Gateway, which handles authentication validation, rate limiting, and routing to the appropriate internal service. The API Gateway is the entry point for all Omni API calls.

Webapps

The Webapps component serves the hosted Webflow UI to end users. When a developer directs a user to a Webflow URL, it is this component that delivers and runs the no-code verification experience in the user's browser. Webapps operates as a distinct service from the microservices that handle API and SDK-based integrations.

Incode Microservices

The core processing engine of the platform. Microservices handle session lifecycle management, AI model invocation (Face Recognition, Liveness Detection, ID Validation), module execution, scoring, and integration with third-party verification services. The microservice architecture allows individual capabilities to scale independently.

Data Warehouse

Session data, verification results, biometric templates, and OCR outputs are stored in the platform's Data Warehouse. This is what backs the score and result retrieval endpoints, the session review views in the Omni Dashboard, and the analytics capabilities.

Key Technical Properties

Microservice Architecture

The Omni Platform is built on a microservice architecture pattern. Services are independently deployable and scalable. This design supports the platform's high availability and redundancy requirements, and allows individual platform capabilities to be updated without affecting others.

SaaS Deployment

The platform is deployed as a SaaS cloud service. You interact with it via the API and Dashboard — you do not manage any platform infrastructure. A demo environment (demo-api.incodesmile.com) is available for development and testing and does not incur production charges.

**On-premise deployment**

Incode supports on-premise and private cloud deployment for enterprise customers with data residency or compliance requirements that preclude SaaS. Contact your Incode representative for information on this deployment model.

High Availability

The platform implements redundant infrastructure to ensure service availability. All services are designed to remain available without scheduled maintenance windows affecting integrations.

**Content required from Incode**

The following details are not currently documented on the developer portal and should be provided by the Incode team before this page is published:

Uptime SLA and availability commitment (e.g., 99.9%)
Status page URL for real-time service status
Supported cloud regions and data residency options
Whether dedicated tenancy is available and under what conditions

Authentication Model

Understanding the three credential types used across the platform is essential for designing a secure integration.

API Key (`x-api-key`)

Your API key is a long-lived credential that identifies your organization's account. It is required to create onboarding sessions and to call privileged Omni API endpoints.

The API key must be kept server-side at all times. It must never appear in client-side JavaScript, mobile app bundles, or any location where an end user could retrieve it.

Session Token (`X-Incode-Hardware-Id` with session token)

A session token is a short-lived JSON Web Token (JWT) issued by /omni/start when a new onboarding session is created. The session token:

Scopes all SDK and API calls to a single onboarding session
Is passed to the SDK by your server — the SDK uses it to communicate with the platform without needing the API key
Can safely be exposed to the client (browser or mobile app), as it is scoped to one session only

Admin Token (`X-Incode-Hardware-Id` with admin token)

An admin token is a short-lived, high-privilege token obtained by authenticating with the Admin API (/executive/log-in). Admin tokens are required to fetch session results (scores, OCR data, images) and to verify authentication attempts.

Admin tokens must only be obtained and used server-side. They provide access to all session data in your account and must not be exposed to clients.

**Relationship between token types**

The session token travels from your server → to your client → to the Incode SDK. The admin token never leaves your server. The API key is used only by your server to create sessions and obtain admin tokens.

End-to-End Encryption (E2EE)

For integrations with heightened security requirements, the platform supports End-to-End Encryption (E2EE). E2EE adds an additional encryption layer on top of HTTPS by encrypting data transmitted between the SDK and the platform server.

The E2EE mechanism works as follows:

The client and server perform a key exchange handshake at session initialization.
All subsequent communications are encrypted using the exchanged keys.
Only the intended server and client can decrypt the messages — not an intermediary.

E2EE uses the following cryptographic mechanisms (iOS implementation as reference):

RSA-OAEP with SHA-256 for the asymmetric key exchange
AES-GCM for symmetric encryption of session data

E2EE is available for iOS (built into the standard SDK from version 5.37), Android, and Flutter. It requires an additional e2eeUrl parameter at SDK initialization.

For implementation details, see the E2EE integration guides for Android and iOS.

Data Flow

The path a request takes through the platform depends on the integration type. The two primary flows are shown below.

No-Code Webflow

When a developer uses the hosted Webflow integration, the end user's browser communicates directly with Incode's infrastructure. The developer's backend is responsible only for generating the session URL.

Your Backend              Incode Platform (SaaS)          End User Browser
     |                           |                               |
     |-- POST /omni/start ------>|                               |
     |   (API key, config ID)    |-- WAF --> API Gateway         |
     |<-- { token, interviewId } |                               |
     |                           |                               |
     |-- Redirect user to Webflow URL ------------------------>  |
     |                           |                               |
     |                           |<-- User interacts with        |
     |                           |    Webapps (hosted UI)        |
     |                           |    ID capture, selfie, etc.   |
     |                           |                               |
     |                           |-- Microservices process ----> |
     |                           |   ID Validation               |
     |                           |   Face Recognition            |
     |                           |   Liveness Detection          |
     |                           |                               |
     |<-- Webhook or polling ----|                               |
     |    (score + result)       |                               |

SDK Integration

When a developer uses the WebSDK or a mobile SDK, the SDK is embedded in the developer's own application. The capture experience runs inside that application; the developer's backend handles session creation and result retrieval.

Your Frontend / App       Your Backend              Incode Platform (SaaS)
        |                      |                            |
        |-- Page / app loads ->|                            |
        |                      |-- POST /omni/start ------->|
        |                      |   (API key, config ID)     |-- WAF --> API Gateway
        |                      |<-- { token, interviewId } -|
        |<-- session token -----|                            |
        |                      |                            |
        |-- SDK init with token --------------------------->|
        |-- ID capture, selfie --------------------------->|
        |   (via WAF → API Gateway → Microservices)         |
        |<-- capture confirmation --------------------------|
        |                      |                            |
        |-- Notify backend ---->|                            |
        |                      |-- GET /omni/get/score ----->|
        |                      |   (admin token)             |
        |                      |<-- score + results ---------|
        |                      |                            |
        |<-- Show result -------|                            |

Key security properties of both flows:

The API key is used only by your backend to create sessions. It never reaches the frontend, the SDK, or the end user's device.
The session token travels to the client but is scoped to a single session and cannot be used to access other sessions or account data.
The admin token is obtained and used only by your backend to fetch results. It never leaves your server.

The Incode Omni Platform — Introductory overview of platform components
Onboarding Session Lifecycle — How sessions progress from creation to completion
Scoring System Explained — How module scores combine into an overall session result
Security Model Overview — Data handling, encryption, and compliance