database_validations[] تقريرًا كاملاً للتحقق من قواعد البيانات — تشغيل واحد لعقدة التحقق من قواعد البيانات مقابل دولة إصدار واحدة. وتوجد نتائج السجل الخاصة بكل خدمة داخل المصفوفة الفرعية validations[] التابعة لذلك الإدخال. توثق هذه الصفحة هيكل JSON حتى تتمكن من تحليل نتائج التطابق، والبيانات المصدرية من السجل، والدرجات البيومترية التي تُرجعها كل خدمة.

نظرة عامة
يتم إنشاء تقرير التحقق من قواعد البيانات في كل مرة تُشغّل فيها عقدة في سير العمل ميزة التحقق من قواعد البيانات. يمثل كل إدخال في مصفوفةdatabase_validations[] تشغيل عقدة واحد مقابل دولة إصدار واحدة؛ وإذا قامت العقدة بتشغيل خدمات متعددة لتلك الدولة (على سبيل المثال CPF + CNH في البرازيل)، فستظهر كل خدمة كعنصر منفصل داخل المصفوفة الفرعية validations[] التابعة لهذا الإدخال. يحتوي كل تقرير على:
statusالعام للميزة — قيمةFeatureStatusChoices(Not FinishedأوApprovedأوDeclinedأوIn Review).- نوع التطابق التراكمي
match_type(full_matchأوpartial_matchأوno_match، أوnullعندما لا تُرجع أي خدمة نتيجة قابلة للاستخدام) مجمّع عبر الخدمات من خلال طريقة التطابق. issuing_state(وفق معيار ISO 3166-1 alpha-3) وvalidation_typeالمشتق (one_by_oneأوtwo_by_twoأوnot_enabled— ولا يكونnullأبدًا).- كتلة
screened_data— البيانات المقدمة من المستخدم التي تم إرسالها إلى السجل. - مصفوفة
validations[]— إدخال واحد لكل خدمة أنتجت نتيجة، معservice_id/service_nameمن الدليل، وoutcome_codeالمحايد عن المورّدين، وoutcome_detailاختياري، وخريطةvalidationلكل حقل، وsource_dataالمُنقّحة والمستخرجة من استجابة السجل. - مصفوفة
errors[]— أخطاء خاصة بكل خدمة عند فشل البحث أو تخطيه؛ ويكون هذا المفتاح محذوفًا تمامًا في حال عدم وجود أخطاء. - مصفوفة
warnings[]— أحداث المخاطر الصادرة أثناء التحقق (راجع تحذيرات التحقق من قواعد البيانات). - حقل
node_idيحدد عقدة مخطط سير العمل التي أنتجت التقرير (جلسات V3 فقط).
أين يظهر في استجابات API
يظهر التقرير كـdatabase_validations[] في GET /v3/session/{sessionId}/decision/ — دائمًا كمصفوفة JSON، وليس ككائن مفرد مطلقًا. تحتوي المصفوفة على إدخال واحد لكل عقدة تحقق من قواعد البيانات في مخطط سير العمل؛ وبدورها، تحتوي المصفوفة الفرعية validations[] لكل إدخال على عنصر واحد لكل خدمة سجل أنتجت نتيجة.
null إلى أنه لم يتم تشغيل أي خطوة تحقق من قواعد البيانات بعد.
المخطط
يوجد المخطط المعتمد لكل حقل على حدة في صفحة نماذج البيانات. ويتم إنشاؤه بواسطةDatabaseValidationV3Serializer.
قيم الحالة
تستخدمstatus التعداد القياسي على مستوى الميزة (راجع تعدادات الحالة) — راجع مرجع تعدادات الحالة. يحدد التعداد أيضاً Resub Requested، وهو ما لا يُنتجه التحقق من قواعد البيانات عملياً.
تُطبَّق قواعد الحالة المخصصة لكل عقدة فوق هذه الحالة الأساسية. راجع تحذيرات التحقق من قواعد البيانات للاطلاع على الإجراءات القابلة للتهيئة وقيمها الافتراضية.
رموز النتائج
يحمل كل إدخال فيvalidations[] رمز outcome_code محايداً للمزودين — وهو أحد الرموز التالية: MATCH، أو PARTIAL_MATCH، أو NO_MATCH، أو DOCUMENT_NOT_FOUND، أو INVALID_DOCUMENT_FORMAT، أو INVALID_INPUT، أو MINOR_BLOCKED، أو DECEASED، أو BIOMETRIC_NO_MATCH، أو BIOMETRIC_IMAGE_UNUSABLE، أو INCONCLUSIVE، أو DOCUMENT_SUPERSEDED، أو REGISTRY_UNAVAILABLE، أو REGISTRY_ERROR. انتبه إلى الفروق: يعني NO_MATCH أن السجل لم يؤكد البيانات بشكل قاطع، ويعني INCONCLUSIVE أن السجل تعذر عليه تحديد النتيجة بأي من الاتجاهين (يتم التوجيه إلى المراجعة، وليس الرفض)، بينما BIOMETRIC_IMAGE_UNUSABLE هي مشكلة فنية في صورة سيلفي (إعادة التقاط) — على عكس BIOMETRIC_NO_MATCH القاطعة. راجع التصنيف الكامل وطريقة التعامل الموصى بها في صفحة رموز النتائج.
إدخال واحد لكل خدمة
تحتوي مصفوفةvalidations[] على عنصر واحد لكل خدمة أنتجت payload للنتيجة (كائن validation، أو source_data، أو outcome_code، أو outcome_detail). إذا كان سير العمل لديك يُشغّل خدمات متعددة لنفس الدولة (على سبيل المثال Brazil CPF + Brazil CNH)، فستظهر كل خدمة بشكل منفصل مع service_id وoutcome_code وsource_data الخاصة بها. وتعمل القيمة الإجمالية match_type على التجميع عبر جميع الخدمات (أي تطابق كامل → full_match؛ وإلا فإن أي تطابق جزئي → partial_match؛ وإلا no_match)، وتُشتق validation_type من عدد الخدمات المختلفة التي تطابقت بالكامل — راجع طرق التطابق.
عناوين URL الموقعة مسبقاً للصور
تُعاد حقول الصور فيsource_data (photo، signature) وscreened_data (selfie، cnh_qr_code_image، document_image) في صورة عناوين URL موقعة مسبقاً تنتهي صلاحيتها — يمكنك تحديثها عبر إعادة استدعاء endpoint القرار. ولا يتم كشف payload الخام الوارد من المصدر عبر API عن قصد.
أمثلة
مقبولة — التحقق من حالة CPF في البرازيل (Receita Federal)
مقبولة — التحقق البيومتري من DNI في الأرجنتين (RENAPER)
بالنسبة للأرجنتين، يستخدم التحقق RENAPER مع مطابقة الوجه البيومترية. تتضمن الاستجابةface_match_score وحقول هوية إضافية يعيدها السجل.
قيد المراجعة — تعذر تشغيل السجل
عندما لا تُعيد أي خدمة نتيجة قابلة للاستخدام — كأن تكون الحقول المطلوبة مفقودة أو غير صحيحة، أو يتعذر الوصول إلى السجل — تظلmatch_type بقيمة null، وتكون validation_type بقيمة not_enabled، ويصدر تحذير COULD_NOT_PERFORM_DATABASE_VALIDATION، وتنتقل الميزة إلى In Review حتى يتم تصحيح البيانات. لا تُفرض رسوم على الخدمات التي تم تخطيها.
ذات صلة
- نظرة عامة على التحقق من قواعد البيانات — كيف تعمل API بشكل شامل والسجلات المدعومة.
- طرق التطابق — كيفية اشتقاق نتائج 1×1 / 2×2 (
validation_type: one_by_one/two_by_two). - رموز النتائج — التصنيف الكامل لكل نتيجة مع رموز التفاصيل الخاصة بكل دولة.
- الدول والخدمات المدعومة — كل سجل فعّال، والحقول المطلوبة، وسعر كل استدعاء.
- تحذيرات التحقق من قواعد البيانات — ما نعرضه عندما يتعذر تشغيل إحدى الخدمات.
- نماذج البيانات — التحقق من قواعد البيانات — المخطط المعتمد لكل حقل على حدة.