KYB रजिस्ट्री API: कंपनी खोज और चयन

एंडपॉइंट और बिलिंग

सफल स्टैंडअलोन खोजों पर, जो किसी सशुल्क कंपनी-डेटा स्रोत का उपयोग करती हैं, प्रति अनुरोध $0.50 शुल्क लगता है, चाहे उम्मीदवार कंपनियों की संख्या कुछ भी हो। खाली परिणाम, विफल खोजें और केवल अन्य स्रोतों से मिले परिणाम शुल्क-मुक्त हैं। बाद में प्रोफ़ाइल प्राप्त करने का शुल्क अलग से लिया जाता है। डेटा पुनर्प्राप्ति तीन डेटा स्तरों में बेची जाती है। हर स्तर का अपना endpoint है, और मूल्य देश के अनुसार तय होता है (देश-वार मूल्य)।

endpoint	आपको क्या मिलता है	मूल्य
`POST /v3/kyb/search/`	उम्मीदवार कंपनियाँ: नाम, पंजीकरण संख्या, स्थिति, प्रकार	$0.50 जब सशुल्क स्रोत से परिणाम लौटाए जाते हैं
`POST /v3/kyb/select/`	Lite: कंपनी की प्रोफ़ाइल (पहचानकर्ता, स्थिति, कानूनी रूप, निगमन तिथि, पंजीकृत पता, गतिविधि, संपर्क विवरण) और अधिकारी	Lite मूल्य: देश के अनुसार $2.00-$3.00
`POST /v3/kyb/shareholders/`	Lite के साथ सीधे शेयरधारक और उनके स्वामित्व के दायरे	Shareholders मूल्य: देश के अनुसार $5.00-$22.00
`POST /v3/kyb/ubo/`	Shareholders के साथ, स्वामित्व श्रृंखला से हल किए गए अंतिम वास्तविक स्वामी	UBO मूल्य: देश के अनुसार $9.00-$96.00

select ही Lite स्तर है: यही वह endpoint है जिसके लिए एक होस्टेड KYB वर्कफ़्लो Lite स्तर पर रजिस्ट्री जाँच का बिल करता है, और इसका वही अनुबंध बना रहता है जो हमेशा से रहा है। “यूरोप” का अर्थ है EEA, यूनाइटेड किंगडम और स्विट्ज़रलैंड। शेयरधारक या UBO खोज उस स्वामित्व स्रोत से पूछती है जो उस स्तर की सेवा करता है। जब वह स्रोत बताता है कि उसके पास कंपनी नहीं है, तो खोज देश के अन्य रजिस्ट्री स्रोतों से भी पूछती है। इस तरह, जो कंपनी स्वामित्व स्रोत में सूचीबद्ध नहीं है, वह भी उम्मीदवार के रूप में पेश की जाती है और मैन्युअल प्रविष्टि पर नहीं रुकती। इस तरह मिले उम्मीदवार आपके माँगे गए स्तर को ही रखते हैं: उन्हें प्राप्त करते समय स्वामित्व स्रोत की दोबारा जाँच होती है, और जब कंपनी अब भी उसके पास दर्ज नहीं होती, तो Lite प्रोफ़ाइल दी जाती है और बिल की जाती है, साथ में registry_ownership_status: "not_held" होता है।

आप वही स्तर का भुगतान करते हैं जो दिया गया है। हर प्रतिक्रिया में registry_tier_requested और registry_tier_delivered होते हैं। जब देश की रजिस्ट्रियों के पास स्वामित्व डेटा नहीं होता, या रजिस्ट्री के पास चुनी गई कंपनी का कोई स्वामित्व रिकॉर्ड नहीं होता, तो स्वामित्व अनुरोध सबसे उच्च उपलब्ध स्तर (आमतौर पर Lite) पर दिया और बिल किया जाता है, और registry_ownership_status इसका कारण बताता है। जिस UBO अनुरोध की हल की गई रिपोर्ट में किसी प्राकृतिक व्यक्ति का वास्तविक स्वामी के रूप में नाम नहीं है, वह Shareholders के रूप में दिया और बिल किया जाता है।

संस्करण। Shareholders और UBO endpoint केवल /v3/ पर उपलब्ध हैं। स्टैंडअलोन खोज शुल्क /v2/kyb/search/ पर भी लागू होता है; प्रोफ़ाइल प्राप्त करने का शुल्क अलग से लिया जाता है।

स्वामित्व स्थिति

registry_ownership_status बताता है कि शेयरधारक या UBO अनुरोध के स्वामित्व वाले हिस्से के साथ क्या हुआ।

मान	अर्थ
`not_requested`	यह कॉल एक Lite पुनर्प्राप्ति थी, इसलिए स्वामित्व का अनुरोध नहीं किया गया।
`delivered`	रजिस्ट्री ने स्वामित्व डेटा दिया है, और `registry_tier_delivered` में दिया गया स्तर वही है जिसका आपसे शुल्क लिया जाता है।
`not_held`	स्वामित्व रजिस्ट्री ने उत्तर दिया है और इस कंपनी को अपनी सूची में नहीं रखती, इसलिए उसके पास देने के लिए कोई स्वामित्व रिकॉर्ड नहीं है। कंपनी देश के किसी दूसरे रजिस्ट्री स्रोत में मिली थी। इसके बजाय Lite प्रोफ़ाइल दी जाती है और उसी का शुल्क लिया जाता है, और `registry_data.ownership_error: "company_not_found"` दिया जाता है।
`unavailable`	स्वामित्व डेटा किसी और कारण से नहीं दिया गया: रजिस्ट्री के रिकॉर्ड में कोई मालिक दर्ज नहीं है, या रजिस्ट्री ने स्वामित्व वाला भाग बिल्कुल नहीं लौटाया, या उससे पूछा ही नहीं जा सका। `registry_data.ownership_error` बताता है कि कारण कौन-सा है। इसके बजाय Lite प्रोफ़ाइल दी जाती है और उसी का शुल्क लिया जाता है।
`pending`	स्वामित्व वाले भाग को अभी तक रजिस्ट्री से नहीं लाया गया है। तब तक कोई शुल्क नहीं लिया जाता और `registry_tier_delivered` `null` रहता है।

not_held और unavailable दोनों को Lite के रूप में दिया और बिल किया जाता है, लेकिन ये एक ही निष्कर्ष नहीं हैं। not_held का मतलब है कि स्वामित्व स्रोत इस कंपनी को कवर नहीं करता, यानी कवरेज में कमी है। unavailable का मतलब है कि डेटा दिया ही नहीं गया, जो किसी आउटेज के कारण हो सकता है या ऐसे भाग के कारण जिसे रजिस्ट्री ने खाली छोड़ा। कारण registry_data.ownership_error बताता है। जो चयन पहले इसलिए unavailable बताते थे क्योंकि स्वामित्व रजिस्ट्री ने कंपनी को सूची में नहीं रखा था, अब वे not_held बताते हैं। यदि आप स्थिति के आधार पर शाखा बनाते हैं, तो दोनों को एक ही Lite डिलीवरी मानें। इसके दो मान अलग-अलग बातें बताते हैं और उन्हें एक ही निष्कर्ष नहीं माना जाना चाहिए:

`ownership_error`	अर्थ
`no_owners_on_record`	रजिस्ट्री ने स्वामित्व वाला भाग दिया है और उसमें कोई मालिक नहीं है। उस रजिस्ट्री में कंपनी का कैप टेबल दर्ज नहीं है।
`ownership_section_unavailable`	रजिस्ट्री ने स्वामित्व वाला भाग नहीं लौटाया, इसलिए उसके लिए कुछ भी नहीं दिया गया। सूची गायब है, खाली नहीं है, और इससे यह पता नहीं चलता कि कंपनी का मालिक कौन है।

जो भाग रजिस्ट्री ने नहीं लौटाया, वह registry_data.section_errors के अंतर्गत संरचित रूप से भी दर्ज होता है। यह उस सेक्शन के नाम से जुड़ा होता है (officers, shareholders, group_structure) और उस स्थिति के साथ जो रजिस्ट्री ने उत्तर में दी:

{
  "section_errors": {
    "shareholders": {
      "status_code": 404
    }
  }
}

section_errors वह बताता है जो उत्तर आपके पास है, उसके पीछे का इतिहास नहीं। जो भाग पहले अनुरोध पर नहीं लौटाया गया और बाद के किसी चरण में दिया गया (नीचे असिंक्रोनस पुनर्प्राप्ति देखें), उसकी प्रविष्टि हट जाती है। इसलिए registry_ownership_status, ownership_error और section_errors हमेशा मेल खाते हैं: delivered वाले भाग की कोई प्रविष्टि नहीं होती, और shareholders के लिए no_owners_on_record के साथ कभी कोई प्रविष्टि नहीं होती। कोई भाग आंशिक रूप से भी नहीं दिया जाता। यदि रजिस्ट्री किसी सूची का पहला पेज देती है और बाद का कोई पेज नहीं दे पाती, तो उस प्रयास में पुनर्प्राप्ति पूरी नहीं मानी जाती। pending पुनर्प्राप्ति अगले चक्र में फिर से की जाती है, और नया अनुरोध रजिस्ट्री-अनुपलब्ध त्रुटि के साथ उत्तर पाता है। इसलिए दी गई officers या शेयरधारकों की सूची हमेशा वह पूरी सूची होती है जो रजिस्ट्री के पास है। section_errors में सूचीबद्ध भाग को ऐसा डेटा मानें जो कभी दिया ही नहीं गया, खाली परिणाम नहीं। section_errors में प्रविष्टि के साथ आने वाली खाली officers या शेयरधारक सूची कंपनी के बारे में कुछ नहीं कहती।

असिंक्रोनस रूप से प्राप्त स्वामित्व

कुछ रजिस्ट्रियों से मांग पर पूछताछ की जाती है: जिस कंपनी के बारे में स्रोत से पहली बार पूछा जाता है, उसके लिए पहला अनुरोध डेटा लाए जाने के दौरान कोई स्वामित्व भाग नहीं लौटाता, और डेटा कुछ मिनटों में आ जाता है। इसे “इस पर कोई स्वामित्व रिकॉर्ड नहीं है” मानने से उस कंपनी को कम आंका जाएगा जिसके पास सचमुच शेयरधारक हैं, इसलिए अनुरोध इसके बजाय pending लौटाता है। जब पुनर्प्राप्ति pending होती है, तो fetch_status भी pending होता है और उत्तर की स्थिति 202 Accepted होती है। Didit उस भाग के लिए स्वयं पुनः प्रयास करता है और आपकी ओर से किसी और कॉल के बिना पुनर्प्राप्ति पूरी करता है:

जैसे ही स्वामित्व डेटा आता है, शेयरधारक और वास्तविक स्वामी सहेजी गई जांच में दिखने लगते हैं, registry_tier_delivered वह स्तर बन जाता है जो दिया गया था, और उस स्तर के अनुसार शुल्क लिया जाता है;
यदि पुनः प्रयास की अवधि समाप्त होने तक भाग अब भी खाली है, तो स्थिति unavailable हो जाती है और अनुरोध Lite के रूप में दिया और बिल किया जाता है।

request_id रखें और registry_checks[0].company.fetch_status के resolved होने तक GET /v3/session/{request_id}/decision/ को लगातार जाँचते रहें। जब तक अनुरोध pending है, पुनर्प्राप्ति का अनुरोध दोबारा न भेजें: हर नया POST एक अलग अनुरोध है और उसका अलग से शुल्क लगता है। उम्मीदवार कंपनियां खोजने के लिए POST /v3/kyb/search/ का उपयोग करें। खोज कोई सहेजी गई जांच नहीं बनाती। खोज का tier इनपुट वह चेन चुनता है जिसमें खोज होती है, देखें खोज स्तर। रजिस्ट्री खोजों में लगभग 90 सेकंड लग सकते हैं। जब आप चाहते हैं कि Didit तुरंत लौट आए और उम्मीदवार तैयार होते ही आपके URL को सूचित करे, तो webhook_url भेजें। खोज कॉलबैक जानबूझकर अहस्ताक्षरित है, इसलिए इस हल्की सूचना के लिए आपको कोई साझा सीक्रेट कॉन्फ़िगर करने की ज़रूरत नहीं है। लौटाए गए kyb_response_id के साथ POST /v3/kyb/select/, POST /v3/kyb/shareholders/ या POST /v3/kyb/ubo/ का उपयोग करें और जिस स्तर की आपको ज़रूरत है उस पर प्रोफ़ाइल प्राप्त करें। पुनर्प्राप्ति का शुल्क लगता है और परिणाम Business Console में Manual Check के रूप में सहेजा जाता है।

सामान्य प्रवाह

कंपनी के नाम, पंजीकरण संख्या और देश से खोजें, उस tier पर जिसे आप खरीदना चाहते हैं (basic डिफ़ॉल्ट Lite चेन है; shareholders और ubo उस स्तर की चेन में खोजते हैं)।
यदि search_resolved=false है, तो पोल करने के बजाय वैकल्पिक webhook_url कॉलबैक की प्रतीक्षा करें।
लौटाए गए उम्मीदवार अपने ऑपरेटर या ग्राहक को दिखाएं।
जिस स्तर की आपको ज़रूरत है उस पर मेल खाने वाला kyb_response_id प्राप्त करें (Lite के लिए select, shareholders या ubo)।
लौटाया गया request_id सहेजें और उसका उपयोग करके सहेजा गया व्यवसाय सत्यापन परिणाम प्राप्त करें।

खोज कॉलबैक

जब प्रदाता Didit को बताता है कि खोज पूरी हो गई है, तब Didit आपके webhook_url पर एक POST अनुरोध भेजता है:

{
  "event_id": "7f5a1c93-6a44-4f0e-9f2b-3d8a1c6f2e91",
  "event_type": "kyb.registry_search.resolved",
  "request_id": "b5ef9df5-bd9e-4d61-bbe5-5eb7a8fb6f85",
  "vendor_data": "business-123",
  "metadata": {
    "source": "onboarding"
  },
  "search_status": "resolved",
  "search_resolved": true,
  "kyb_registry": {
    "companies": [
      {
        "kyb_response_id": "kyb_resp_123",
        "name": "TESCO PLC",
        "registration_number": "00445790",
        "status": "active",
        "type": "Public Limited Company",
        "registered_address": "Tesco House, Shire Park, Kestrel Way, Welwyn Garden City, AL7 1GA",
        "risk_level": null,
        "fetch_status": "pending"
      }
    ],
    "pagination": {
      "total": 1,
      "page": 1,
      "per_page": 25
    },
    "search_status": "resolved",
    "search_resolved": true
  },
  "timestamp": 1767225600,
  "created_at": 1767225600
}

कॉलबैक को एक डिलीवरी सूचना मानें। लौटाए गए kyb_response_id के साथ POST /v3/kyb/select/, POST /v3/kyb/shareholders/ या POST /v3/kyb/ubo/ को कॉल करें, ताकि शुल्क-योग्य रजिस्ट्री प्रोफ़ाइल प्राप्त की जा सके।

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

​एंडपॉइंट और बिलिंग

​स्वामित्व स्थिति

​असिंक्रोनस रूप से प्राप्त स्वामित्व

​सामान्य प्रवाह

​खोज कॉलबैक

एंडपॉइंट और बिलिंग

स्वामित्व स्थिति

असिंक्रोनस रूप से प्राप्त स्वामित्व

सामान्य प्रवाह

खोज कॉलबैक