> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Didit का KYB रजिस्ट्री API कंपनी रजिस्ट्री खोजता है; फिर जरूरी स्तर पर कंपनी लाएँ: Lite (select), शेयरधारक या UBO। मूल्य देश के अनुसार।

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

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

डेटा पुनर्प्राप्ति तीन डेटा स्तरों में बेची जाती है। हर स्तर का अपना endpoint है, और मूल्य देश के अनुसार तय होता है ([देश-वार मूल्य](https://docs.didit.me/hi/getting-started/kyb-registry-pricing.md))।

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

`select` ही Lite स्तर है: यही वह endpoint है जिसके लिए एक होस्टेड KYB वर्कफ़्लो Lite स्तर पर रजिस्ट्री जाँच का बिल करता है, और इसका वही अनुबंध बना रहता है जो हमेशा से रहा है। "यूरोप" का अर्थ है EEA, यूनाइटेड किंगडम और स्विट्ज़रलैंड।

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

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

> [!NOTE]
>
> **संस्करण।** 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`) और उस स्थिति के साथ जो रजिस्ट्री ने उत्तर में दी:

```json theme={null}
{
  "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` इनपुट वह चेन चुनता है जिसमें खोज होती है, देखें [खोज स्तर](https://docs.didit.me/hi/standalone-apis/kyb-registry-search.md#खोज-स्तर)।

रजिस्ट्री खोजों में लगभग 90 सेकंड लग सकते हैं। जब आप चाहते हैं कि Didit तुरंत लौट आए और उम्मीदवार तैयार होते ही आपके URL को सूचित करे, तो `webhook_url` भेजें। खोज कॉलबैक जानबूझकर अहस्ताक्षरित है, इसलिए इस हल्की सूचना के लिए आपको कोई साझा सीक्रेट कॉन्फ़िगर करने की ज़रूरत नहीं है।

लौटाए गए `kyb_response_id` के साथ `POST /v3/kyb/select/`, `POST /v3/kyb/shareholders/` या `POST /v3/kyb/ubo/` का उपयोग करें और जिस स्तर की आपको ज़रूरत है उस पर प्रोफ़ाइल प्राप्त करें। पुनर्प्राप्ति का शुल्क लगता है और परिणाम Business Console में Manual Check के रूप में सहेजा जाता है।

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

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

## खोज कॉलबैक

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

```json theme={null}
{
  "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/` को कॉल करें, ताकि शुल्क-योग्य रजिस्ट्री प्रोफ़ाइल प्राप्त की जा सके।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.