मुख्य सामग्री पर जाएं
POST
curl

अवलोकन

चयनित उपयोगकर्ता इकाइयों के लिए सतत AML निगरानी को सक्षम या अक्षम करता है, ठीक वैसे ही जैसे Business Console में सतत AML निगरानी कार्रवाई करती है। Console और यह endpoint एक ही अंतर्निहित ऑपरेशन चलाते हैं, इसलिए नियम, बिलिंग और परिणाम समान होते हैं। पहले estimate_only: true भेजें ताकि पता चले कि कितने उपयोगकर्ता चयनित हैं, कितनों को नई AML स्क्रीनिंग की आवश्यकता है, एक बार की स्क्रीनिंग लागत और वार्षिक निगरानी लागत कितनी है। ड्राई-रन से कुछ भी लिखा नहीं जाता।

इसका उपयोग कब करें

  • प्रोग्रामैटिक ऑनबोर्डिंग: API के माध्यम से आयात या बनाए गए उपयोगकर्ताओं के लिए निगरानी चालू करें, बिना उन्हें हाथ से दोबारा स्क्रीन किए।
  • ऑफ़बोर्डिंग: उन उपयोगकर्ताओं के लिए निगरानी और उसका वार्षिक नवीकरण बंद करें जो आपके प्लेटफ़ॉर्म से चले गए हैं।
  • लागत नियंत्रण: किसी चयन के लिए प्रतिबद्ध होने से पहले उसकी सटीक लागत पर पड़ने वाले असर का पूर्वावलोकन करें।

चयन कैसे संसाधित होता है

  • प्रति उपयोगकर्ता एक निगरानी वाली स्क्रीनिंग। कई बार सत्यापन कराने वाले उपयोगकर्ता की केवल एक स्क्रीनिंग की निगरानी की जाती है और बिल भी एक ही बार लगता है। अक्षम करने पर उस उपयोगकर्ता की सभी स्क्रीनिंग पर निगरानी बंद हो जाती है।
  • बिना AML स्क्रीनिंग वाले उपयोगकर्ताओं की पहले स्क्रीनिंग होती है। Didit उनके लिए एक नया AML सत्यापन बनाता है (जो उपयोगकर्ता के Verifications टैब में दिखता है), उसका बिल एक सामान्य AML स्क्रीनिंग की तरह लगता है, और उस पर निगरानी चालू हो जाती है। इसके लिए उपयोगकर्ता का पूरा नाम, जन्म तिथि और देश चाहिए; इनमें से कोई भी न होने पर उपयोगकर्ता को skipped_no_identity_data के रूप में रिपोर्ट किया जाता है, चुपचाप छोड़ा नहीं जाता।
  • ब्लॉक किए गए उपयोगकर्ता छोड़ दिए जाते हैं (skipped_blocked)। सैंडबॉक्स एप्लिकेशन कभी स्क्रीनिंग नहीं बनाते (skipped_sandbox)।
  • बैलेंस पहले से जाँचा जाता है। जब आपका बैलेंस अनुमान को कवर नहीं करता, तो चालू करने का अनुरोध 403 के साथ अस्वीकार हो जाता है, और प्रतिक्रिया में अनुमान शामिल होता है ताकि आपको पता रहे कि कितना टॉप अप करना है।
  • वार्षिक नवीकरण। नई निगरानी वाले उपयोगकर्ता से उसकी अगली नवीकरण तिथि पर वार्षिक निगरानी मूल्य लिया जाता है, वही तिथि जो Console में सतत निगरानी कॉलम में दिखती है। अक्षम करने से नवीकरण रुक जाता है, लेकिन पहले से बिल की जा चुकी अवधि का रिफ़ंड नहीं होता।

चयन और बैच आकार

vendor_data_list, didit_internal_id_list, या दोनों से उपयोगकर्ता चुनें; दोनों सूचियों को OR के रूप में लिया जाता है। एक अनुरोध में दोनों सूचियों को मिलाकर अधिकतम 1000 पहचानकर्ता स्वीकार होते हैं। जो पहचानकर्ता आपके एप्लिकेशन के किसी उपयोगकर्ता से मेल नहीं खाते, वे unmatched के अंतर्गत ठीक वैसे ही लौटाए जाते हैं जैसे भेजे गए थे, और वे अनुरोध को कभी विफल नहीं करते: जो चयन किसी से भी मेल नहीं खाता, वह खाली जॉब (total: 0) के रूप में पूरा होता है, जिसमें सभी पहचानकर्ता सूचीबद्ध होते हैं, जो बैच डिलीट endpoints की परिपाटी जैसा है।

इनलाइन या पृष्ठभूमि में

20 या उससे कम उपयोगकर्ताओं वाले चयन इनलाइन संसाधित होते हैं और कॉल 200 के साथ पूरी हुई जॉब लौटाता है। बड़े चयन PENDING जॉब के साथ 202 लौटाते हैं; जब तक status COMPLETED या FAILED न हो जाए, AML निगरानी जॉब प्राप्त करें को पोल करें। दोनों ही स्थितियों में जॉब में प्रति उपयोगकर्ता एक results प्रविष्टि होती है, जिसमें उसका outcome होता है।

Webhooks

निगरानी चालू या बंद करने से कोई अपना webhook इवेंट नहीं भेजा जाता। एक बार निगरानी चालू होने के बाद, दोबारा स्क्रीनिंग पर सतत AML निगरानी में बताए गए सामान्य status.updated और data.updated इवेंट भेजे जाते रहते हैं।

अनुमतियाँ

एप्लिकेशन की कोई भी सक्रिय API कुंजी इस endpoint को कॉल कर सकती है। Didit API कुंजियाँ एप्लिकेशन-स्तरीय हैं, भूमिका-स्तरीय नहीं: Console की भूमिकाएँ और अनुमतियाँ यह तय करती हैं कि कोई व्यक्ति Console में क्या कर सकता है, और Management API ट्रैफ़िक के लिए इनका मूल्यांकन नहीं किया जाता।

संबंधित

प्राधिकरण

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।

बॉडी

application/json

vendor_data_list, didit_internal_id_list, या दोनों के साथ उपयोगकर्ताओं का चयन करें (दोनों सूचियाँ OR की जाती हैं)। दोनों सूचियों को मिलाकर प्रति अनुरोध अधिकतम 1000 पहचानकर्ता।

is_enabled
boolean
आवश्यक

निगरानी सक्षम करने के लिए true, इसे अक्षम करने के लिए false।

estimate_only
boolean
डिफ़ॉल्ट:false

true होने पर, लागत अनुमान लौटाता है और कोई राइट ऑपरेशन नहीं करता है - कोई स्क्रीनिंग नहीं, कोई बिलिंग नहीं, कोई जॉब नहीं।

vendor_data_list
string[]

टॉगल करने के लिए उपयोगकर्ताओं के आपके अपने पहचानकर्ता, ठीक वैसे ही मिलान किए जाते हैं जैसे भेजे गए थे।

didit_internal_id_list
string<uuid>[]

टॉगल करने के लिए उपयोगकर्ताओं की Didit आंतरिक ids - create, get और list endpoints द्वारा लौटाई गई didit_internal_id।

प्रतिक्रिया

अनुमान (जब estimate_only सत्य हो) या इनलाइन प्रोसेस किए गए चयन के लिए पूर्ण किया गया कार्य।

लागत पूर्वावलोकन। estimate_only true होने पर सीधे लौटाया जाता है (कुछ भी लिखा नहीं जाता है)।

users_total
integer
आवश्यक

चयन द्वारा मिलान की गई प्रोफ़ाइल।

already_enabled
integer
आवश्यक

पहले से मॉनिटर की जा रही प्रोफ़ाइल (सक्षम करते समय कुछ करने की आवश्यकता नहीं है; अक्षम करने पर इन्हें ही बंद किया जाता है)।

with_existing_aml
integer
आवश्यक

वे प्रोफ़ाइल जिनकी मौजूदा AML स्क्रीनिंग को निगरानी में बदल दिया जाएगा (कोई नई स्क्रीनिंग नहीं)।

needing_screening
integer
आवश्यक

बिना किसी AML स्क्रीनिंग वाली प्रोफ़ाइल जिनकी पहले स्क्रीनिंग की जाएगी (नियमित AML स्क्रीनिंग के रूप में बिल किया जाएगा)।

skipped_no_identity_data
integer
आवश्यक

वे प्रोफ़ाइल जिनकी स्क्रीनिंग नहीं की जा सकती क्योंकि पहचान डेटा मौजूद नहीं है।

skipped_blocked
integer
आवश्यक

ब्लॉक किए गए उपयोगकर्ता जिन्हें छोड़ दिया जाएगा (व्यवसायों के लिए हमेशा 0)।

estimated_screening_cost_usd
number
आवश्यक

नई स्क्रीनिंग की एकमुश्त लागत।

उदाहरण:

0.2

estimated_annual_monitoring_cost_usd
number
आवश्यक

उन प्रोफ़ाइलों की वार्षिक निगरानी लागत जिनकी निगरानी शुरू की जाएगी।

उदाहरण:

0.07

balance_sufficient
boolean
आवश्यक

क्या संगठन का बैलेंस स्क्रीनिंग और निगरानी के पहले वर्ष को कवर करता है।

unmatched
string[]
आवश्यक

अनुरोध के वे पहचानकर्ता जिनका इस एप्लिकेशन में किसी प्रोफ़ाइल से मिलान नहीं हुआ, बिल्कुल वैसे ही जैसे भेजे गए थे।

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