الخطوة 1: احصل على بيانات اعتمادك
لديك طريقتان للحصول علىapi_key:
الخيار أ: التسجيل البرمجي (دون متصفح)
الأنسب لبيئات CI/CD ووكلاء الذكاء الاصطناعي. يُرجع الاستدعاءان إلى الواجهة البرمجية، وهماPOST /programmatic/register/ ثم POST /programmatic/verify-email/، مفتاح api_key ضمن الاستجابة مباشرة.
→ انظر التسجيل البرمجي للاطلاع على التدفق الكامل، وقواعد كلمة المرور، ومدة صلاحية JWT، وسياسة القفل.
الخيار ب: من Didit Console
- انتقل إلى Didit Console.
- أنشئ مؤسستك أو اختر مؤسسة موجودة.
- انتقل إلى الإعدادات ← API وwebhook.
- انسخ:
- مفتاح API: يُستخدم كرأس
x-api-keyفي كل استدعاء تحقق. - مفتاح webhook السري: يُستخدم للتحقق من توقيعات HMAC الخاصة بـ webhook.
- مفتاح API: يُستخدم كرأس
متغيرات البيئة
الخطوة 2: أنشئ سير عمل
قبل إنشاء الجلسات، تحتاج إلى سير عمل للتحقق. يحدد سير العمل خطوات التحقق التي يمر بها المستخدمون.الإنشاء من وحدة التحكم
- انتقل إلى Didit Console ← سير العمل
- انقر على إنشاء سير العمل
- اختر قالباً أساسياً:
- أضف الميزات الاختيارية:
- انسخ مُعرّف سير العمل
راجع توثيق سير العمل للاطلاع على خيارات الإعداد التفصيلية.
الخطوة 3: إنشاء جلسة تحقق
استدعِ الـ API لإنشاء جلسة لمستخدمك.الطلب
معاملات الطلب
مثال كامل بجميع الخيارات
expected_details.expected_document_types يقصر خطوة التحقق من الهوية على أنواع مستندات محددة، إذ لا تعرض شاشة اختيار المستند سوى الأنواع المطلوبة. القيم المسموح بها: P (جواز السفر)، وID (بطاقة الهوية الوطنية)، وDL (رخصة القيادة)، وRP (تصريح الإقامة)، وHIC (بطاقة التأمين الصحي)، وTC (البطاقة الضريبية)، وSSC (بطاقة الضمان الاجتماعي). القيم غير حساسة لحالة الأحرف، وتُحذف التكرارات، وتُرجع القيم غير المعروفة 400. راجع مرجع Create Session للاطلاع على المخطط الكامل.الاستجابة
201 Created:
حقول الاستجابة الرئيسية
Idempotency. عند توفير
vendor_data ووجود جلسة غير مكتملة (Not Started أو In Progress أو Resubmitted أو Awaiting User) بالقيمة نفسها لـ vendor_data في أحدث إصدار منشور لسير العمل، تُعاد تلك الجلسة الموجودة (ما زال الرمز 201) بدلاً من إنشاء نسخة مكررة، مع تحديث callback وmetadata إلى القيم الجديدة، ويعكس status حالة الجلسة الموجودة.يُرجع غياب
x-api-key الرمز 403 مع الاستجابة {"detail": "You do not have permission to perform this action."}، وهي الاستجابة نفسها التي تُرجع عند استخدام مفتاح صالح لكن بلا إذن. يُرجع المفتاح الخاطئ أو الملغى أو المنتهي الرمز 401. يُرجع الرصيد غير الكافي الرمز 400. راجع مرجع Create Session API للوثائق الكاملة.الخطوة 4: عرض التحقق على المستخدم
اختر طريقة عرض تدفق التحقق على مستخدمك:الخيار أ: حزمة SDK الأصلية (موصى بها للجوال)
استخدمsession_token مع حزم SDK الأصلية للكاميرا وNFC والتكامل البيومتري.
→ iOS SDK · Android SDK · React Native · Flutter
الخيار ب: InContext iframe (موصى به للويب)
ضمّن التحقق في صفحتك باستخدامurl الذي تُرجعه الخطوة 3.
الخيار ج: إعادة التوجيه
وجّه المستخدم إلى رابط التحقق.الخيار د: WebView في تطبيق الجوال
للتطبيقات المحمولة التي لا تملك SDK أصلية.الخطوة 5: استلام النتائج
عبر webhook (موصى به)
تُخطِر webhook خادمك فورياً عند تغيّر حالة التحقق. الإعداد:- أنشئ وجهة webhook في لوحة التحكم (API & Webhooks) أو عبر
POST /v3/webhook/destinations/معwebhook_version: "v3"ومصفوفةsubscribed_events(مثلاً["status.updated"]) - احفظ
secret_shared_keyالمُعاد عند الإنشاء، فهو سر HMAC لجميع متغيرات التوقيع - نفّذ endpoint webhook على خادمك
decision، تُسلَّم كل نتيجة خاصة بميزة في صورة مصفوفة بصيغة الجمع (id_verifications[]، وnfc_verifications[]، وliveness_checks[]، وface_matches[]، و…)، بمدخل واحد لكل عقدة في سير العمل. هذا هو عقد V3 ولا يُمسّ: لا تكتب شيفرتك أبداً على مفاتيح مفردة مثل nfc أو id_verification أو liveness.
decision موجوداً إلا عندما تكون status هي Approved أو Declined أو In Review أو Abandoned (أما حدث Resubmitted فيحمل resubmit_info بدلاً منه). تعيد Didit استخدام event_id نفسه عبر المحاولات المتكررة ووجهات التوزيع المتعددة، فاجعل مفتاح idempotency الخاص بك قائماً عليه. راجع نماذج البيانات لمعرفة كل مصفوفة بصيغة الجمع وكل حقل.
تحقق من التوقيع (X-Signature-V2، موصى به):
X-Signature-V2 هو HMAC-SHA256 على إعادة ترميز معيارية لجسم JSON: تُختصر الأعداد العشرية ذات القيم الصحيحة إلى أعداد صحيحة، وتُرتَّب المفاتيح بشكل متكرر، وتُستخدم فواصل مدمجة، ويُحافَظ على ترميز Unicode.
X-Signature القائم على البايتات الخام، والغلاف المهمَل X-Signature-Simple الذي يشمل الغلاف فقط، وكيفية الاختيار بينها. تعيد Didit محاولة التسليم الفاشل (5xx أو 404 أو انتهاء المهلة) حتى مرتين (بعد نحو دقيقة، ثم بعد نحو 4 دقائق)، وتنتهي المهلة بعد 5 ثوانٍ، لذا أعِد 2xx بسرعة.
عبر API (اختياري)
استرجع حمولة القرار نفسها في أي وقت:decision داخل حمولة الـ webhook، ويمكن استدعاء نقطة النهاية في أي مرحلة من دورة حياة الجلسة. استخدم webhook للتحديثات الفورية، واقتصر على استدعاءات API لاستكمال البيانات والتدقيق وإعادة البناء. endpoint /decision/ محدودة بـ 600 طلب GET في الدقيقة لكل مفتاح API (راجع حد المعدل). دلالات الأخطاء: إذا كان session_id غير معروف تُعاد استجابة 404 مع {"detail": "Not found."}، وتظهر إخفاقات المصادقة كـ 403، ولا يُعيد هذا endpoint أبداً 401. روابط الوسائط في الاستجابة روابط موقّعة مسبقاً وقصيرة الأمد، فاستردّها فوراً ولا تحتفظ بها.
→ مرجع API لاسترجاع الجلسة
أمثلة شيفرة كاملة
Node.js / Express
Python / FastAPI
حالات الجلسة
هذه هي القيم الـ 10 الممكنة لـstatus، وهي سلاسل نصية دقيقة وحساسة لحالة الأحرف (لاحظ أن Kyc Expired تستخدم حرف K كبيراً واحداً):
راجع حالات التحقق للاطلاع على دورة الحياة الكاملة والانتقالات ومخطط Mermaid.
الخطوات التالية
- اختر طريقة التكامل:
- تطبيقات الجوال ← SDKs الأصلية
- تطبيقات الويب ← SDKs الويب
- إعداد webhook: Webhooks
- تخطيط السعة: حد المعدل
- معالجة كل حالة: حالات التحقق
- تخصيص سير العمل: سير العمل
- تحقق من إمكانية الوصول إلى API: Healthcheck
هل تحتاج إلى مساعدة؟
- الدعم: support@didit.me
- التسجيل البرمجي: التسجيل البرمجي