उपयोगकर्ता और व्यवसाय सत्यापन

सत्र डेटा अपडेट API: KYC और KYB फ़ील्ड सुधारें

Didit पर मौजूदा सत्रों के OCR डेटा के KYC, पते या KYB फ़ील्ड सुधारें। तीन PATCH endpoints, आंशिक अपडेट, webhook भेजता है। प्रति कॉल भुगतान।

कभी-कभी OCR किसी ID, यूटिलिटी बिल या रजिस्ट्री प्रविष्टि को गलत पढ़ लेता है। Didit तीन PATCH endpoint उपलब्ध कराता है, जिन्हें आप पूरी सत्यापन प्रक्रिया दोबारा चलाए बिना निकाले गए डेटा को सुधारने के लिए कॉल कर सकते हैं।

Endpoint	कब उपयोग करें
`PATCH /v3/session/{id}/update-data/`	उपयोगकर्ता सत्यापन (KYC) सत्र पर ID दस्तावेज़ से निकाले गए मान सुधारें
`PATCH /v3/session/{id}/update-poa-data/`	उपयोगकर्ता सत्यापन (KYC) सत्र पर यूटिलिटी बिल / बैंक स्टेटमेंट / लीज़ समझौते से निकाले गए मान सुधारें
`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`	व्यवसाय सत्यापन (KYB) सत्र पर रजिस्ट्री से निकाले गए फ़ील्ड सुधारें
`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`	जो प्रमुख व्यक्ति पार्टी अब अपनी स्वयं की जाँच पूरी नहीं कर सकती, उसे सत्यापन से छूट दें

चारों endpoints आपकी क्लाइंट API कुंजी या उपयोगकर्ता प्राधिकरण हेडर स्वीकार करते हैं, और सफल होने पर सभी एक data.updated webhook भेजते हैं, ताकि आपका सिस्टम और डाउनस्ट्रीम विश्लेषण सिंक में रहें।

साझा आवश्यकताएँ

प्राधिकरण: क्लाइंट API कुंजी (मानक x-api-key / Authorization bearer) या उपयोगकर्ता token।
विशेषाधिकार:
- KYC और POA: write:sessions
- KYB कंपनी और प्रमुख व्यक्ति पार्टी: write:businesses
सत्र की स्थिति (केवल KYC / POA): इनमें से एक होनी चाहिए: APPROVED, DECLINED, IN_REVIEW, या KYC_EXPIRED। जो सत्र समीक्षा योग्य स्थिति तक नहीं पहुँचे हैं, उन्हें patch नहीं किया जा सकता। KYB कंपनी अपडेट पर कोई स्थिति प्रतिबंध नहीं है।
सुविधा रिकॉर्ड मौजूद होना चाहिए: KYC फ़ील्ड केवल तभी patch कर सकते हैं जब सत्र में KYC कैप्चर किया गया हो, POA फ़ील्ड केवल तभी जब POA कैप्चर किया गया हो, और KYB कंपनी फ़ील्ड केवल तभी जब सत्र में रजिस्ट्री जाँच हो।
आंशिक अपडेट: केवल वही फ़ील्ड बदले जाते हैं जो आप शामिल करते हैं। किसी फ़ील्ड को छोड़ने पर वह जैसा है वैसा ही रहता है। extra_fields की किसी key को हटाने के लिए null भेजें।
Webhooks: सफल अपडेट पर session_kind: "user" या "business" के साथ data.updated भेजा जाता है, और सत्र का audit trail यह दर्ज करता है कि कौन से विशिष्ट फ़ील्ड बदले गए और किसने बदले।

KYC पहचान डेटा अपडेट करें

PATCH /v3/session/{sessionId}/update-data/ ID दस्तावेज़ से निकाला गया कोई भी फ़ील्ड patch करें। यह ग्राफ़-आधारित मल्टी-इंस्टेंस वर्कफ़्लो को सपोर्ट करता है: जब एक सत्र में कई KYC चरण हों, तो वैकल्पिक node_id query parameter या body field के ज़रिए एक विशिष्ट KYC रिकॉर्ड चुनें।

बदलने योग्य फ़ील्ड

फ़ील्ड	टिप्पणियाँ
`document_type`	ISO दस्तावेज़ कोड: `P` (पासपोर्ट), `ID`, `DL`, `RP`।
`document_number`	छपा हुआ दस्तावेज़ नंबर।
`personal_number`	व्यक्तिगत / कर पहचान नंबर, जब दस्तावेज़ पर छपा हो।
`date_of_birth`	ISO 8601 तारीख।
`date_of_issue` / `expiration_date`	ISO 8601 तारीखें।
`issuing_state`	जारीकर्ता देश, ISO 3166-1 alpha-3।
`first_name` / `last_name`	`full_name` इन्हीं दोनों से अपने-आप फिर से गणना होता है।
`gender`	`M`, `F`, या `X`, जब मौजूद हो।
`nationality`	मुक्त-पाठ।
`marital_status`	मुक्त-पाठ।
`place_of_birth`	मुक्त-पाठ।
`address`	दस्तावेज़ से मुक्त-पाठ पता। इससे री-जियोकोडिंग शुरू होती है।
`parsed_address`	संरचित पता: नीचे दी गई नेस्टेड संरचना देखें।
`extra_fields`	ID से अतिरिक्त मनमाने फ़ील्ड (जैसे `blood_group`, `municipality`)। किसी key को हटाने के लिए `null` भेजें।

parsed_address केवल ये nested keys स्वीकार करता है: address_type, city, region, street_1, street_2, postal_code, country (ISO 3166-1 alpha-2)।

उदाहरण

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'

मल्टी-इंस्टेंस ग्राफ़-आधारित वर्कफ़्लो के लिए, URL में ?node_id=feature_ocr_2 जोड़ें (या body में "node_id": "feature_ocr_2" भेजें) ताकि एक विशिष्ट KYC रिकॉर्ड चुना जा सके।

पते का प्रमाण (POA) डेटा अपडेट करें

PATCH /v3/session/{sessionId}/update-poa-data/ पते के प्रमाण वाले दस्तावेज़ से निकाले गए फ़ील्ड patch करें। इसके लिए वही सत्र स्थिति प्रतिबंध और अनुमति लागू होती है जो KYC अपडेट पर है। यह मल्टी-इंस्टेंस वर्कफ़्लो के लिए node_id भी स्वीकार करता है।

बदलने योग्य फ़ील्ड

फ़ील्ड	टिप्पणियाँ
`issuing_state`	दस्तावेज़ का जारीकर्ता देश, ISO 3166-1 alpha-3।
`document_type`	जैसे `utility_bill`, `bank_statement`, `lease_agreement`।
`document_language`	दस्तावेज़ की भाषा का ISO 639-1 कोड।
`issuer`	यूटिलिटी कंपनी, बैंक, मकान मालिक, आदि।
`issue_date`	ISO 8601 तारीख।
`poa_address`	दस्तावेज़ पर छपा पता (मुक्त-पाठ)। इससे री-जियोकोडिंग शुरू होती है।
`name_on_document`	दस्तावेज़ पर छपा पूरा नाम।
`poa_parsed_address`	संरचित पता: KYC `parsed_address` जैसी ही नेस्टेड संरचना।
`extra_fields`	दस्तावेज़-विशिष्ट फ़ील्ड: बैंक विवरण (`bank_account_number`, `bank_iban`, `bank_sort_code`, `bank_routing_number`, `bank_swift_bic`, `bank_branch_name`, `bank_branch_address`), `document_phone_number`, `additional_names` (सूची या `null`)।

उदाहरण

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-poa-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "utility_bill",
    "issuer": "Iberdrola",
    "issue_date": "2026-03-15",
    "name_on_document": "Jane Doe",
    "poa_parsed_address": {
      "street_1": "Calle Mayor 10",
      "city": "Madrid",
      "postal_code": "28013",
      "country": "ES"
    }
  }'

KYB कंपनी डेटा अपडेट करें

PATCH /v3/session/{sessionId}/kyb/{companyUuid}/update-data/ KYB कंपनी में रजिस्ट्री से निकाले गए फ़ील्ड्स में सुधार करें। यह endpoint कैनोनिकल कंपनी कॉलम और registry_data दोनों को संपादित करता है, ताकि कंसोल का “Extracted from Registry” व्यू आपके सुधार दिखाए। user_provided_data (जिसकी पुष्टि अंतिम उपयोगकर्ता ने होस्टेड फ़्लो में की थी) में बदलाव नहीं होता। last_console_edit_at सेट किया जाता है, और trigger: "console_registry_edit" के साथ data.updated webhook फ़ायर होता है।

आवश्यकताएँ

विशेषाधिकार - write:businesses (KYC / POA विशेषाधिकार से अलग)।
URL में दिया गया companyUuid दिए गए sessionId से संबंधित होना चाहिए, अन्यथा आपको 404 मिलेगा।
सत्र की स्थिति पर कोई रोक नहीं है। KYB कंपनी डेटा किसी भी समय सुधारा जा सकता है।

परिवर्तनीय फ़ील्ड्स

फ़ील्ड	नोट्स
`company_name`	कानूनी नाम।
`registration_number`	आधिकारिक पंजीकरण संख्या।
`country_code`	निगमन का देश, ISO 3166-1 alpha-3।
`incorporation_date` / `registration_date` / `dissolution_date`	ISO 8601 तिथियाँ।
`tax_number`	कर पहचान संख्या।
`legal_address`	`registered_address` का उपनाम, यह कैनोनिकल `registered_address` कॉलम में जाता है।
`company_type`	Ltd / LLC / PLC / SA / GmbH / SL आदि।
`registry_status`	`active`, `dissolved`, `struck_off`, `inactive` आदि।
`verification_status`	`verified`, `failed`, `unknown`।
`alternative_names`	ट्रेड नाम, पूर्व नाम, DBA।
`nature_of_business`	संक्षिप्त विवरण।
`registered_capital`	अधिकृत / जारी पूंजी।
`website`, `email`, `phone`	संपर्क विवरण।
`legal_entity_identifier`	LEI।
`location_of_registration`	शहर / उप-क्षेत्र।
`control_scheme`	जब रजिस्ट्री इसे उपलब्ध कराए, तो शासन योजना।

आप जो फ़ील्ड छोड़ते हैं, वह अपरिवर्तित रहता है। आप जो फ़ील्ड भेजते हैं, वह (यदि कैनोनिकल कॉलम मौजूद है) उस कॉलम में लिखा जाता है और registry_data में मर्ज किया जाता है। registry_data में मर्ज करते समय तिथियाँ ISO 8601 स्ट्रिंग के रूप में सीरियलाइज़ की जाती हैं।

उदाहरण

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/f7a9c1b2-4e6d.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Corporation Limited",
    "registration_number": "12345678",
    "registry_status": "active",
    "legal_address": "1 Main Street, London EC1A 1AA, United Kingdom",
    "alternative_names": "Acme Ltd, Acme Group"
  }'

रिस्पॉन्स: पूरा KYB कंपनी ऑब्जेक्ट, जिसका आकार सत्र निर्णय में registry_checks[].company जैसा ही है।

प्रमुख व्यक्ति पक्ष को छोड़ें

PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/ किसी प्रमुख व्यक्ति पक्ष को सत्यापन से छूट दें। यह उस पक्ष के लिए आपात मार्ग है जो अपनी जाँच कभी पूरी नहीं कर सकता। आम कारण हटाया गया child session होता है: एक बार UBO या निदेशक को सौंपा गया व्यक्तिगत KYC हटा दिया जाए, तो उसकी स्थिति स्थिर हो जाती है और वह कभी तय नहीं हो सकती। इसलिए KYB के पास ऐसा कुछ नहीं बचता जो उसे Awaiting User से बाहर निकाल सके। पक्ष को छोड़ने पर वह प्रमुख व्यक्ति एकत्रीकरण से बाहर हो जाता है, जाँच तुरंत पुनः गणना होती है, और सत्र का निपटारा होकर वह स्वीकृत या अस्वीकृत हो सकता है।

आवश्यकताएँ

विशेषाधिकार - write:businesses।
URL में दिया गया partyUuid दिए गए sessionId से संबंधित होना चाहिए, अन्यथा आपको 404 मिलेगा।
allow_skip से नियंत्रित नहीं। वह भूमिका सेटिंग सीमित करती है कि आवेदक होस्टेड प्रमुख व्यक्ति स्क्रीन भरते समय क्या छोड़ सकता है। यह endpoint ऑपरेटर का ओवरराइड है, इसलिए यह उन भूमिकाओं पर भी काम करता है जिन्हें आवेदक नहीं छोड़ सकता था।

बॉडी

फ़ील्ड	प्रकार	नोट्स
`is_skipped`	boolean	`true` पक्ष को छूट देता है; `false` उसे दायरे में वापस लाता है और जाँच फिर उसके पूरा होने का इंतज़ार करती है।

requires_verification जानबूझकर अपरिवर्तित छोड़ा जाता है, इसलिए ओवरराइड किए गए पक्ष में requires_verification: true और is_skipped: true दिखता है। इससे रिकॉर्ड में यह दिखता रहता है कि नियमों ने जाँच माँगी थी।

उदाहरण

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/parties/0a3f1e2c-7c2f.../" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_skipped": true }'

रिस्पॉन्स: अपडेट किया गया पक्ष, जिसका आकार सत्र निर्णय में key_people_checks[].submitted.parties[] की एक प्रविष्टि जैसा ही है। trigger: "console_key_people_skip" के साथ data.updated webhook फ़ायर होता है।

जिस पक्ष का child session हटाया गया था, उसे निर्णय payload में kyc_session_deleted: true (या कॉर्पोरेट पक्षों के लिए kyb_sub_session_deleted: true) से चिह्नित किया जाता है, और उसका kyc_session_url / kyb_sub_session_url null लौटाया जाता है, क्योंकि लिंक अब काम नहीं करता। child session हटाने से पक्ष अपने आप स्वीकृत नहीं होता। प्रमुख व्यक्ति जाँच In Review पर आ जाती है, ताकि निर्णय कोई व्यक्ति ले।

अपडेट के बाद क्या होता है

webhook - सत्र पर data.updated फ़ायर होता है, और payload में सत्र का session_kind ("user" या "business") होता है। गंतव्य स्तर पर एक बार सदस्यता लें और session_kind के आधार पर रूट करें।
ऑडिट रिकॉर्ड - सत्र में ठीक-ठीक यह दर्ज होता है कि कौन से फ़ील्ड बदले, पिछले और नए मान क्या थे, और (उपयोगकर्ता-प्रमाणीकरण कॉल के लिए) अभिकर्ता का ईमेल। यह कंसोल के Events टैब में दिखता है।
पता पुनः जियोकोडिंग - KYC और POA अपडेट में जब address / poa_address बदलते हैं, तो Didit पृष्ठभूमि में जियोकोडिंग दोबारा चलाता है। विफलताएँ अनदेखी की जाती हैं, ताकि जियोकोडिंग समस्या से अपडेट कभी विफल न हो।
AML पुनर्मूल्यांकन - जिन KYC अपडेट में नाम / जन्म तिथि / राष्ट्रीयता बदलते हैं, वे AML स्क्रीनिंग फिर से शुरू कर सकते हैं, यदि सत्र पर AML पूरा नहीं हुआ था। परिणाम सत्र निर्णय पर दिखते हैं।

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

पूरी सत्यापन प्रक्रिया दोबारा चलाना - यदि ग्राहक को अपनी ID की फ़ोटो दोबारा लेनी है या दस्तावेज़ फिर से अपलोड करना है, तो सत्र को Resubmitted पर ले जाने के लिए update-status का उपयोग करें।
User या Business entity के प्रोफ़ाइल फ़ील्ड बदलना - PATCH /v3/users/{vendor_data}/ या PATCH /v3/businesses/{vendor_data}/ का उपयोग करें। ये endpoints entity-स्तर का डेटा अपडेट करते हैं, सत्र-स्तर का नहीं।
प्रमुख व्यक्ति का विवरण संपादित करना - किसी पक्ष का नाम, भूमिकाएँ या स्वामित्व पैच करने के लिए कोई सार्वजनिक API नहीं है। यह डेटा होस्टेड फ़्लो के माध्यम से जमा किया जाता है। एकमात्र पैच योग्य फ़ील्ड is_skipped है (देखें प्रमुख व्यक्ति पक्ष को छोड़ें)।

त्रुटियाँ

स्टेटस	अर्थ
`401`	क्रेडेंशियल गायब हैं या अमान्य हैं।
`403`	कॉल करने वाले के पास आवश्यक विशेषाधिकार नहीं है (`write:sessions` या `write:businesses`)।
`404`	सत्र नहीं मिला, या सत्र में वह रिकॉर्ड नहीं है जिसे आप पैच कर रहे हैं (कोई KYC नहीं, कोई POA नहीं, कोई मिलती-जुलती कंपनी नहीं, कोई मिलता-जुलता पक्ष नहीं, या ऐसा पक्ष जो किसी दूसरे सत्र से जुड़ा है)।
`400`	सत्यापन त्रुटि: अमान्य देश कोड, अज्ञात `parsed_address` कुंजी, `extra_fields` का ऑब्जेक्ट नहीं होना, आदि।

आगे के चरण

सत्र प्राप्त करें

अपडेट किए गए फ़ील्ड देखने के लिए पूरा निर्णय प्राप्त करें।

स्टेटस अपडेट करें

डेटा सुधार के बाद सत्र को स्वीकृत करें, अस्वीकृत करें, या फिर से खोलें।

webhook

data.updated webhook इवेंट की सदस्यता लें।

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

​साझा आवश्यकताएँ

​KYC पहचान डेटा अपडेट करें

​बदलने योग्य फ़ील्ड

​उदाहरण

​पते का प्रमाण (POA) डेटा अपडेट करें

​बदलने योग्य फ़ील्ड

​उदाहरण

​KYB कंपनी डेटा अपडेट करें

​आवश्यकताएँ

​परिवर्तनीय फ़ील्ड्स

​उदाहरण

​प्रमुख व्यक्ति पक्ष को छोड़ें

​आवश्यकताएँ

​बॉडी

​उदाहरण

​अपडेट के बाद क्या होता है

​इन endpoints का उपयोग कब न करें

​त्रुटियाँ

​आगे के चरण

सत्र प्राप्त करें

स्टेटस अपडेट करें

webhook

साझा आवश्यकताएँ

KYC पहचान डेटा अपडेट करें

बदलने योग्य फ़ील्ड

उदाहरण

पते का प्रमाण (POA) डेटा अपडेट करें

बदलने योग्य फ़ील्ड

उदाहरण

KYB कंपनी डेटा अपडेट करें

आवश्यकताएँ

परिवर्तनीय फ़ील्ड्स

उदाहरण

प्रमुख व्यक्ति पक्ष को छोड़ें

आवश्यकताएँ

बॉडी

उदाहरण

अपडेट के बाद क्या होता है

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

त्रुटियाँ

आगे के चरण