> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# उपयोगकर्ता KYC इतिहास: सत्र और पुनः सत्यापन

> Didit के साथ उपयोगकर्ता से जुड़े सभी सत्यापन सत्र प्राप्त करें, फ़ीचर-स्तर के परिणाम देखें, पुनः सत्यापन ट्रिगर करें और अनुपालन रिपोर्ट एक्सपोर्ट करें।



KYC इतिहास प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\````# Goal — read a user's full KYC history and trigger re-verification

Every KYC session a user has ever run stays permanently linked to the User entity via `vendor_data`. The session list endpoint is the entry point; the decision endpoint is the detail view.

\## List every session for a user

\```bash
curl -G https://verification.didit.me/v3/sessions/ \
-H "x-api-key: $DIDIT_API_KEY" \
\--data-urlencode "vendor_data=user-42" \
\--data-urlencode "page_size=50"
\```

Response covers every status (approved, declined, in review, abandoned, expired). Paginate with the `next` cursor / `page` param until empty.

\## Inspect a single session decision

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

V3 returns plural arrays — always iterate them:

\- `id_verifications[]`
\- `liveness_checks[]`
\- `face_matches[]`
\- `aml_screenings[]`
\- `nfc_verifications[]`
\- `proof_of_address_checks[]`

Never assume V2 singular fields.

\## Trigger re-verification

Annual re-KYC, document expiry, trigger-based re-checks — same pattern: create a new session against the same `vendor_data`. The new session attaches to the existing User entity and updates the `features` map on completion.

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id": "wf_reverification", "vendor_data": "user-42"}'
\```

\## Fast path — fully verified right now?

The User entity carries a `features` map summarising the **latest** state of each feature across all sessions:

\```bash
curl https://verification.didit.me/v3/users/user-42/ \
-H "x-api-key: $DIDIT_API_KEY"
\# data.features = { id_verification: "APPROVED", liveness: "APPROVED", aml: "IN_REVIEW", ... }
\```

Use `features` for "is the user verified right now?" without iterating every session.

\## Generate a PDF for any session

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/generate-pdf/ \
-H "x-api-key: $DIDIT_API_KEY" \
-o session-report.pdf
\```

\## Generate the full user history PDF

One file with a cover page plus the report of every reportable session (`Approved`, `Declined`, `In Review`, `Kyc Expired`) of the user, capped at the 20 most recent. Same document as Console → User detail → Actions → Download PDF. Synchronous render: use a 120s read timeout.

\```bash
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
-H "x-api-key: $DIDIT_API_KEY" \
-o user-history.pdf
\```

404 = no such user in this application; 403 = user has no reportable session yet.

\## Resubmit vs new session

\| Scenario | Use |
\|---|---|
\| Declined for fixable reason (blurry ID, bad lighting) | Resubmit the existing session (re-deliver `url`); the workflow advances through resubmission |
\| Annual / trigger-based re-KYC | Create a brand new session via `POST /v3/session/` |
\| Transaction-rule triggered remediation | The transaction creates a remediation session automatically (`Awaiting User` status) |

\## Share a session with a partner (Reusable KYC)

\```bash
\# Issue a shareable token
curl -X POST https://verification.didit.me/v3/session/$SESSION_ID/share/ \
-H "x-api-key: $DIDIT_API_KEY"

\# Receiver imports the shared session
curl -X POST https://verification.didit.me/v3/session/import-shared/ \
-H "x-api-key: $RECEIVER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"share_token": "..."}'
\```

\## Failure modes

\- `404` on the user — wrong `vendor_data` casing or no sessions yet.
\- Empty `results[]` — no sessions for this `vendor_data` in this application.
\- Stale signed image URLs — re-fetch the decision.
\- Sharing rejected — receiving application must have Reusable KYC enabled.

\## Sources of truth

\- /sessions-api/retrieve-session — V3 decision schema
\- /management-api/users/generate-pdf — full user history PDF
\- /reference/data-models — per-feature plural-array contract
\- /core-technology/reusable-kyc/overview — share / import pattern
\- /entities/users/data-model — features map computation
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

यहाँ पेस्ट करें

किसी उपयोगकर्ता द्वारा चलाया गया हर उपयोगकर्ता सत्यापन (KYC) सत्र स्थायी रूप से उसकी User entity से जुड़ा रहता है। आप पूरा इतिहास प्राप्त कर सकते हैं, व्यक्तिगत सत्र परिणामों का निरीक्षण कर सकते हैं, पुनः सत्यापन ट्रिगर कर सकते हैं, और अनुपालन रिपोर्ट एक्सपोर्ट कर सकते हैं।## किसी उपयोगकर्ता के सभी सत्रों की सूची`vendor_data` के आधार पर सत्रों की सूची को फ़िल्टर करें:```bash theme={null}
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"
```रिस्पॉन्स में हर सत्र शामिल होता है (स्थिति चाहे जो भी हो): स्वीकृत, अस्वीकृत, समीक्षाधीन, छोड़ा गया, या समय-सीमा समाप्त।## फ़ीचर एग्रीगेट्स को समझनाUser entity का `features` मैप सभी सत्रों में हर सुविधा की **नवीनतम** स्थिति को दर्शाता है:```json theme={null}
"features": {
  "id_verification": "APPROVED",
  "liveness": "APPROVED",
  "face_match": "APPROVED",
  "aml": "IN_REVIEW"
}
```यह जानने का तेज़ तरीका है कि क्या उपयोगकर्ता अभी सत्यापित है। ऐतिहासिक रिकॉर्ड के लिए (सभी सत्र, सभी सुविधाएँ, सभी परिणाम) सत्रों की सूची बनाएँ और हर निर्णय का निरीक्षण करें।## एक सत्र का निरीक्षण```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/decision/ \
  -H "x-api-key: YOUR_API_KEY"
```निर्णय में शामिल है:- प्रति-सुविधा परिणाम (ID, लाइवनेस, चेहरा मिलान, AML, पते का प्रमाण (POA), NFC, आदि)
- निकाला गया दस्तावेज़ डेटा और छवियाँ (हस्ताक्षरित URLs)
- मिलान/जोखिम स्कोर के साथ AML हिट्स
- डिवाइस और IP विश्लेषण और डिवाइस संदर्भ
- समीक्षक नोट्स और मैन्युअल कार्रवाइयाँपूरा स्कीमा देखने के लिए [सत्र प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md) देखें।## पुनः सत्यापन ट्रिगर करनाजब आपको किसी उपयोगकर्ता से पुनः सत्यापन करवाना हो (जैसे वार्षिक पुनः KYC, दस्तावेज़ की समाप्ति, या ट्रिगर-आधारित पुनः जाँच):```bash theme={null}
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"
  }'
```नया सत्र उसी User entity से जुड़ता है। पूरा होने पर, entity का `features` मैप नए परिणामों को दर्शाने के लिए अपडेट हो जाता है।## पुनः जमा बनाम नया सत्र| परिदृश्य | उपयोग करें |
| - | - |
| उपयोगकर्ता का सत्र किसी ठीक होने योग्य समस्या (धुंधला ID, खराब रोशनी) के कारण अस्वीकृत हुआ | [पुनः जमा करें](https://docs.didit.me/hi/console/manual-review.md) — वही सत्र, नया अपलोड |
| पूर्ण पुनः सत्यापन या आवधिक पुनः KYC | एक बिल्कुल नया सत्र बनाएँ |
| लेन-देन नियम द्वारा ट्रिगर किया गया सुधार | लेन-देन स्वचालित रूप से एक सुधार सत्र बनाता है (`AWAITING_USER` स्थिति) |## अनुपालन रिपोर्ट एक्सपोर्ट करनाऑडिट, SARs या नियामक अनुरोधों के लिए, किसी भी सत्र की PDF जनरेट करें:```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o session-report.pdf
```किसी उपयोगकर्ता के पूरे इतिहास को एक फ़ाइल में शामिल करने के लिए, [उपयोगकर्ता इतिहास PDF](https://docs.didit.me/hi/management-api/users/generate-pdf.md) डाउनलोड करें: एक कवर पेज (प्रोफ़ाइल सारांश, सुविधा स्थिति, सत्र सूची) जिसके बाद हर रिपोर्ट योग्य सत्र की पूरी रिपोर्ट होती है, सबसे पुराने से शुरू करके, और केवल सबसे हाल के 20 सत्रों तक सीमित।```bash theme={null}
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o user-history.pdf
```यह वही दस्तावेज़ है जो कंसोल *Users → \[user] → Actions → Download PDF* से बनाता है। कई उपयोगकर्ताओं के लिए बल्क CSV एक्सपोर्ट के लिए, *Review & Operations → Export PDF/CSV* पर ऐप-व्यापी एक्सपोर्ट का उपयोग करें।## किसी तीसरे पक्ष के साथ सत्र साझा करनाजब आपको किसी उपयोगकर्ता का सत्यापन किसी पार्टनर एप्लिकेशन के साथ साझा करना हो (जैसे पुनः प्रयोज्य KYC परिदृश्य), तो इनका उपयोग करें:- `POST /v3/session/{session_id}/share/` — साझा करने योग्य token जनरेट करने के लिए।
- `POST /v3/session/import-shared/` — प्राप्तकर्ता पक्ष पर साझा किया गया सत्र इंपोर्ट करने के लिए।पूरा पैटर्न देखने के लिए [पुनः प्रयोज्य KYC](https://docs.didit.me/hi/core-technology/reusable-kyc/overview.md) देखें।## इतिहास-आधारित वर्कफ़्लोबेहतर अनुपालन निर्णय लेने के लिए सत्र इतिहास का उपयोग करें:- **चरण छोड़ें** यदि उपयोगकर्ता के पास N दिनों के भीतर स्वीकृत लाइवनेस है।
- **अतिरिक्त जाँच आवश्यक करें** यदि उपयोगकर्ता का सबसे हाल का सत्र अस्वीकृत हुआ था।
- **फ़्लैग करें** जब किसी उपयोगकर्ता के सत्रों की संख्या अचानक बढ़ जाए।
- **निगरानी करें** चल रहे AML पुनः स्कैन की [सतत निगरानी](https://docs.didit.me/hi/core-technology/aml-screening/continuous-monitoring-aml-screening.md) सुविधा के माध्यम से।## अगले चरण> [card] [डेटा मॉडल](https://docs.didit.me/hi/entities/users/data-model.md)
>
> सुविधा मैप और काउंटर कैसे गणना किए जाते हैं।> [card] [सत्र प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md)
>
> सत्र निर्णय का पूरा स्कीमा।> [card] [पुनः प्रयोज्य KYC](https://docs.didit.me/hi/core-technology/reusable-kyc/overview.md)
>
> सत्यापित डेटा को एप्लिकेशन में पुनः उपयोग करें।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.