Skip to main content
Sessions are the unit of verification on Didit. When you start a verification, a session is created; when the verification finishes, the session carries the full decision payload. The same session API handles both kinds:

​
Kind is determined by the workflow

When you create a session, you pass a workflow_id. The workflow’s type determines whether the session is a User Verification or a Business Verification — callers do not choose separately. KYB workflows create Business Verification sessions; KYC workflows create User Verification sessions.

​
session_kind discriminator

Every session response — from create, retrieve, list, update-status, share, and import — includes a top-level field:
  • "user" — the session is a User Verification (KYC) session. The response contains user-specific feature arrays.
  • "business" — the session is a Business Verification (KYB) session. The response contains business-specific feature arrays.
Use this field to switch on shape on your side.
The enum values are the short identifiers "user" and "business" — we keep them short for API ergonomics. The full names User Verification (KYC) and Business Verification (KYB) are used throughout the documentation for clarity.

​
Feature arrays by kind

The feature arrays present in a decision depend on the kind. Fields absent from one kind simply do not appear in that response (no nulls, no placeholders):

​
Shared top-level fields

Every session (both kinds) carries these fields:

​
Endpoints covered

The following endpoints all accept either kind. No separate /v3/business-session/* paths.

​
How lookups work

User Verification and Business Verification sessions live in different database tables. IDs use UUIDs so collisions are impossible. When you call an endpoint with a session_id, Didit:
  1. Looks up the id in the User Verification table first (covers most traffic).
  2. Falls back to the Business Verification table if not found.
  3. Returns 404 if neither table has a match.
You never need to tell the API which kind you’re looking for.

​
Statuses are identical

Status values are the same for both kinds: NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, ABANDONED, EXPIRED, RESUBMITTED, AWAITING_USER. See verification statuses for the full reference.

​
Webhooks

Webhook events already carry a session_kind field so your webhook handlers can dispatch per kind: See webhooks for signature verification and retry semantics, plus KYB webhooks for the Business Verification event catalog.

​
Next steps

Create session

Start a verification — User Verification or Business Verification.

Retrieve session

Fetch the decision. Works for both kinds.

List sessions

Filter by session_kind.

Update status

Approve, decline, review, resubmit.

Generate PDF

Per-kind PDF reports.

Share + import

Move sessions between apps.