SDK reference, Incode Web SDK 2 Reference

Third-Party Dependencies

Warning

This guide is specific to Web SDK 2.x. For Web SDK 1.x, you can find documentation here.

Do not attempt to upgrade or implement without support. Contact your Incode representative to check if you are a candidate for this upgrade.

The Incode Web SDK loads some resources from domains outside your configured apiURL. This page lists those external network requests — what they're for, and how to remove, replace, or self-host them. Use it to configure Content-Security-Policy allowlists or to run a fully self-hosted deployment.

Summary

Resource Domain Package Default Override
WASM + ML models cdn.incodesmile.com @incodetech/core Loaded for capture or explicit warm-up setup({ wasm: { wasmPath, modelsBasePath, ... } })
Public IP lookup api.ipify.org @incodetech/core Enabled setup({ ipLookup: false })
Translations Application asset host in 2.3.0; api.i18nexus.com in SDK development builds @incodetech/web Bundled locale chunks in published 2.3.0 packages setup({ i18n: { loadPath | skipRemoteLoad, translations } })
Feature management Statsig-managed endpoints internal layer Enabled setup({ featureManagement: false })
Digital-ID logos content.trinsic.id @incodetech/web Only with digital-ID cards None — allowlist the domain or accept a blank logo

Fonts and animations are bundled in @incodetech/web. The Video Selfie voice-consent MP3 encoder (lamejs) ships in @incodetech/core as a separate file. It loads only in flows with voice consent from the same host as your other SDK files. None of these request third-party domains, so the table doesn't list them. In 2.3.0 and earlier releases, voice consent loads the encoder from cdnjs.cloudflare.com.

@incodetech/web's setup() forwards ipLookup, fingerprint, featureManagement, and environment to @incodetech/core, and applies i18n internally.

WASM / ML models

What: WASM binaries, glue JavaScript, and ML models for face and ID capture.

Default domain: cdn.incodesmile.com

Override individual paths, or point at your own host entirely:

import { setup } from '@incodetech/core';

await setup({
  apiURL: 'https://api.incode.com',
  wasm: {
    wasmPath: '/wasm/webLib.wasm',
    glueCodePath: '/wasm/webLib.js',
    modelsBasePath: '/wasm/models',
  },
});

See WASM Configuration for the full self-hosting walkthrough, including required headers and SIMD variants.

Public IP lookup (ipify)

What: Fetches the client's public IP address, used to enrich the device-fingerprint submission.

Default domain: api.ipify.org

import { setup } from '@incodetech/core';

await setup({
  apiURL: 'https://api.incode.com',
  ipLookup: false,
});

Set ipLookup: false to skip the third-party call entirely — useful for deployments where outbound calls to third-party services are restricted. See the ipLookup and fingerprint options in API Reference for the full behavior, including what each flag does to fingerprint submission.

Translations

Published 2.3.0 packages load the built-in translations as locale chunks from the host serving your application's SDK assets. The default no longer needs an i18nexus CSP allowance. Earlier packages and SDK development builds can fetch translations from api.i18nexus.com.

A custom i18n.loadPath uses your translation endpoint instead;. Allow its host for translation requests. Inline translations override the loaded strings. skipRemoteLoad: true disables remote loading but still permits bundled locales in 2.3.0. See Internationalization.

Feature management (Statsig)

What: Decides feature-gate and experiment values for the session, so Incode can roll changes out progressively and run capture experiments. Served by Statsig via the @statsig/js-client package, loaded as a separate chunk during setup().

Default: enabled. Include its network requirements when configuring your application CSP.

Domains: the client uses Statsig's own default endpoints. The SDK does not override or proxy them, and exposes no option to redirect them, so take the current hostnames from Statsig's CSP guidance when you build an allowlist.

Opt out completely:

import { setup } from '@incodetech/core';

await setup({
  apiURL: 'https://api.incode.com',
  featureManagement: false,
});

With featureManagement: false the chunk is never fetched and no feature-management request leaves the browser. Reads from @incodetech/core/feature-management keep working and resolve to their defaults, so opting out does not break code that checks a gate.

What identity is sent. No customer API key is involved. The integration generates its own anonymous identifier (a "StableID") and enriches it over the session with hashed session, flow, and workflow identifiers. Two privacy defaults are already conservative, and two flags tighten them further:

  • IP address and country are redacted by default before anything is sent. Use redactedUserInfo to redact more fields, or to send those two deliberately.
  • disableStableId: true stops the identifier being generated at all — the strongest control. Evaluations then resolve to control values until session identity arrives.
  • disablePersistence: true keeps identity in memory only, so it is never linkable across page loads.

See FeatureManagementSetupOptions for the full option table, and Feature management for the read API.

Digital-ID provider logos (Trinsic)

What: Brand logos for the providers on the ID Capture document chooser. When a flow enables digital-ID bank redirects, the chooser shows one card per provider (for example iDIN or Finnish Trust Network) and each card loads its logo as an <img>. A flow with no digital-ID methods never requests this domain.

Default domain: content.trinsic.id

There is no setup() option for this. To allow it, add content.trinsic.id to your img-src Content-Security-Policy directive.

If the domain is blocked, the provider cards still render and stay selectable — the logo is decorative and carries an empty alt, so nothing is announced to screen readers and no functionality is lost. The card's icon area is simply blank; it does not fall back to the SDK's built-in digital-ID glyph.

When the Incode API supplies an absolute logoUrl for a method, that URL takes precedence and the request goes to whichever host the API named instead of this default.

API-driven externals

These URLs come from Incode API responses, not hardcoded SDK constants. Most of them are presigned links to Incode storage, for example on *.s3.amazonaws.com. Take the exact hosts from the responses in your environment when you build an allowlist.

  • Theme and logo assets. To skip them, set disableDashboardTheme: true in the <incode-flow> or <incode-workflow> config. For standalone modules, call setup({ theme: false }). The SDK then uses its default theme.
  • Face Match photos. The Face Match animation shows the cropped ID face and the selfie as images from presigned links. Allow their host in img-src, or turn off the animation (disableFaceMatchAnimation) for the Face Match step in your flow configuration.
  • Presigned upload URLs (electronic signature document uploads)
  • Signed PDF document URLs
  • Recording upload URLs (when video recording is enabled). For 2.3.0, allow HTTPS uploads to the destinations supplied for the session. A recording-specific WebSocket allowance is no longer required.

Configure the remaining items in Dashboard or with your Incode account team.

The API supplies the desktop-to-mobile redirect URL by default. Set FlowConfig.redirectToMobileUrl to replace this URL for one <incode-flow> instance.

Content-Security-Policy

In addition to the hosts on this page, the SDK needs these CSP allowances:

Directive Value Why
script-src 'unsafe-eval' The WASM runtime generates its JavaScript bindings with new Function. Without this value, WASM initialization fails and capture can't start. It also allows WebAssembly compilation.
script-src blob: The SDK checks the WASM glue code against its release digest and then runs those exact bytes from a blob: URL. Without this value, WASM initialization fails and capture can't start.
worker-src blob: The SDK runs some work in workers that it creates from blob: URLs, for example the voice-consent MP3 encoder and the PDF viewer (Digital ID upload, electronic signature).

Some modules link to Incode policy pages (for example, terms-of-service or privacy-policy links in consent screens). These are user-initiated navigation, not requests the SDK makes on its own.

See Also