الانتقال إلى المحتوى الرئيسي
يرشدك هذا الدليل خلال التدفق الكامل لدمج التحقق من الهوية عبر Didit باستخدام REST API: الحصول على بيانات الاعتماد، وإنشاء جلسة، وعرضها على المستخدم، واستلام النتائج.

الخطوة 1: احصل على بيانات اعتمادك

لديك طريقتان للحصول على api_key:

الخيار أ: التسجيل البرمجي (دون متصفح)

الأنسب لبيئات CI/CD ووكلاء الذكاء الاصطناعي. يُرجع الاستدعاءان إلى الواجهة البرمجية، وهما POST /programmatic/register/ ثم POST /programmatic/verify-email/، مفتاح api_key ضمن الاستجابة مباشرة. → انظر التسجيل البرمجي للاطلاع على التدفق الكامل، وقواعد كلمة المرور، ومدة صلاحية JWT، وسياسة القفل.

الخيار ب: من Didit Console

  1. انتقل إلى Didit Console.
  2. أنشئ مؤسستك أو اختر مؤسسة موجودة.
  3. انتقل إلى الإعدادات ← API وwebhook.
  4. انسخ:
    • مفتاح API: يُستخدم كرأس x-api-key في كل استدعاء تحقق.
    • مفتاح webhook السري: يُستخدم للتحقق من توقيعات HMAC الخاصة بـ webhook.

متغيرات البيئة


الخطوة 2: أنشئ سير عمل

قبل إنشاء الجلسات، تحتاج إلى سير عمل للتحقق. يحدد سير العمل خطوات التحقق التي يمر بها المستخدمون.

الإنشاء من وحدة التحكم

  1. انتقل إلى Didit Console ← سير العمل
  2. انقر على إنشاء سير العمل
  3. اختر قالباً أساسياً:
  1. أضف الميزات الاختيارية:
  1. انسخ مُعرّف سير العمل
راجع توثيق سير العمل للاطلاع على خيارات الإعداد التفصيلية.

الخطوة 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.
→ InContext iframe

الخيار ج: إعادة التوجيه

وجّه المستخدم إلى رابط التحقق.
→ إعادة التوجيه إلى الويب

الخيار د: WebView في تطبيق الجوال

للتطبيقات المحمولة التي لا تملك SDK أصلية.
→ WebView في iOS/Android

الخطوة 5: استلام النتائج

عبر webhook (موصى به)

تُخطِر webhook خادمك فورياً عند تغيّر حالة التحقق. الإعداد:
  1. أنشئ وجهة webhook في لوحة التحكم (API & Webhooks) أو عبر POST /v3/webhook/destinations/ مع webhook_version: "v3" ومصفوفة subscribed_events (مثلاً ["status.updated"])
  2. احفظ secret_shared_key المُعاد عند الإنشاء، فهو سر HMAC لجميع متغيرات التوقيع
  3. نفّذ endpoint webhook على خادمك
مثال على حمولة 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.
→ التوثيق الكامل للـ webhooks، ويشمل التوقيع 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.

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

  1. اختر طريقة التكامل:
  2. إعداد webhook: Webhooks
  3. تخطيط السعة: حد المعدل
  4. معالجة كل حالة: حالات التحقق
  5. تخصيص سير العمل: سير العمل
  6. تحقق من إمكانية الوصول إلى API: Healthcheck

هل تحتاج إلى مساعدة؟

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