मुख्य सामग्री पर जाएं
Didit की डेटाबेस सत्यापन सुविधा प्रत्येक उपयोगकर्ता के पहचान डेटा को उस देश के आधिकारिक स्रोत से क्रॉस-रेफ़रंस करती है — RENAPER (अर्जेंटीना), Receita Federal (ब्राजील), Tribunal Electoral (पनामा, बायोमेट्रिक फ़ेस-मैच के साथ), Junta Central Electoral (डोमिनिकन गणराज्य), और अन्य — बिना किसी मासिक न्यूनतम के प्रति सफल क्वेरी बिल किया जाता है। database_validations[] में प्रत्येक प्रविष्टि एक पूर्ण डेटाबेस सत्यापन रिपोर्ट है — एक जारीकर्ता देश के विरुद्ध डेटाबेस सत्यापन नोड का एक रन। प्रति-सर्विस रजिस्ट्री परिणाम उस प्रविष्टि के validations[] सब-एरे के अंदर होते हैं। यह पेज JSON संरचना का विवरण प्रस्तुत करता है ताकि आप प्रत्येक सर्विस द्वारा लौटाए गए मिलान परिणामों, रजिस्ट्री स्रोत डेटा और बायोमेट्रिक स्कोर को पार्स कर सकें।
Didit डेटाबेस सत्यापन रिपोर्ट, जिसमें मिलान प्रकार और रजिस्ट्री रिस्पॉन्स फ़ील्ड दिखाए गए हैं

अवलोकन

हर बार जब कोई वर्कफ़्लो नोड डेटाबेस सत्यापन सुविधा को चलाता है, तो एक डेटाबेस सत्यापन रिपोर्ट तैयार की जाती है। 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 रिस्पॉन्स में यह कहाँ दिखाई देती है

रिपोर्ट GET /v3/session/{sessionId}/decision/ में database_validations[] के रूप में दिखाई देती है — हमेशा एक JSON एरे, कभी भी एक ऑब्जेक्ट नहीं। एरे में वर्कफ़्लो ग्राफ़ के प्रत्येक डेटाबेस सत्यापन नोड के लिए एक प्रविष्टि होती है; बदले में, प्रत्येक प्रविष्टि के validations[] सब-एरे में परिणाम देने वाली प्रत्येक रजिस्ट्री सर्विस के लिए एक आइटम होता है।
null मान का अर्थ है कि अभी तक कोई डेटाबेस सत्यापन चरण नहीं चला है।

स्कीमा

कैनोनिकल फ़ील्ड-दर-फ़ील्ड स्कीमा डेटा मॉडल पेज पर मौजूद है। यह DatabaseValidationV3Serializer द्वारा तैयार किया जाता है।

स्थिति मान

status मानक सुविधा-स्तरीय enum का उपयोग करता है (स्थिति enum देखें) — स्थिति enum संदर्भ देखें। यह enum 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)। यदि आपका वर्कफ़्लो एक ही देश के लिए कई सेवाएँ चलाता है (उदाहरण के लिए ब्राज़ील CPF + ब्राज़ील 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) में इमेज फ़ील्ड प्री-साइंड URLs के रूप में लौटाए जाते हैं जिनकी समय-सीमा समाप्त हो जाती है — निर्णय 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 में चली जाती है। छोड़ी गई सेवाओं के लिए कोई शुल्क नहीं लागू किया जाता है।
Console में सत्र विवरण पेज से अनुपलब्ध फ़ील्ड भरें — इसे सहेजने पर जाँच स्वचालित रूप से फिर से ट्रिगर हो जाती है और सफल होने पर चेतावनी हट जाती है।

संबंधित

अंतिम संशोधन 7 नवंबर 2026