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.

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 capture in a continuous-camera experience that records the session locally and uploads it alongside the capture. See import paths above; no dedicated reference page yet.
• 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. See import paths above; no dedicated reference page yet.
• 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.
• Document upload — file-picker-only upload path for documents that can't be captured live (e.g., third ID). See Module: Document Upload.
• 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. See import paths above; no dedicated reference page yet.

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 · Document Upload · 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 [email protected].