मुख्य सामग्री पर जाएं
POST
Python
टाइप किए गए पहचानकर्ता और दावा की गई पहचान विशेषताएँ सबमिट करें, चलाने के लिए जाँच चुनें, और हर परिणाम को अलग-अलग जाँचें। इनपुट आवश्यकताओं और अनुमानित शुल्क की जाँच के लिए पहले फ़्रॉड जाँच की योजना बनाएँ का उपयोग करें।

प्रोफ़ाइल चुनें

profile_version को पिन करें, ताकि चुने गए डिफ़ॉल्ट और निर्णय नीति स्पष्ट रहें। डिफ़ॉल्ट प्रोफ़ाइल standard है, संस्करण 2026-08-27। संस्करण 2026-09-14 में ईमेल और फ़ोन के वैकल्पिक सोशल एनरिचमेंट जुड़ जाते हैं, और पूरी हुई हर जाँच को नेटिव उपयोगकर्ता सत्यापन सत्र के रूप में दर्ज किया जाता है। इस संस्करण में भुगतान वाले ऐड-ऑन ऑप्ट-इन होते हैं। संस्करण 2026-09-14.1 में Enterprise प्लान वाले उन संगठनों के लिए वैश्विक धोखाधड़ी नेटवर्क पहचानकर्ता लुकअप भी सक्षम हो जाते हैं जो वैश्विक स्तर पर साझा करते हैं। संस्करण 2026-09-14.2 ब्राज़ील के लिए एक वैकल्पिक सेल्फ़ी-से-CPF संदर्भ जाँच जोड़ता है। पुराने संस्करण अपना मूल व्यवहार बनाए रखते हैं। मौजूदा प्रोफ़ाइलें ईमेल जोखिम, फ़ोन जोखिम, IP जोखिम, योग्य डेटाबेस सत्यापन और आपके एप्लिकेशन के निजी नेटवर्क इतिहास को सपोर्ट करती हैं। सेल्फ़ी-आधारित पहचान बाइंडिंग के लिए संस्करण 2026-09-14.2 की आवश्यकता होती है। पुराने संस्करणों में इसे चुनने पर not_available_in_profile_version लौटता है।

दावा की गई पहचान और संदर्भ

ईमेल, फ़ोन और सरकारी पहचानकर्ता subject.identifiers में डालें। सरकारी पहचानकर्ताओं के लिए उनका जारीकर्ता देश आवश्यक है; जिन क्षेत्रों में संख्याएँ केवल एक क्षेत्र के भीतर अद्वितीय होती हैं, वहाँ जारीकर्ता की भी आवश्यकता हो सकती है। नाम, जन्म तिथि, राष्ट्रीयता और पता subject.attributes में डालें। ये वे दावे हैं जिन्हें चुने गए स्रोत के समर्थन की स्थिति में मिलाया जाता है; केवल सबमिट किए जाने से ये सत्यापित तथ्य नहीं बन जाते। प्रयास के IP पते, उपयोगकर्ता एजेंट, उद्देश्य, देश और किसी भी आवश्यक सहमति कथन के लिए context का उपयोग करें। इससे सत्यापन प्रयास की जानकारी और व्यक्ति की जानकारी अलग रहती है। समर्थित बायोमेट्रिक जाँचों के लिए subject.selfie को base64-एन्कोडेड JPEG, PNG, या WebP के रूप में दें, जिसका आकार 6 MB तक हो। मेल खाने वाला इमेज डेटा URI भी स्वीकार किया जाता है। संदर्भ छवि, रिमोट URL, या स्टोरेज कुंजी न भेजें।

सेल्फ़ी और दावा किया गया पहचानकर्ता

biometric_identity चुनें, एक ब्राज़ीलियाई tax_number पहचानकर्ता और सेल्फ़ी सबमिट करें, और context.consent_obtained की पुष्टि करें। संदर्भ जाँच करती है कि वह सेल्फ़ी दावा किए गए CPF धारक की है या नहीं। सहमति न होने पर consent_required लौटता है, और असमर्थित देशों के लिए unsupported_region लौटता है। इस मॉड्यूल की प्रति-जाँच कीमत आपके संगठन की डेटाबेस सत्यापन दर पर आधारित है; इसे चलाने से पहले प्लान की जाँच करें। जब संदर्भ जाँच का उत्तर मिलता है, तो identity_relationship.result match, mismatch, या inconclusive होता है। अनिर्णायक उत्तर के लिए समीक्षा आवश्यक है, और उसे कभी भी असंगति नहीं माना जाता। परिणाम केवल सेल्फ़ी और CPF के बीच के संबंध को स्थापित करता है। यह सबमिट किए गए नाम या जन्म तिथि को सत्यापित नहीं करता, लाइवनेस साबित नहीं करता, और इंटरनेट या वैश्विक धोखाधड़ी नेटवर्क पर चेहरे की खोज नहीं करता। नाम और जन्म तिथि दावे ही बने रहते हैं, जब तक कोई अन्य चुना गया स्रोत उन फ़ील्ड के लिए साक्ष्य न दे। टाइमआउट और स्रोत त्रुटियाँ अनुपलब्ध परिणाम हैं और इनका बिल नहीं बनता। जिन अनिर्णायक उत्तरों का निष्पादन पूरा हो चुका है, उनका बिल उसी संदर्भ-जाँच दर पर बनता है। इस जाँच द्वारा सेल्फ़ी परिणाम में शामिल नहीं की जाती और सत्र मीडिया के रूप में संग्रहीत नहीं की जाती।

जाँच चुनें

checks.include मॉड्यूल चुनता है, और checks.exclude को प्राथमिकता मिलती है। include की स्पष्ट खाली सूची सभी वैकल्पिक कार्य बंद कर देती है; सामान्यीकरण फिर भी चलता है। include छोड़ने पर पिन की गई प्रोफ़ाइल के डिफ़ॉल्ट उपयोग होते हैं। ईमेल और फ़ोन सोशल एनरिचमेंट को email_social और phone_social से अलग-अलग चुना जाता है। इनके लिए मान्य और मेल खाता पहचानकर्ता आवश्यक है, और ये OTP नहीं भेजते।

परिणामों को आपस में मिलाए बिना पढ़ें

हर मॉड्यूल अपनी निष्पादन स्थिति, कारण और बिलिंग योग्य इकाइयाँ रिपोर्ट करता है। not_requested, excluded_by_caller, missing_required_input, और source_unavailable अलग-अलग परिणामों का वर्णन करते हैं। अनुपस्थित स्रोत पहचान में असंगति नहीं है, और न ही शून्य-जोखिम परिणाम है। attribute_evidence फ़ील्ड-स्तर के साक्ष्य का वर्णन करता है, जबकि risk पहचान, संपर्क, डिवाइस, व्यवहार और धोखाधड़ी-नेटवर्क के आयामों को अलग रखता है। साझा ईमेल, डिवाइस या किसी अन्य पहचानकर्ता को देखा गया संबंध माना जाता है; यह इस बात का प्रमाण नहीं कि दो खाते एक ही व्यक्ति के हैं या उन्होंने धोखाधड़ी की है। recommendation उस जाँच की सिफ़ारिश है; यह किसी अन्य रिकॉर्ड की स्थिति नहीं बदलती। सोशल एनरिचमेंट के परिणाम enrichment के अंतर्गत दिखते हैं, और अनुपलब्ध परिणाम पूरे हुए परिणामों से अलग दिखाए जाते हैं।

वैश्विक फ़्रॉड नेटवर्क

networks_cross_org चुनें, ताकि समर्थित ईमेल, फ़ोन और उचित नेमस्पेस वाले दस्तावेज़ पहचानकर्ता साझा नेटवर्क में खोजे जा सकें। इस लुकअप के लिए Enterprise प्लान और आपके संगठन का शेयरिंग मोड global पर सेट होना ज़रूरी है। इनके बिना प्लान मॉड्यूल को available: false और availability_reason: "entitlement_required" के साथ रिपोर्ट करता है। जो जाँच इसे चुनती है, वह इसे skipped स्थिति और entitlement_required कारण के साथ छोड़ देती है। यही कारण तब भी लागू होता है जब आपके संगठन के लिए Networks सक्षम नहीं है। सैंडबॉक्स एप्लिकेशन पर प्लान या शेयरिंग मोड की शर्त लागू नहीं होती। समर्थित पहचानकर्ता के साथ मॉड्यूल चलता है और खाली नमूना परिणाम लौटाता है। यह लुकअप मौजूदा संगठन के रीड बजट का उपयोग करता है और रीड का ऑडिट रिकॉर्ड करता है। प्रति लुकअप कोई शुल्क नहीं लगता। जाँच की योजना बनाने से साझा इंडेक्स की क्वेरी नहीं होती और उसका रीड बजट खर्च नहीं होता। जाँच पूरी होने पर network.cross_organization में signals_checked और खुलासा किए गए समग्र insights होते हैं। हर इनसाइट में सिग्नल का प्रकार, परिणाम श्रेणियाँ, योगदानकर्ता की संख्या और हालिया अवधि की श्रेणी होते हैं। उद्योग श्रेणियाँ केवल तब शामिल होती हैं जब खुलासा सक्षम हो। इनसे कभी किसी दूसरे संगठन, खाते, व्यक्ति या सत्यापन की पहचान नहीं होती। खुलासा थ्रेशोल्ड से नीचे के परिणाम छोड़ दिए जाते हैं। खाली सूची का अर्थ यह नहीं है कि फ़्रॉड का कोई इतिहास नहीं है। खुलासा किया गया साझा सिग्नल समीक्षा की सिफ़ारिश को ट्रिगर करता है। वह कभी स्वचालित अस्वीकृति या पहचान मिलान नहीं होता। अनुपलब्ध लुकअप का कारण, खाली लेकिन पूरे हुए लुकअप से अलग, रिपोर्ट किया जाता है। अगर आपके संगठन की क्रॉस-ऑर्गनाइज़ेशन पहुँच बाद में खो जाती है, उदाहरण के लिए प्लान बदलने पर या शेयरिंग global न रहने पर, तो परिणाम की पुनर्प्राप्ति, पुनः प्रयास और सत्र का विवरण साझा समग्र डेटा और उससे निकले जोखिम साक्ष्य छिपा देते हैं। मूल सिफ़ारिश एक ऐतिहासिक निर्णय बनी रहती है, और रीड से सत्यापन की स्थिति नहीं बदलती।

सत्र, पुनः प्रयास और शुल्क

check_id Get a Fraud Check के ज़रिए संग्रहीत परिणाम लौटाता है। मौजूद होने पर request_id उसके मूल सत्यापन सत्र की पहचान करता है। संस्करण 2026-09-14, 2026-09-14.1 और 2026-09-14.2 हमेशा वह सत्र बनाते हैं, भले ही केवल निजी नेटवर्क इतिहास चुना गया हो। उसी अनुरोध बॉडी के साथ client_reference का दोबारा उपयोग करने पर, जब तक वह जाँच मौजूद है, मूल परिणाम लौटता है, बिना दोबारा निष्पादन या शुल्क के। उसी संदर्भ के साथ अलग बॉडी भेजने पर 409 लौटता है। अगर निष्पादन अब भी चल रहा है, तो रिस्पॉन्स के Retry-After अंतराल के बाद उसी अनुरोध को दोबारा भेजें। संबंधित सत्यापन हटाने पर Fraud Check परिणाम भी हट जाता है, और फिर पुनर्प्राप्ति पर 404 लौटता है। निष्पादन के दौरान हटाई गई जाँच पूरा परिणाम प्रकाशित नहीं कर सकती। कीमतें आपके संगठन की मौजूदा प्रीपेड या अनुबंध दरों से आती हैं। अनुपलब्ध और छोड़े गए मॉड्यूल का शुल्क नहीं लगता, और निजी नेटवर्क इतिहास का प्रति जाँच कोई शुल्क नहीं है। सैंडबॉक्स जाँच नमूना रिस्पॉन्स का उपयोग करती है, जिसमें कोई शुल्क वाली आपूर्तिकर्ता कॉल या शुल्क नहीं होता।

प्राधिकरण

x-api-key
string
header
आवश्यक

आपकी एप्लिकेशन की API कुंजी, Business Console में Developers -> API keys से। प्राथमिक कुंजी के पास पूर्ण एक्सेस होता है। एक नामित कुंजी को स्कोप किया जा सकता है: प्रति संसाधन none, read या write, कुछ वर्कफ़्लो या स्वीकृत सत्रों तक सीमित, IP पतों की सूची तक सीमित, और समाप्ति तिथि तक सीमित। 401 का अर्थ है कि कुंजी गलत है, निरस्त कर दी गई है या उसकी समय-सीमा समाप्त हो गई है; 403 का अर्थ है कि कोई कुंजी नहीं भेजी गई थी, कुंजी के पास इस संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध उसकी IP सूची से बाहर के पते से आया था; सत्र रूट पर 404 का अर्थ है कि सत्र कुंजी के वर्कफ़्लो या स्थितियों से बाहर है। मीडिया एक्सेस के बिना एक कुंजी को छवि, वीडियो और PDF URL null के रूप में प्राप्त होते हैं, और सत्र write के बिना एक कुंजी को सत्र लिंक और token null के रूप में प्राप्त होते हैं। देखें https://docs.didit.me/console/api-keys।

बॉडी

subject
object
आवश्यक
client_reference
string

इस जाँच के लिए आपका अपना संदर्भ। यह आइडेम्पोटेंसी कुंजी के रूप में भी काम करता है: समान बॉडी के साथ इसका पुन: उपयोग करने से मॉड्यूल को दोबारा चलाए या बिल किए बिना मूल जाँच वापस मिल जाती है; एक अलग बॉडी के साथ इसका पुन: उपयोग करने पर 409 वापस आता है।

Required string length: 1 - 255
profile
string
डिफ़ॉल्ट:standard

ऑर्केस्ट्रेशन प्रोफ़ाइल id। डिफ़ॉल्ट रूप से Didit standard प्रोफ़ाइल पर सेट होता है।

Required string length: 1 - 64
profile_version
string

फ़्रीज़ किए गए प्रोफ़ाइल संस्करण को पिन करें। डिफ़ॉल्ट रूप से प्रोफ़ाइल का वर्तमान संस्करण होता है।

Required string length: 1 - 32
context
object
checks
object
vendor_data
string
Maximum string length: 1000
metadata
any

प्रतिक्रिया

check_id
string<uuid>
आवश्यक
client_reference
string | null
आवश्यक
processing_status
enum<string>
आवश्यक
  • pending - लंबित
  • running - चल रहा है
  • completed - पूर्ण
  • failed - विफल
उपलब्ध विकल्प:
pending,
running,
completed,
failed
profile_id
string
आवश्यक
profile_version
string
आवश्यक
created_at
string<date-time>
आवश्यक
completed_at
string<date-time> | null
आवश्यक
inputs
object[]
आवश्यक
modules
object[]
आवश्यक
attribute_evidence
object[]
आवश्यक
compound_evidence
object[]
आवश्यक
risk
object[]
आवश्यक
network
object
आवश्यक
recommendation
enum<string>
आवश्यक
  • approve - स्वीकृत करें
  • review - समीक्षा करें
  • reject - अस्वीकृत करें
उपलब्ध विकल्प:
approve,
review,
reject
next_action
enum<string>
आवश्यक
  • none - कोई नहीं
  • manual_review - मैन्युअल समीक्षा
  • step_up - स्टेप अप
  • resubmit_capture - कैप्चर पुनः सबमिट करें
उपलब्ध विकल्प:
none,
manual_review,
step_up,
resubmit_capture
decision_reasons
string[]
आवश्यक
coverage
object
आवश्यक
usage
object[]
आवश्यक
request_id
string<uuid>

इस जाँच के लिए बनाया गया मूल सत्यापन सत्र।

enrichment
object
identity_relationship
object | null
vendor_data
string | null
metadata
unknown
अंतिम संशोधन 7 नवंबर 2026