API Reference

Didit offers two complementary approaches to identity verification. Understanding the difference is essential for choosing the right integration for your use case.

Hosted Sessions (Recommended for User-Facing Flows)

Hosted sessions are the recommended approach for most integrations. When you create a session, Didit generates a verification_url that you present to your user. The user completes the entire verification flow in Didit’s optimized interface, and you receive the results via webhook or API.

How It Works

Create Session

Your server calls POST /v3/session/ with a workflow ID. Didit returns a verification_url and session_token.

Present to User

Redirect the user, embed via iframe, or initialize a native SDK using the session token.

User Completes Verification

The user follows the guided flow in Didit’s optimized UI — ID capture, liveness, and any additional steps.

Receive Results

Didit sends a webhook to your server with the verification decision, or you poll via the retrieve API.

Why Sessions Are Recommended

Advantage	Details
Optimized UX	The verification interface is continuously A/B tested globally for the highest completion rates
Camera handling	Smart camera selection, auto-capture, quality checks, and device compatibility built in
Guided flow	Step-by-step instructions, real-time feedback, and error recovery for the user
Multi-feature workflows	Chain multiple features (ID + Liveness + AML + Phone + Email) in a single flow
Security	Anti-spoofing, active liveness detection, and device fingerprinting embedded in the flow
Compliance	Session-level audit trails, consent capture, and data retention policies handled automatically
Localization	49 languages with automatic browser detection
Mobile-native	Native SDKs for iOS, Android, React Native, and Flutter
No maintenance	Didit handles all UI updates, browser/device bugs, and camera edge cases

When to Use Sessions

User onboarding / KYC — New users sign up and need to verify their identity
Age verification — Confirm users meet minimum age requirements
Re-verification — Periodically re-verify existing users
Biometric authentication — Users authenticate with their face for sensitive actions
Multi-step compliance — Flows requiring ID + Liveness + AML + Phone in one go
Any scenario where the end user is present and interacts directly

Session Endpoints

Endpoint	Purpose
Create Session	Generate a verification URL for a user
Retrieve Session	Get the full results and decision for a session
List Sessions	Query and filter all sessions
Delete Session	Remove a session and all associated data
Generate PDF	Export a verification report as PDF
Share Session	Generate a share token for Reusable KYC with a partner
Import Shared	Import a session shared by a partner (Reusable KYC)

Standalone APIs (For Server-to-Server Processing)

Standalone APIs let you call individual verification features directly from your server without any end-user UI. You send the data (images, documents, names) and receive structured results.

How It Works

Send Data

Your server calls a standalone endpoint (e.g., POST /v3/id-verification/) with the required data — images, documents, or JSON fields.

Receive Results

Didit processes the request synchronously and returns structured verification results in the response.

When to Use Standalone APIs

Use Case	Example
Backend processing	You already have document images from your own capture UI and need to verify them
Batch verification	Processing bulk identity documents uploaded by an operations team
Custom UX	You’ve built your own capture flow and want to use Didit only for the analysis
Server-to-server checks	AML screening a list of customers, without any user interaction
Automated pipelines	CI/CD or cron-based compliance re-checks (e.g., daily AML monitoring)
Integration with existing systems	Connecting Didit’s verification to your existing document management system
Single-feature calls	You only need one feature (e.g., just AML screening or just face matching)

Available Standalone APIs

Identity & Documents

API	What It Does
ID Verification	Extract and validate data from ID documents (front + back images)
Proof of Address	Verify address documents (utility bills, bank statements, government docs)
Database Validation	Cross-check user data against government databases

Biometrics & Face

API	What It Does
Passive Liveness	Verify a real person is present (anti-spoofing) from a single image
Face Match	Compare two faces to determine if they are the same person
Face Search	Search for a face across all previously verified sessions (1:N)
Age Estimation	Estimate a person’s age from a facial image

Compliance & Risk

API	What It Does
AML Screening	Screen persons or companies against sanctions, PEP, and watchlists

Side-by-Side Comparison

	Hosted Sessions	Standalone APIs
Integration effort	Low — redirect, iframe, or SDK	Medium — you handle data capture and submission
User interaction	Yes — user completes flow in Didit UI	No — server-to-server only
Camera/capture	Handled by Didit (optimized)	You provide the images/data
Multi-feature flows	Yes — chain features in a workflow	One feature per API call
UX optimization	Continuously A/B tested	You control the UX
Localization	49 languages, auto-detected	N/A (no UI)
Webhooks	Automatic status notifications	N/A (synchronous response)
Response time	Async (user completes at their pace)	Synchronous (seconds)
Best for	User-facing onboarding & verification	Backend processing & automation
Console visibility	Full session lifecycle in dashboard	Appears in Manual Checks section

Can I Use Both?

Yes. Many teams combine both approaches:

Sessions for onboarding — New users go through the full hosted verification flow during sign-up
Standalone AML for ongoing monitoring — A cron job re-screens all approved users nightly against updated watchlists
Standalone Face Search for duplicate detection — When a new session is approved, your server calls Face Search to check for duplicates
Standalone ID Verification for operations — Your compliance team uploads documents manually for edge-case reviews

Example: Combined Architecture

Your Application	Didit API	Type
User sign-up flow	Sessions API (hosted UI)	User-facing
Nightly AML re-screening	Standalone AML API	Server-to-server
Ops team document review	Standalone ID Verification API	Server-to-server
Duplicate face detection	Standalone Face Search API	Server-to-server

Getting Started

Healthcheck

⌘I

Overview

User and Business Verifications

Lists

Workflows

Questionnaires

Users

Businesses

Cases

Case Blueprints

Report Templates

Regulatory Reports

Transactions

Travel Rule

Session Operations

Customization

Webhook

Billing

Management API Overview

Auth API (Programmatic)

Identity & Documents

Database Validation

Biometrics & Face

Compliance & Risk

Email Verification

Phone Verification

Hosted Sessions (Recommended for User-Facing Flows)

How It Works

Why Sessions Are Recommended

When to Use Sessions

Session Endpoints

Standalone APIs (For Server-to-Server Processing)

How It Works

When to Use Standalone APIs

Available Standalone APIs

Side-by-Side Comparison

Can I Use Both?

Example: Combined Architecture

Getting Started

​Hosted Sessions (Recommended for User-Facing Flows)

​How It Works

​Why Sessions Are Recommended

​When to Use Sessions

​Session Endpoints

​Standalone APIs (For Server-to-Server Processing)

​How It Works

​When to Use Standalone APIs

​Available Standalone APIs

​Side-by-Side Comparison

​Can I Use Both?

​Example: Combined Architecture

​Getting Started

Hosted Sessions (Recommended for User-Facing Flows)

How It Works

Why Sessions Are Recommended

When to Use Sessions

Session Endpoints

Standalone APIs (For Server-to-Server Processing)

How It Works

When to Use Standalone APIs

Available Standalone APIs

Side-by-Side Comparison

Can I Use Both?

Example: Combined Architecture

Getting Started