ربط بيانات المورّد: ربط المعرّفات بالكيانات

vendor_data هو المعرّف الذي تُمرّره في كل جلسة ومعاملة لربطها بكيان المستخدم أو الشركة. وهو أهم حقل لتجميع الكيانات: إذا أعددته بشكل صحيح، تعمل كل الميزات اللاحقة بسلاسة، مثل سجل الملف الشخصي ومراقبة المعاملات وتطبيق قائمة الحظر ومراقبة AML المستمرة.

ما هو المعرّف

vendor_data هو سلسلة نصية تختارها بنفسك. يتعامل معها Didit كمعرّف غير شفاف ولا يفسّر محتواها. من القيم المعتادة:

نظامك	قيم `vendor_data` المناسبة
قاعدة بيانات المستخدمين الداخلية	`user_1234`، و`uuid-v4` للمستخدم
معرّف يراه العميل	`CUST-2026-00042`، أو تجزئة البريد الإلكتروني
منصة SaaS متعددة المستأجرين	`tenant_acme:user_1234`
منصة B2B	`company-hq-global`، و`tax-id-US-123456789`

لا تضع معلومات شخصية قابلة للتحديد (PII) مثل رسائل البريد الإلكتروني وأرقام الهواتف والأرقام الضريبية الخام مباشرةً في vendor_data. استخدم التجزئة (hash) أو أضف بادئة إليها. يظهر vendor_data في حمولات webhook ويُحفظ إلى أجل غير مسمى طالما الكيان موجود.

كيف يربط العناصر ببعضها

عند إرسال جلسة أو معاملة مع قيمة vendor_data:

يبحث Didit عن الكيان في تطبيقك باستخدام vendor_data هذا.
إن وُجد الكيان، يُربط الكائن الجديد به.
إن لم يوجد، ينشئ Didit الكيان (بالحالة status: ACTIVE) ويربط الكائن الجديد به.

ينطبق هذا على:

POST /v3/session/: جلسات التحقق من الهوية (KYC) والتحقق من الشركات (KYB)
POST /v3/transactions/: المعاملات (للمتقدّم بالطلب والطرف المقابل على حد سواء)
الحقلان applicant.vendor_data وcounterparty.vendor_data داخل حمولات المعاملات

التفرد والنطاق

vendor_data فريد لكل تطبيق، وليس فريداً عبر Didit بأكمله:

النطاق	ضمان التفرد
ضمن تطبيق واحد	`vendor_data` فريد لكل نوع كيان (المستخدم والشركة مساحتا أسماء منفصلتان)
عبر التطبيقات في مؤسستك	`vendor_data` غير مشترك؛ القيمة نفسها في تطبيقين تشير إلى كيانين مختلفين
عبر المؤسسات	غير مشترك؛ لكل مؤسسة جداول كيانات خاصة بها

وهذا يعني أنه يمكنك استخدام vendor_data نفسه في التطبيق في البيئة التجريبية وتطبيق الإنتاج دون تعارض، ويمكنك أن تملك مستخدماً user-42 وشركة user-42 دون تعارض، وإن كان ذلك غير مستحسن من أجل الوضوح.

ماذا يحدث إذا أغفلت `vendor_data`

يمكنك إنشاء جلسة دون vendor_data. في هذه الحالة:

لا يُنشأ أي كيان للجلسة.
تصبح الجلسة يتيمة: لن تظهر في أي ملف شخصي لمستخدم أو شركة.
لا يمكنك لاحقاً البحث عن الجلسة بواسطة vendor_data، بل بواسطة session_id فقط.

استخدم هذا النمط فقط للتحققات المجهولة أو لمرة واحدة التي لا تحتاج إلى تجميع الكيانات. أما في كل تكامل يتضمن إعادة التحقق أو المعاملات أو المراقبة المستمرة، فقدّم vendor_data دائماً.

مثال: إنشاء كيان مسبقاً ثم تشغيل الجلسات

# 1. Pre-create the User with initial metadata
curl -X POST https://verification.didit.me/v3/users/create/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vendor_data": "user-42",
    "display_name": "Jane Doe",
    "metadata": { "tier": "premium", "signup_date": "2026-04-01" }
  }'

# 2. Create a User Verification (KYC) session for the same user
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_kyc_standard",
    "vendor_data": "user-42"
  }'

# 3. Later, submit a transaction tied to the same user
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "txn_id": "tx-0001",
    "direction": "OUTBOUND",
    "amount": "500.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "user-42" },
    "counterparty": { "name": "Acme Corp" }
  }'

تُربط الاستدعاءات الثلاثة كلها بكيان المستخدم نفسه. وعندما تستدعي لاحقاً GET /v3/users/user-42/، سترى عدد الجلسات وعدادات الجلسات المقبولة والمرفوضة والمعاملات المرتبطة وأحدث بيانات الملف الشخصي.

ترحيل المعرّفات الخارجية

إذا كنت تعتمد Didit بعد مزود KYC سابق، فمرّر معرّفات المستخدمين الثابتة الحالية كـ vendor_data من اليوم الأول. يسهّل ذلك:

مطابقة بيانات Didit مع قاعدة بياناتك الداخلية.
تحميل المستخدمين التاريخيين بالجملة عبر استيراد CSV من لوحة التحكم قبل تشغيل أي جلسة.
الحفاظ على العلاقات عندما تنتقل لاحقاً إلى Didit لمراقبة المعاملات.

القواعد والاصطلاحات وأفضل الممارسات

القاعدة	السبب
اختر معرّفاً أساسياً واحداً لكل كيان ولا تغيّره أبداً	التغيير ينشئ كياناً جديداً ويترك السجل السابق يتيماً
ابدأ قيم `vendor_data` ببادئة حسب نوع الكيان (`user_...`، `biz_...`)	يمنع التعارض العرضي بين الفضاءات داخل كودك
حافظ على ثبات `vendor_data` مع مراعاة حالة الأحرف	لا يُطبّع Didit حالة الأحرف
اجعل طول `vendor_data` أقل من 128 حرفاً	يناسب فهارس قواعد البيانات بسهولة
لا تكشف المعلومات الشخصية الخام أبداً	يظهر `vendor_data` في webhook وسجلات التدقيق واستجابات API

الخطوات التالية

نظرة عامة على المستخدمين

تعمّق في كيانات المستخدمين وعملياتها.

نظرة عامة على الشركات

تعمّق في كيانات الشركات وعملياتها.

إنشاء جلسة

ابدأ تحققاً لقيمة vendor_data.

إنشاء معاملة

أرسل معاملة مرتبطة بكيان.

نظرة عامة

الأسعار

سير العمل والتحقق

المراجعة والعمليات

الكيانات (المستخدمون والشركات)

الإعدادات والتخصيص

الأمان والامتثال

Didit Academy

الموارد

ربط بيانات المورّد: ربط المعرّفات بالكيانات

ما هو المعرّف

كيف يربط العناصر ببعضها

التفرد والنطاق

ماذا يحدث إذا أغفلت `vendor_data`

مثال: إنشاء كيان مسبقاً ثم تشغيل الجلسات

ترحيل المعرّفات الخارجية

القواعد والاصطلاحات وأفضل الممارسات

الخطوات التالية

نظرة عامة على المستخدمين

نظرة عامة على الشركات

إنشاء جلسة

إنشاء معاملة

​ما هو المعرّف

​كيف يربط العناصر ببعضها

​التفرد والنطاق

​ماذا يحدث إذا أغفلت vendor_data

​مثال: إنشاء كيان مسبقاً ثم تشغيل الجلسات

​ترحيل المعرّفات الخارجية

​القواعد والاصطلاحات وأفضل الممارسات

​الخطوات التالية

نظرة عامة على المستخدمين

نظرة عامة على الشركات

إنشاء جلسة

إنشاء معاملة

ما هو المعرّف

كيف يربط العناصر ببعضها

التفرد والنطاق

ماذا يحدث إذا أغفلت `vendor_data`

مثال: إنشاء كيان مسبقاً ثم تشغيل الجلسات

ترحيل المعرّفات الخارجية

القواعد والاصطلاحات وأفضل الممارسات

الخطوات التالية