मुख्य सामग्री पर जाएं
हर उपयोगकर्ता और व्यवसाय इकाई Didit में एक पूर्वानुमेय जीवनचक्र से गुज़रती है। इस जीवनचक्र को समझना आपके ऑनबोर्डिंग, सतत निगरानी और उपचारात्मक प्रवाह को डिज़ाइन करने की कुंजी है।

​
जीवनचक्र आरेख

​
स्थितियों का विस्तृत विवरण

PATCH /v3/users/{vendor_data}/update-status/ या PATCH /v3/businesses/{vendor_data}/update-status/ के ज़रिए स्थिति बदलने पर एक webhook (user.status.updated / business.status.updated) भेजा जाता है, ताकि डाउनस्ट्रीम सिस्टम वास्तविक समय में प्रतिक्रिया दे सकें।

​
जीवनचक्र के चरण

निर्माण

एक इकाई तीन तरीकों में से किसी एक से बनाई जाती है:
  • एक नए vendor_data के साथ सत्र शुरू करने पर स्वचालित रूप से बनाई जाती है। इकाई ACTIVE स्थिति में बनती है।
  • POST /v3/users/create/ या POST /v3/businesses/create/ का उपयोग करके API के ज़रिए पहले से बनाई जाती है। स्थिति डिफ़ॉल्ट रूप से ACTIVE होती है।
  • एक अनुपालन अधिकारी द्वारा कंसोल में बनाई गई। जब तक अधिकारी अलग से निर्दिष्ट न करे, स्थिति ACTIVE से शुरू होती है।
हर इकाई को Didit द्वारा बनाया गया एक uuid और ग्राहक के स्वामित्व वाला एक vendor_data पहचानकर्ता मिलता है।

सत्यापन

सत्र vendor_data के ज़रिए इकाई से जुड़े होते हैं। हर सत्र आपके कॉन्फ़िगर किए गए वर्कफ़्लो से गुज़रता है: पहचान सत्यापन, लाइवनेस, चेहरा मिलान, AML, दस्तावेज़, KYB के लिए रजिस्ट्री लुकअप, और अन्य।पूरे हुए सत्र इकाई के कुल काउंटर अपडेट करते हैं:
  • session_count, approved_count, declined_count, in_review_count
  • features मैप: सभी सत्रों में प्रत्येक सुविधा की नवीनतम स्थिति (जैसे { "id_verification": "APPROVED", "aml": "IN_REVIEW" })
  • प्रोफ़ाइल फ़ील्ड्स नवीनतम स्वीकृत सत्र से लागू होते हैं (जैसे full_name, date_of_birth, portrait_image)।

सक्रिय उपयोग

एक बार इकाई के पास एक या अधिक स्वीकृत सत्र हो जाएँ, तो आप यह कर सकते हैं:
  • पेलोड में vendor_data के ज़रिए इकाई का संदर्भ देते हुए लेन-देन सबमिट करना
  • सतत AML निगरानी चलाना: प्रतिबंध / PEP / प्रतिकूल मीडिया सूचियों का समय-समय पर पुनः स्कैन
  • निर्धारित समय पर पुनः सत्यापन करना: नियमित अंतराल पर एक ही vendor_data के लिए नए सत्र बनाना
  • सत्रों और लेन-देन में जोखिम संकेतों को एकत्र करना

स्थिति परिवर्तन

इकाई की स्थिति स्वचालित या मैन्युअल रूप से बदलती है।स्वचालित परिवर्तन
  • ACTIVE → FLAGGED जब कोई लेन-देन समीक्षा थ्रेशोल्ड पार करता है या कोई नियम इकाई को वॉचलिस्ट में जोड़ता है।
  • ACTIVE → BLOCKED जब किसी चेहरे का बायोमेट्रिक डेटा ब्लॉकलिस्ट की किसी प्रविष्टि से मेल खाता है।
अस्वीकृत सत्र इकाई को ब्लॉकलिस्ट में नहीं डालता, इसलिए उसकी स्थिति नहीं बदलती। अस्वीकृत व्यक्ति को ब्लॉकलिस्ट में डालना एक मैन्युअल चरण है: ब्लॉकलिस्ट पेज या Lists API से प्रविष्टि जोड़ें, और USER प्रविष्टि (vendor_data) स्थिति को BLOCKED पर सेट कर देती है।मैन्युअल परिवर्तन तब होते हैं जब कोई विश्लेषक कंसोल से स्थिति बदलता है या आप update-status endpoint को कॉल करते हैं।हर परिवर्तन एक user.status.updated या business.status.updated webhook भेजता है।

हटाना

इकाइयाँ POST /v3/users/delete/ या POST /v3/businesses/delete/ (बैच) के ज़रिए हटाई जाती हैं। इकाई का रिकॉर्ड स्थायी रूप से हटा दिया जाता है। किसी उपयोगकर्ता को हटाने पर सत्र हटने के बाद उसके लिए रखे गए हर बायोमेट्रिक टेम्पलेट को भी हटा दिया जाता है, ताकि डुप्लिकेट डिटेक्शन और चेहरा खोज में उस व्यक्ति का मिलान होना बंद हो जाए।सत्रों और लेन-देन पर ये endpoints लागू नहीं होते। सत्रों को Delete Session या Batch Delete Sessions से हटाएँ; लेन-देन कंसोल से हटाए जाते हैं।

​
गतिविधि टाइमस्टैम्प

इकाइयाँ गतिविधि को ट्रैक करती हैं, ताकि आप निष्क्रिय या सक्रिय प्रोफ़ाइल पहचान सकें: इन टाइमस्टैम्प का उपयोग निष्क्रिय इकाइयों को फ़िल्टर करने, पुनः सत्यापन शेड्यूल करने, या सतत निगरानी शुरू करने के लिए करें।

​
जीवनचक्र के दौरान उत्सर्जित इवेंट

पेलोड की संरचना और डिलीवरी के नियमों के लिए इकाई के webhook देखें।

​
अगले चरण

वेंडर डेटा लिंकिंग

vendor_data सत्रों, लेन-देन और इकाइयों को आपस में कैसे जोड़ता है।

उपयोगकर्ता संचालन

उपयोगकर्ता इकाइयाँ बनाएँ, अपडेट करें, स्थिति बदलें और हटाएँ।

व्यवसाय संचालन

व्यवसाय इकाइयाँ बनाएँ, अपडेट करें, स्थिति बदलें और हटाएँ।
अंतिम संशोधन 7 नवंबर 2026