Skip to main content
Every User Verification (KYC) session a user has ever run stays permanently linked to their User entity. You can retrieve the full history, inspect individual session results, trigger re-verification, and export compliance reports.

​
Listing all sessions for a user

Filter the Sessions list by vendor_data: 
curl -G https://verification.didit.me/v3/sessions \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=user-42" \
  --data-urlencode "page_size=50"
Response includes every session (regardless of status) — approved, declined, in review, abandoned, or expired.

​
Understanding the feature aggregates

The User entity’s features map reflects the latest status of each feature across all sessions: 
"features": {
  "id_verification": "APPROVED",
  "liveness": "APPROVED",
  "face_match": "APPROVED",
  "aml": "IN_REVIEW"
}
Use this as the fast path to answer “is the user verified right now?”. For the historical record — all sessions, all features, all results — list sessions and inspect each decision.

​
Inspecting a single session

curl https://verification.didit.me/v3/session/{session_id}/decision/ \
  -H "x-api-key: YOUR_API_KEY"
The decision includes:
  • Per-feature results (ID, liveness, face match, AML, POA, NFC, etc.)
  • Extracted document data and images (signed URLs)
  • AML hits with match/risk scores
  • IP analysis and device context
  • Reviewer notes and manual actions
See retrieve session for the full schema.

​
Triggering re-verification

When you need a user to re-verify (e.g. annual re-KYC, document expiry, trigger-based re-check): 
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_reverification",
    "vendor_data": "user-42"
  }'
The new session attaches to the same User entity. On completion, the entity’s features map updates to reflect the new results.

​
Resubmission vs new session

ScenarioUse
User’s session was declined due to a fixable issue (blurry ID, bad lighting)Resubmit — same session, new upload
Full re-verification or periodic re-KYCCreate a brand new session
Remediation triggered by a transaction ruleThe transaction creates a remediation session automatically (AWAITING_USER status)

​
Exporting a compliance report

For audits, SARs, or regulator requests, generate a PDF for any session: 
curl https://verification.didit.me/v3/session/{session_id}/generate-pdf \
  -H "x-api-key: YOUR_API_KEY" \
  -o session-report.pdf
For bulk exports across many sessions, use the console’s CSV/PDF export from Users → [user] → Verifications or the app-wide export at Review & Operations → Export PDF/CSV.

​
Sharing a session with a third party

When you need to share a user’s verification with a partner app (e.g. a reusable KYC scenario), use:
  • POST /v3/session/{session_id}/share/ — generate a shareable token.
  • POST /v3/session/import-shared/ — import a shared session on the receiving side.
See reusable KYC for the full pattern.

​
History-driven workflows

Use session history to drive smarter compliance decisions:
  • Skip steps if the user already has an approved liveness within N days.
  • Require additional checks if the user’s most recent session was declined.
  • Flag when a user’s session count spikes unexpectedly.
  • Monitor ongoing AML rescans via the continuous monitoring feature.

​
Next steps

Data model

How the features map and counters are computed.

Retrieve session

Full session decision schema.

Reusable KYC

Reuse verified data across applications.