Individual Modules Catalog

The Incode Web SDK is composed of small, single-purpose modules. Each module ships independently and exposes (depending on the module) a web component, a headless Manager, or both.

This page is the complete catalog. For deep-dives, see the per-module reference pages linked below where they exist; otherwise consult Headless Mode for headless API patterns and Web Components for the consumer-element API surface.

New here? Most modules follow one of five implementation patterns (form-based, camera-capture, backend-process, document-signing, composite). Module Patterns documents each pattern's lifecycle once so per-module pages can stay focused on what's actually unique. Read that first if you're orienting on the SDK.

How to read this catalog

For a tour of how to combine these into a full integration, start with Getting Started.

Flow-backed standalone modules

Standalone modules can read their configuration from the active Flow. This lets a host render modules such as ID, Selfie, or Phone without copying their configuration into application code.

Use setup() from @incodetech/web for standalone modules. The flow and theme options below only take effect through that entry point, and standalone modules load the dashboard theme from it. Set up through @incodetech/core instead and these modules render unbranded, with no error — see Which setup() do I call?.

Flow configuration and the session theme are independent:

• flow controls where standalone module configuration comes from and whether it is prefetched.
• theme controls whether the session theme is fetched and applied.

ID followed by Selfie

The examples below preload one Flow, disable the session theme, and render the registered ID and Selfie web components directly in JSX. Both modules intentionally omit config.

React 19

React 19 passes function-valued custom element properties directly:

import { setup } from '@incodetech/web';
import '@incodetech/web/id';
import '@incodetech/web/selfie';
import { useEffect, useState } from 'react';

export function Verification() {
  const [step, setStep] = useState('loading');

  useEffect(() => {
    void setup({
      apiURL,
      token,
      flow: {
        preload: true,
      },
      theme: false,
    }).then(() => setStep('id'));
  }, []);

  if (step === 'id') {
    return (
      <incode-id
        onFinish={() => setStep('selfie')}
        onError={(error) => console.error('ID failed', error)}
      />
    );
  }

  if (step === 'selfie') {
    return (
      <incode-selfie
        onFinish={() => setStep('finished')}
        onError={(error) => console.error('Selfie failed', error)}
      />
    );
  }

  return null;
}

React 18

React 18 renders custom elements directly, but function-valued properties must be assigned through refs:

import { setup } from '@incodetech/web';
import '@incodetech/web/id';
import '@incodetech/web/selfie';
import { useEffect, useRef, useState } from 'react';

function ID({ onFinish, onError }) {
  const ref = useRef(null);

  useEffect(() => {
    const element = ref.current;
    if (!element) {
      return;
    }
    element.onFinish = onFinish;
    element.onError = onError;

    return () => {
      element.onFinish = undefined;
      element.onError = undefined;
    };
  }, [onError, onFinish]);

  return <incode-id ref={ref} />;
}

function Selfie({ onFinish, onError }) {
  const ref = useRef(null);

  useEffect(() => {
    const element = ref.current;
    if (!element) {
      return;
    }
    element.onFinish = onFinish;
    element.onError = onError;

    return () => {
      element.onFinish = undefined;
      element.onError = undefined;
    };
  }, [onError, onFinish]);

  return <incode-selfie ref={ref} />;
}

export function Verification() {
  const [step, setStep] = useState('loading');

  useEffect(() => {
    void setup({
      apiURL,
      token,
      flow: {
        preload: true,
      },
      theme: false,
    }).then(() => setStep('id'));
  }, []);

  if (step === 'id') {
    return (
      <ID
        onFinish={() => setStep('selfie')}
        onError={(error) => console.error('ID failed', error)}
      />
    );
  }

  if (step === 'selfie') {
    return (
      <Selfie
        onFinish={() => setStep('finished')}
        onError={(error) => console.error('Selfie failed', error)}
      />
    );
  }

  return null;
}

setup fetches Flow once and waits for it. ID reads the first ID module configuration from the cached Flow. Selfie later reads the first SELFIE configuration from the same cache, so mounting Selfie does not issue another Flow request. theme: false ensures that Flow configuration is used without changing the host application's colors, logo, subtitle, or footer.

The session token must belong to a Flow containing both ID and SELFIE. If either module is missing, that module reports an error instead of falling back to library defaults.

Setup options

Flow and theme requests are independent. For example, flow: { preload: true }, theme: false preloads module configuration without fetching or applying the session theme.

Override part of the Flow configuration

Enable merging when the Flow should provide defaults but the host needs to override selected fields. In React 19:

await setup({
  apiURL,
  token,
  flow: {
    preload: true,
    mergeConfig: true,
  },
  theme: false,
});

<incode-selfie config={{ showTutorial: false }} />;

Objects merge recursively, arrays are replaced, and defined local values including null win. Without mergeConfig: true, any supplied config is used verbatim and Flow is not consulted for that module.

Disable Flow configuration

Use a complete local config or a supported external manager when Flow-backed configuration is disabled. In React 19:

await setup({
  apiURL,
  token,
  flow: false,
  theme: false,
});

<incode-id config={localIdConfig} />;

Rendering <incode-id /> in this mode reports Flow-backed module configuration is disabled; provide config or manager.

Standalone Flow resolution requires an active Flow session. A Workflow-only token cannot supply standalone Flow configuration. Modules rendered inside Flow or Workflow orchestration already receive authoritative configuration from their orchestrator and do not use this standalone fallback.

Direct Core setup supports the same flow option and semantics. The theme option belongs to Web setup because Core does not render or apply UI themes.

Identity capture

• Selfie: face capture with ML-powered liveness detection. Supports single-frame, multi-modal, and video-liveness modes. Validates against masks, glasses, headwear, closed eyes, lighting. See Module: Selfie.

• Video selfie: selfie, ID, and optional voice-consent capture in one continuous camera session, recorded on-device and uploaded alongside the captures. See Module: Video Selfie.

• Personhood: a passive liveness check that runs without an onboarding session and returns a verdict of its own: human (whether a live person was present), confidence, evidenceId (the server-side record to reference later), and signals. Because it is session-less, it does not participate in a Flow or Workflow — drive createPersonhoodManager directly. The drop-in UI ships separately as incode-personhood-widget, which consumes this same core module. No dedicated reference page yet; PersonhoodConfig takes:

  Option	Type	Required	Description
  siteKey	string	✅	Identifies your Personhood integration. Issued by Incode.
  clientId	string	❌	Client credentials for the live check. See the credential note below before using them.
  clientSecret	string	❌	Paired with clientId. See the credential note below.
  authBaseUrl	string	❌	Points the authorization step at a dedicated host. Omit unless Incode gave you one — single-origin deployments do not need it.
  threshold	number	❌	Minimum confidence a verdict must reach to pass. Agree a value with Incode rather than tuning it blind.
  showTutorial	boolean	❌	Set false to skip the tutorial screen. Default false shows it.
  autoComplete	boolean	❌	Complete with the best available frame after a short deadline, rather than waiting for ideal framing. Raises completion rates at the cost of verdict confidence.
  onSignal	(event) => void	❌	Called as signals are observed, for progress reporting. Receives { type, payload } where type is 'pose', 'detection', 'verdict', or 'error'.
  ds	boolean	❌	Enables the session's additional anti-injection checks.

  Credentials: clientId and clientSecret are optional, and needed only for the live check. The SDK sends them from the browser, so anyone who can read your page or its network traffic can read the secret. Use them only where that exposure is acceptable. Where it isn't, have your own backend obtain the authorization token and keep the secret server-side.

• ID document: government ID, passport, and driver's-license capture with quality checks (blur, glare, perspective). See Module: ID.

• ID OCR: extracts structured data from a captured ID image (name, DOB, address, ID number, etc.). With cpfOnly: true, or when <incode-flow> receives useCPF: true, it shows and validates only the CPF document number field. See Module: ID OCR.

• Document capture: generic document capture (utility bills, lease agreements, tax docs) with multi-page support and file-picker fallback. See Module: Document Capture.

• Face match: compares a captured selfie against the face on a previously captured ID and returns a match score. See Module: Face Match.

Contact verification

• Phone: phone-number capture with optional SMS OTP verification. See Module: Phone.
• Email: email capture with optional OTP verification. See Module: Email.

Compliance & consent

• Consent: capture user consent with optional checkboxes for terms, privacy, marketing. See Module: Consent.
• Mandatory consent: strict consent flow that gates downstream modules until the user accepts. State and methods documented inline in Module: ID → Mandatory Consent State Properties.
• Geolocation: captures the user's coordinates with a permission prompt; useful for jurisdictional rules. See Module: Geolocation.
• Antifraud: runs antifraud signal collection in the background. See Module: Antifraud.
• Watchlist / Custom watchlist / Watchlist for business: sanctions, PEP, and custom-list screening. See Module: Watchlist, Module: Custom Watchlist, Module: Watchlist for Business.
• Government validation: validates submitted ID data against government registries (with optional OTP). See Module: Government Validation.
• CURP validation: validates Mexican CURP identity numbers (enter / confirm / generate). See Module: CURP Validation.
• Fiscal QR: scans a Mexican SAT fiscal QR code, resolves its URL, and submits the fiscal data for verification. No dedicated reference page yet. It takes no configuration — FiscalQrConfig is empty, because the backend sends no settings for this step. Its states are idle, scanning, capturing, success, processing, verified, error, and finished; drive it with load(), continue(), and skip(). A scan can be rejected with a 2xx response, so treat a failure result as a failure rather than checking only the HTTP status.

Authentication & identity reuse

• Authentication: re-authenticate a returning user via fresh selfie capture matched against their stored biometric. Same camera-capture flow as Selfie. See Module: Authentication.
• Identity reuse: recognizes a returning user via face match against their existing on-file biometric record and lets them choose to reuse the existing identity. See Module: Identity Reuse.

Signing

• Signature: handwritten signature capture on a touch surface or mouse-driven canvas. See Module: Signature.
• Electronic signature, AE signature, QE signature: eIDAS-aligned signing flows. AE and QE are thin wrappers around Electronic Signature (same state machine, different consent keys). All three covered in Module: Electronic Signature.

Composite & orchestration

• Flow (orchestrator): drives a dashboard-configured sequence of modules end-to-end. The default for most integrations. createOrchestratedFlowManager is the modern API; createFlowManager is legacy and stays for back-compat. See IncodeFlow Component and Headless Mode → Orchestrated Flow Manager.
• Workflow: server-driven multi-step workflows where step ordering and configuration come from the backend per session, including custom-module callbacks. See Module: Workflow.
• eKYC: Know Your Customer form module: collects identity verification data (name, DOB, address, etc.) with dashboard-driven field schema. See Module: eKYC.
• eKYB: Know Your Business form module: business name, address, tax ID, plus UBOs. Country-aware schema. See Module: eKYB.
• Cross-document data match: cross-references data across multiple captured documents to flag inconsistencies. See Module: Cross-Document Data Match.
• Certificate issuance: issues a digital certificate at the end of a verification flow: the user sets a protecting password, the backend issues the certificate, and the SDK offers it for download. See Module: Certificate Issuance.
• Field comparison: collects the user's first and last name and submits them for backend verification against the data already on file for the session. See Module: Field Comparison.
• Custom fields: collect arbitrary structured data (text, number, date, boolean) from a dashboard-defined schema. See Module: Custom Fields.
• Dynamic forms: server-driven multi-screen form module. Screen schema, fields, and validation rules come from the backend per session — useful for jurisdiction-specific questionnaires that change without an SDK release. Typically driven by <incode-flow> (no public UI subpath); use the headless manager directly when you're stepping through forms outside the orchestrator. See Module: Dynamic Forms.
• Trust graph: backend-only risk-graph analysis. The orchestrator renders an empty shell while the server runs the analysis; the module advances to finished automatically once the backend reports done. No UI element, no config (TrustGraphConfig = Record<string, never>).

Utility

• Home: the SDK's built-in home screen presented before a flow starts. Wired automatically by <incode-flow> when enableHome: true. See Module: Home.
• Redirect to mobile: generates a QR code and a one-time URL that hands the user off from a desktop browser to their phone, where camera-bearing modules continue. See Module: Redirect to Mobile.

Helpers used by every integration

These aren't modules per se — they're SDK-wide helpers you'll hit on day one.

Per-module reference pages

Every module has a dedicated reference page covering its tag, properties, configuration, state machine, and API methods. Pages cross-reference Module Patterns for the shared lifecycle (load / subscribe / reset / stop and pattern-specific transitions) so they stay focused on what's module-specific.

Identity capture: Selfie · ID Capture · ID OCR · Document Capture · Face Match

Contact verification: Phone · Email

Compliance & consent: Consent · Geolocation · Antifraud · Watchlist · Custom Watchlist · Watchlist for Business · Government Validation · CURP Validation

Authentication & identity reuse: Authentication · Identity Reuse

Signing: Signature · Electronic Signature (covers AE / QE variants)

Composite & orchestration: IncodeFlow Component · Workflow · eKYC · eKYB · Cross-Document Data Match · Certificate Issuance · Custom Fields

Utility: Home · Redirect to Mobile

For niche fields not covered on a page, the TypeScript declarations shipped with each @incodetech/core/<name> subpath are authoritative — your editor's go-to-definition (or hover docs) takes you straight to them. If you need help, contact support@incode.com.