> ## 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) يجريها المستخدم مرتبطةً بكيان المستخدم الخاص به بشكل دائم. يمكنك استرجاع السجل الكامل، وفحص نتائج كل جلسة على حدة، وتشغيل إعادة التحقق، وتصدير تقارير الامتثال.## عرض جميع الجلسات لمستخدمصفِّ قائمة الجلسات حسب `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"
```تتضمن الاستجابة كل الجلسات بغض النظر عن حالتها: مقبولة، أو مرفوضة، أو قيد المراجعة، أو متروكة، أو منتهية الصلاحية.## فهم المجاميع الخاصة بالميزاتتعكس خريطة `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"
```يتضمن القرار ما يلي:- النتائج لكل ميزة (الهوية، وكشف الحيوية، ومطابقة الوجه، وAML، وإثبات العنوان، وNFC، وغيرها)
- بيانات الوثيقة المستخرجة وصورها (روابط موقعة)
- حالات تطابق AML مع درجات التطابق ودرجات المخاطر
- تحليل الجهاز وعنوان IP وسياق الجهاز
- ملاحظات المراجِع والإجراءات اليدويةراجع [استرجاع الجلسة](https://docs.didit.me/ar/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"
  }'
```ترتبط الجلسة الجديدة بكيان المستخدم نفسه. وعند الاكتمال، تُحدَّث خريطة `features` في الكيان لتعكس النتائج الجديدة.## إعادة الإرسال مقابل الجلسة الجديدة| السيناريو | الاستخدام |
| - | - |
| رُفضت جلسة المستخدم لسبب قابل للإصلاح (وثيقة هوية غير واضحة، إضاءة سيئة) | [إعادة الإرسال](https://docs.didit.me/ar/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/ar/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/ar/core-technology/reusable-kyc/overview.md) للاطلاع على النمط الكامل.## سير العمل المبني على السجلاستخدم سجل الجلسات لاتخاذ قرارات امتثال أذكى:- **تخطَّ الخطوات** إذا كان لدى المستخدم كشف الحيوية المقبول خلال N يوماً.
- **اطلب فحوصات إضافية** إذا رُفضت أحدث جلسة للمستخدم.
- **ضع علامة** عندما يرتفع عدد جلسات المستخدم بشكل غير متوقع.
- **راقب** عمليات إعادة فحص AML المستمرة عبر ميزة [المراقبة المستمرة](https://docs.didit.me/ar/core-technology/aml-screening/continuous-monitoring-aml-screening.md).## الخطوات التالية> [card] [نموذج البيانات](https://docs.didit.me/ar/entities/users/data-model.md)
>
> كيفية احتساب خريطة الميزات والعدادات.> [card] [استرجاع الجلسة](https://docs.didit.me/ar/sessions-api/retrieve-session.md)
>
> مخطط قرار الجلسة الكامل.> [card] [KYC القابل لإعادة الاستخدام](https://docs.didit.me/ar/core-technology/reusable-kyc/overview.md)
>
> إعادة استخدام البيانات المتحقق منها عبر التطبيقات.


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