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

अवलोकन

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

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

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

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

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

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

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

Webhooks

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

अनुमतियाँ

एप्लिकेशन की कोई भी सक्रिय API कुंजी इस endpoint को कॉल कर सकती है। Didit API कुंजियाँ एप्लिकेशन-स्तरीय हैं, भूमिका-स्तरीय नहीं। कंसोल की भूमिकाएँ और अनुमतियाँ तय करती हैं कि कोई व्यक्ति कंसोल में क्या कर सकता है, और 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