Skip to main content
The Didit JavaScript SDK provides a programmatic way to integrate verification into your web application with full control over the user experience.

Features

  • Simple API - Singleton pattern with easy-to-use methods
  • Flexible Integration - Use UniLink URL directly or create sessions via backend
  • Responsive - Works on desktop and mobile browsers
  • Customizable - Configuration options for styling and behavior
  • Multiple Formats - ESM, CommonJS, and UMD builds
  • TypeScript Support - Full type definitions included
  • Modal & Inline Modes - Choose between modal overlay or inline embedding
  • Event Callbacks - Real-time events for verification progress (started, step completed, finished)
  • State Management - Observe SDK state for custom UI

Installation

NPM/Yarn

CDN (UMD)

The latest published npm release is 0.6.0. 0.6.0 moves the SDK to @didit-protocol/signals 0.2.0, the package it sends events and device signals with. 0.5.0 added DiditSdk.shared.submitEvent() (see Submit events), and 0.5.1 lets the hosted flow ask a digital ID wallet for the user’s ID inside the SDK and keeps a failed launch in the error state with its errorMessage. 0.4.0 added the camera options the native SDKs already offer, including defaultLivenessCamera, which opens the face capture on the rear camera (see Camera options).

Check the installed version

Your package manager remains authoritative for the installed release:
You can also inspect the runtime export:
From 0.3.1 this export is generated from the package version in every JavaScript format (ESM, CommonJS, UMD, minified UMD) and in the TypeScript declaration, so it always matches the installed release. 0.3.0 and earlier report 0.2.1 from this export regardless of the installed version. On those releases, use npm list or your lockfile instead.

Vanilla JavaScript

ES Modules / TypeScript

Script Tag (UMD)


Framework Examples

SDK Web Examples

React, Angular, Svelte, Next.js, Nuxt, Vue, and more — with examples and documentation for each framework.

Integration Methods

There are two ways to integrate the SDK: Use your workflow’s UniLink URL directly from the Didit Console. No backend required.
Get your UniLink URL from the Didit Console → Your Workflow → Copy Link. The session_id generated will be sent to you by an event. Check event reference here Your backend creates a session via the Didit API and returns the hosted verification URL. This gives you control over vendor_data, per-session callback, metadata, and lets you create sessions before the user reaches the frontend. Read more in the Create Session API reference. Backend (Node.js / Express)
Frontend
The session-create response field is named url (see the Create Session OpenAPI schema). Pass it directly to startVerification({ url }).

Configuration

See the full TypeScript type definitions below for the complete DiditSdkConfiguration interface.

Camera options

The camera options require @didit-protocol/sdk-web 0.4.0 or later.
The web SDK exposes the same four camera options as the native SDKs. By default the document capture opens the rear camera and the face (liveness) capture opens the front (selfie) camera, and both steps offer an in-capture camera switcher on devices with more than one camera. Set defaultLivenessCamera: 'back' to open the face capture on the rear camera, for example on a kiosk or when an operator holds the device and points it at the person being verified.
  • Accepted lens values are 'front' and 'back'. Any other value is ignored, as is a switcher flag that is not a boolean.
  • A device without the requested camera keeps the one it has: a laptop asked for 'back' still uses its webcam. The switcher is hidden on single-camera devices whatever the flags say.
  • The liveness options apply to the passive liveness check. Active liveness is not affected.
  • The SDK forwards the options to the verification page as query parameters of the verification URL: document_camera, liveness_camera, document_camera_switch and liveness_camera_switch. If you open the verification URL directly instead of through the SDK, set them yourself: append ?liveness_camera=back to a URL without a query string, &liveness_camera=back to one that already has parameters, or set them with the URL API so either case is handled:

Submit events

DiditSdk.shared.submitEvent() queues end-user events (sign-up, login, failed login, logout, password reset, MFA, device change) for Didit’s event monitoring. Your backend mints a monitoring token for the person, and the SDK sends the events in batches with the device fingerprint. Never ship an API key to the browser.
See SDK event submission for the token, the event fields and delivery behavior.

One device across your site and the verification

A browser keeps the storage of the verification’s frame apart from your page’s, so the two would never share a device ID. From 0.6.0, when your page already keeps one for Didit (it has sent events, transactions or sign-ins), startVerification passes it to the verification. The verification then reports it next to its own device signals, so a session and your site’s events can be told apart as the same device, and it goes by that ID where the browser gives the frame no storage that lasts. A page that keeps no device ID gets none created: opening a verification adds no cookie and no storage entry to your site.
The sizing behavior below requires 0.3.1 or later. 0.3.0 and earlier can clip the verification flow on short desktop and landscape viewports.
Modal mode uses a maximum width of 500px and a maximum height of 700px. On shorter desktop and landscape viewports, the iframe tracks 90% of the visible viewport. The verification flow scrolls inside the iframe, so every step remains reachable while the page behind the modal stays locked. The SDK uses dvh on browsers that support dynamic viewport units and falls back to vh on older supported browsers. At widths of 540px and below, the modal fills the visible viewport. The close button and exit confirmation stay inside the modal.

Redesigned verification flow

Everything in this section applies from version 0.5.0. On an earlier version, the modal keeps the size described above.
From version 0.5.0, the modal sizes itself around the redesigned verification flow once the page reports its layout with a didit:layout message:
  • Starting size, from version 0.5.0: until the page reports its layout, and for pages that never do, the modal keeps the existing maximum size of 500px by 700px. It still fits short windows and stays full screen at 540px and below.
  • Close button, from version 0.5.0: a 44px circle over the page’s top bar. It follows the page’s light or dark theme and moves to the left in right-to-left languages.
  • Embedded mode, from version 0.5.0: it keeps filling its host element, as before (see Embedded mode).
  • Verification URL, from version 0.5.0: the SDK adds sdk_presentation (modal or embedded) and, in a modal, sdk_close_button (true or false, following showCloseButton), so the page knows how it is shown.
  • Events, from version 0.5.0: the SDK handles didit:layout itself and does not pass it to onEvent.
There is nothing to configure, and every existing option keeps working.

Embedded mode

Embedded mode does not use the modal’s 500px by 700px cap. The SDK fills the host element’s content box, so give that element an explicit or otherwise resolved height:
If the host has no resolved height, the embedded iframe also has no usable height. Resize the host when your layout changes; the SDK continues to fill it automatically.

Verification Results

The SDK returns three types of results:

Completed

Verification flow finished (approved, pending, or declined).
The TypeScript type declares 'Approved' | 'Pending' | 'Declined', but the value is passed through from the hosted flow’s session status — you can also receive other statuses such as In Review. Pending is the SDK’s fallback when the flow reported no status. Treat status as a hint and rely on the webhook for the canonical decision.

Cancelled

User closed the verification modal. session is included when a sessionId was already known (it can be undefined if the user cancelled before the iframe reported one).

Failed

An error occurred during verification.

State Management

You can observe the SDK state for custom UI:

API Reference

DiditSdk.shared

The singleton SDK instance.

Methods

Properties

Callbacks


Granular Events

Track verification progress with the onEvent callback:

Event Reference

Lost connection

If the user’s connection drops, the verification page covers the flow with a “No internet connection” screen instead of leaving a step loading. It keeps checking in the background and closes the screen by itself as soon as Didit can be reached again, and the user carries on from the step they were on. Inside the SDK’s modal or an iframe the screen also offers Exit Verification: the page then sends didit:error with error: "network_error", followed by didit:cancelled, and the SDK closes the modal and calls onComplete with type: "cancelled". From version 0.5.0, the page’s didit:layout message sizes the modal and does not reach onEvent. If you embed the page with your own iframe instead, see Size the iframe from didit:layout.

Step Values

The step field can be one of:
  • document_selection - Document type selection
  • document_front - Front side of document
  • document_back - Back side of document
  • face - Face/liveness verification
  • email - Email verification
  • phone - Phone verification
  • poa - Proof of address
  • questionnaire - Questionnaire step

Channel Values

The channel field in code_sent can be:
  • email - Code sent via email
  • sms - Code sent via SMS
  • whatsapp - Code sent via WhatsApp

Code Size

The codeSize field in code_sent indicates the OTP code length (e.g., 4 or 6 digits).

TypeScript Types

Last modified on November 13, 2026