الانتقال إلى المحتوى الرئيسي

المصادقة

تستخدم جميع نقاط نهاية واجهة الإدارة البرمجية مفتاح API الخاص بتطبيقك. لا حاجة إلى معرّفات UUID للمؤسسة أو التطبيق في عناوين URL، إذ يُحدَّد التطبيق من مفتاحك.
ليس لديك مفتاح API بعد؟ سجّل برمجياً باستدعاءين من API.

سير العمل

يحدد سير العمل خطوات التحقق التي يمر بها مستخدموك (مسح الهوية، وكشف الحيوية، ومطابقة الوجه، وفحص AML، وغيرها). كل سير عمل إعداد قابل لإعادة الاستخدام تربطه بالجلسات.
GET
اعرض جميع سير العمل في تطبيقك. يعيد ميزات كل سير عمل وعتباته وما إذا كان هو الافتراضي.
POST
أنشئ سير عمل جديداً. حدّد ميزات التحقق المراد تفعيلها، واضبط العتبات، وأعدّ أنواع المستندات المقبولة، وغير ذلك.
GET
احصل على التفاصيل الكاملة لسير عمل محدد، بما في ذلك إعدادات جميع الميزات والعتبات.
PATCH
حدّث إعدادات سير العمل. يمكنك تعديل أي إعداد ميزة أو أي عتبة أو المستندات المقبولة.
DELETE
احذف سير عمل. لا تتأثر الجلسات التي تستخدم سير العمل هذا بالحذف.
نوصي بشدة باستخدام وحدة تحكم الأعمال لإنشاء سير العمل وإعداده. يوفر منشئ سير العمل المرئي القوالب، والإعداد بالسحب والإفلات لميزات التحقق، وإعدادات المستندات، وضبط العتبات، والمعاينة، كل ذلك دون كتابة أي شيفرة. استخدم واجهة البرمجة للأتمتة أو لإدارة سير العمل برمجياً فقط.

مثال سريع: إنشاء سير عمل

يحدد workflow_type مجموعة الميزات الأساسية. ثم تُفعَّل الميزات الفردية أو تُعطَّل بواسطة الأعلام is_*_enabled.
قيم workflow_type المتاحة: kyc، kyb، adaptive_age_verification، biometric_authentication، address_verification، questionnaire_verification، email_verification، phone_verification. في سير عمل kyc، يُضمَّن التحقق من الهوية تلقائياً، ولا تحتاج إلى علم منفصل له. استخدم أعلام is_*_enabled لإضافة الميزات الاختيارية أو إزالتها، مثل مطابقة الوجه، وكشف الحيوية، وAML، وNFC، والهاتف، والبريد الإلكتروني، وإثبات العنوان، وتحليل الجهاز وعنوان IP، وغيرها. ثم استخدم سير العمل عند إنشاء الجلسات:

الاستبيانات

نماذج مخصصة يمكنك إضافتها إلى سير عمل التحقق لجمع معلومات إضافية من المستخدمين.
GET
اعرض جميع الاستبيانات.
POST
أنشئ استبياناً جديداً بأسئلة مخصصة ومنطق تفرّع وترجمات.
GET
احصل على تفاصيل الاستبيان، بما في ذلك جميع الأسئلة وبنية النموذج.
PATCH
حدّث الاستبيان.
DELETE
احذف الاستبيان.

المستخدمون

أدِر الأفراد الذين تم التحقق منهم (المستخدمين) في تطبيقك. يُعرَّف كل مستخدم بسلسلة vendor_data تزوّدنا بها عند إنشاء الجلسات.
GET
اعرض جميع المستخدمين في تطبيقك، بما في ذلك حالة التحقق وسجل الجلسات.
GET
احصل على تفاصيل المستخدم باستخدام معرّف vendor_data الخاص بك.
PATCH
حدّث البيانات الوصفية للمستخدم.
POST
احذف المستخدمين دفعة واحدة. نص الطلب: {"vendor_data_list": ["user-1", "user-2"]} أو {"delete_all": true}. كما يمسح جميع القوالب البيومترية المحفوظة لهؤلاء المستخدمين.

القوالب البيومترية

قوالب بيومترية للوجه خالية من الصور، يحتفظ بها التطبيق الذي فعّل خيار الاحتفاظ بها بعد حذف الجلسات. راجع القوالب البيومترية.
GET
قائمة مُقسّمة إلى صفحات مع عوامل تصفية (vendor_data، vendor_user_uuid، status، source_type، retained_from، retained_to، ordering).
GET
العدد باستخدام عوامل التصفية نفسها.
GET
قالب واحد: المستخدم المالك، ومرجع المصدر، وتاريخ الانتهاء، والتعليمات، والحالة.
DELETE
امسح قالباً واحداً نهائياً. يُرجع {"uuid": "...", "outcome": "purged" | "already_purged"}.
POST
مسح جماعي. نص الطلب: {"template_uuids": [...]} أو {"delete_all": true} مع عوامل تصفية اختيارية.

عمليات الجلسات

POST
احذف الجلسات دفعة واحدة. يتطلب delete:sessions. نص الطلب: {"session_numbers": ["1", "2", "3"]} أو {"delete_all": true} (قيّد delete_all بعوامل تصفية قائمة الجلسات التي تسبقها filter_، مثل filter_status)، إضافةً إلى الحقول الاختيارية retain_face_embeddings وface_retention_days وface_retention_deadline وdeletion_instruction وinstruction_id. تُرجع ما يصل إلى 20 جلسة مطابقة مع الاستجابة 200 ومع face_retention_outcome لكل جلسة. أما إذا زاد العدد على ذلك، فتُرجع الاستجابة 202 مع مهمة حذف.
GET
تقدّم عملية حذف الجلسات الجماعية التي أعادت 202 وأعداد نتائجها.
GET
اعرض المراجعات وسجل النشاط للجلسة.
POST
أضف ملاحظة مراجعة أو تغيير حالة إلى الجلسة.

الفوترة

GET
الحصول على رصيد الاعتمادات الحالي وإعدادات إعادة التعبئة التلقائية.
POST
إنشاء جلسة دفع في Stripe لشحن الرصيد. تتراوح كل عملية شحن بين $50 و$20,000، وتُضاف بقيمتها الاسمية.

القوائم (قوائم الحظر وقوائم السماح والقوائم المخصصة)

إدارة القوائم المصنّفة حسب النوع لحظر العناصر والسماح بها وإنشاء شروط مخصصة لسير العمل. راجع وثائق واجهة برمجة تطبيقات القوائم الكاملة.
GET
عرض جميع القوائم الخاصة بالتطبيق (قوائم الحظر، وقوائم السماح، والقوائم المخصصة).
POST
إضافة عنصر إلى قائمة. يدعم reference_session_id لاستخراج البيانات تلقائياً من جلسة، وreference_object_uuid لتتبع الارتباط بالمعاملات أو المستخدمين أو الشركات.
DELETE
إزالة عنصر من قائمة.
POST
رفع صورة وجه إلى قائمة حظر الوجوه (بصيغة base64).

إعدادات webhook

GET
الحصول على الإعدادات الحالية لـ webhook، بما في ذلك عنوان URL والإصدار والمفتاح السري للتحقق من توقيعات webhook، وسياسة الاحتفاظ بالبيانات وسياسة الاحتفاظ بالقوالب البيومترية الخاصة بالتطبيق. تتضمن الاستجابة أيضاً allowed_domains، وهو موصوف ضمن PATCH /v3/webhook/ أدناه.
PATCH
تحديث عنوان URL الخاص بـ webhook أو الإصدار، أو تدوير المفتاح السري. اضبط rotate_secret_key: true لإنشاء سر جديد لـ webhook (يُبطل القديم فوراً). كما يضبط سياسة الاحتفاظ الخاصة بالتطبيق: data_retention_months، وface_retention_policy (القيمة الافتراضية delete_with_session، أو retain_until_user_deleted) مع face_retention_days إلزامي بقيمة نهائية محددة (من 1 إلى 3650) عند تفعيل الاحتفاظ. راجع الاحتفاظ بالقوالب البيومترية. كما يسجّل allowed_return_hosts: ما يصل إلى 20 اسم مضيف مجرّداً (على سبيل المثال app.example.com، دون مخطط أو منفذ أو مسار أو حرف بدل)، يجوز لعملية تحقق عبر واجهة برمجة تطبيقات محفظة الهوية الرقمية إعادة الشخص إليها عبر HTTPS. تحلّ القائمة الجديدة محل القائمة المسجلة، ويبقى نطاق العلامة البيضاء الخاص بتطبيقك مسموحاً به دائماً.كما يضبط allowed_domains: ما يصل إلى 50 أصل ويب (على سبيل المثال https://app.example.com) يجوز تضمين تدفق التحقق المستضاف فيها، ويجوز لها إعادة المستخدم إليها باستخدام callback الخاص بالجلسة. يتكون كل إدخال من مخطط ومضيف ومنفذ اختياري، دون مسار أو استعلام أو حرف بدل. استخدم https؛ ولا يُقبل http إلا لـ localhost و127.0.0.1 و::1. تخزّن Didit كل أصل بحروف صغيرة ودون المنفذ الافتراضي، وتعيد القائمة في allowed_domains. يؤدي الإدخال غير الصالح إلى خطأ 400 عند ضبط allowed_domains. تحلّ القائمة الجديدة محل القائمة المسجلة، وتزيل القائمة الفارغة القيد. طالما القائمة غير فارغة، ترفض POST /v3/session/ قيمة callback للويب الواقعة خارجها بالخطأ 400، ولا تعيد صفحة التحقق المستضافة توجيه المستخدم إلى callback مخزّن أو افتراضي لسير العمل خارجها. لا تتأثر مخططات الروابط المخصصة (روابط التطبيقات العميقة) ولا استدعاءات API من الخادم إلى الخادم.إذا أرسلت endpoints، فسيتم حذف كل وجهة webhook لا تتضمنها القائمة بشكل دائم، مع سر التوقيع الخاص بها وسجل التسليم كاملاً، تماماً كما في DELETE /v3/webhook/destinations/{destination_uuid}/. لا يمكن التراجع عن ذلك. لإدارة الوجهات واحدة تلو الأخرى، استخدم endpoints الخاصة بوجهات webhook بدلاً من ذلك.

ملخص endpoint الكامل لواجهة API

آخر تعديل في ٧ نوفمبر ٢٠٢٦