> ## 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.

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

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



सत्र डेटा अपडेट करने का प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\`Correct OCR-extracted fields on a finished Didit verification session — KYC identity, Proof of Address, or KYB company data.

There are THREE separate PATCH endpoints. Pick the one that matches the feature record you need to fix.

1\) Update KYC identity data
PATCH https://verification.didit.me/v3/session/{session_id}/update-data/
\- Auth: x-api-key (client) or user-auth token. Privilege: write:sessions.
\- Session status must be one of Approved, Declined, In Review, Kyc Expired.
\- Session must have a captured KYC feature record.
\- Optional query / body param node_id targets a specific KYC instance in multi-step workflows (e.g. node_id=feature_ocr_2).
\- Mutable fields: document_type ("P", "ID", "DL", "RP"), document_number, personal_number, date_of_birth (ISO date), date_of_issue, expiration_date, issuing_state (ISO 3166-1 alpha-3), first_name, last_name (full_name is auto-recomputed), gender ("M"|"F"|"X"), nationality, marital_status, place_of_birth, address (free-text — triggers re-geocoding), parsed_address (nested: address_type, city, region, street_1, street_2, postal_code, country [ISO 3166-1 alpha-2]), extra_fields (object — send null on a key to remove it).

2\) Update Proof of Address (POA) data
PATCH https://verification.didit.me/v3/session/{session_id}/update-poa-data/
\- Same auth + privilege + status gate as KYC.
\- Session must have a captured POA record. node_id supported.
\- Mutable fields: issuing_state (ISO-3), document_type ("utility_bill" | "bank_statement" | "lease_agreement"), document_language (ISO 639-1), issuer, issue_date (ISO date), poa_address (free-text — triggers re-geocoding), name_on_document, poa_parsed_address (same nested shape as 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).

3\) Update KYB company data
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/{company_uuid}/update-data/
\- Privilege: write:businesses (NOT write:sessions).
\- No status gate — KYB company data can be corrected at any time.
\- company_uuid must belong to that session_id (else 404).
\- Mutable fields: company_name, registration_number, country_code (ISO-3), incorporation_date / registration_date / dissolution_date, tax_number, legal_address (lands on registered_address), company_type, registry_status ("active" | "dissolved" | "struck_off" | "inactive" | ...), verification_status ("verified" | "failed" | "unknown"), alternative_names, nature_of_business, registered_capital, website, email, phone, legal_entity_identifier, location_of_registration, control_scheme.
\- Edits BOTH the canonical column and registry_data. user_provided_data is never touched.

4\) Skip (or re-require) a Key People party
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/parties/{party_uuid}/
\- Privilege: write:businesses.
\- Body: { "is_skipped": true } to exempt the party, { "is_skipped": false } to put it back in scope.
\- party_uuid must belong to that session_id (else 404).
\- Use it when a party can no longer finish its own check - most often because the linked individual KYC session was deleted - and the KYB is stuck in Awaiting User with nothing left that can move it.
\- Independent of the role's allow_skip setting: that flag limits what the applicant may skip in the hosted flow, not what you may override.
\- requires_verification is left untouched, so the override stays visible as requires_verification: true + is_skipped: true.
\- Recomputes the Key People check and the parent session status immediately, and fires data.updated with trigger: "console_key_people_skip".

Common contract for all four:
\- PATCH semantics — only fields you send are updated. Omit a field to leave it as-is. Send null on an extra_fields key to remove it.
\- A successful update fires a data.updated webhook (with session_kind: "user" or "business"). KYB company updates carry trigger: "console_registry_edit".
\- The audit trail records changed fields, previous + new values, and (for user-auth) the actor email.

KYC curl example:
curl -X PATCH "https://verification.didit.me/v3/session/<SESSION_ID>/update-data/" \
-H "x-api-key: <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" }
}'

Response: the updated record (KYC / POA / KYB company shape — same fields as in the session decision).

Failure modes:
\- 401 — missing or invalid credentials.
\- 403 — { "detail": "You do not have permission to perform this action." } — caller lacks write:sessions (KYC/POA) or write:businesses (KYB company).
\- 404 — { "detail": "Not found." } — session, node_id, or company_uuid not found; OR the session does not carry the feature record you are patching (no KYC / no POA / no matching company).
\- 400 — validation error: invalid country code, unknown parsed_address key, extra_fields not an object, etc. Returned as { "<field>": ["..."] }.

When NOT to use these endpoints:
\- To ask the user to retake the document → use PATCH /v3/session/{id}/update-status/ with new_status: "Resubmitted" (see /sessions-api/update-status).
\- To change entity-level data → use /v3/users/{vendor_data}/ or /v3/businesses/{vendor_data}/.
\- To edit Key People names / roles / ownership - no public API; that data is submitted through the hosted flow. Only the is_skipped flag is patchable (endpoint 4).

Side effects:
\- Changes to KYC name / DOB / nationality can re-trigger AML if AML was still running.
\- Changes to address / poa_address re-run geocoding asynchronously (failures swallowed — they never fail the update).

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\</pre>



      
      

यहाँ पेस्ट करें

कभी-कभी OCR किसी ID, यूटिलिटी बिल या रजिस्ट्री प्रविष्टि को गलत पढ़ लेता है। Didit तीन PATCH endpoint उपलब्ध कराता है, जिन्हें आप पूरी सत्यापन प्रक्रिया दोबारा चलाए बिना निकाले गए डेटा को सुधारने के लिए कॉल कर सकते हैं।| Endpoint | कब उपयोग करें |
| - | - |
| [`PATCH /v3/session/{id}/update-data/`](#kyc-पहचान-डेटा-अपडेट-करें) | **उपयोगकर्ता सत्यापन (KYC)** सत्र पर ID दस्तावेज़ से निकाले गए मान सुधारें |
| [`PATCH /v3/session/{id}/update-poa-data/`](#पते-का-प्रमाण-poa-डेटा-अपडेट-करें) | **उपयोगकर्ता सत्यापन (KYC)** सत्र पर यूटिलिटी बिल / बैंक स्टेटमेंट / लीज़ समझौते से निकाले गए मान सुधारें |
| [`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`](#kyb-कंपनी-डेटा-अपडेट-करें) | **व्यवसाय सत्यापन (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**)।### उदाहरण```bash theme={null}
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`)। |### उदाहरण```bash theme={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 स्ट्रिंग के रूप में सीरियलाइज़ की जाती हैं।### उदाहरण```bash theme={null}
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 कंपनी ऑब्जेक्ट, जिसका आकार [सत्र निर्णय](https://docs.didit.me/hi/sessions-api/retrieve-session.md#व्यवसाय-सत्यापन-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` दिखता है। इससे रिकॉर्ड में यह दिखता रहता है कि नियमों ने जाँच माँगी थी।### उदाहरण```bash theme={null}
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 }'
```रिस्पॉन्स: अपडेट किया गया पक्ष, जिसका आकार [सत्र निर्णय](https://docs.didit.me/hi/business-verification/response-schema.md#key_people_checks) में `key_people_checks[].submitted.parties[]` की एक प्रविष्टि जैसा ही है।`trigger: "console_key_people_skip"` के साथ `data.updated` webhook फ़ायर होता है।> [!NOTE]
>
> जिस पक्ष का 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](https://docs.didit.me/hi/sessions-api/update-status.md) का उपयोग करें।
- **User या Business entity के प्रोफ़ाइल फ़ील्ड बदलना** - [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/hi/management-api/users/update) या [`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/hi/management-api/businesses/update) का उपयोग करें। ये endpoints entity-स्तर का डेटा अपडेट करते हैं, सत्र-स्तर का नहीं।
- **प्रमुख व्यक्ति का विवरण संपादित करना** - किसी पक्ष का नाम, भूमिकाएँ या स्वामित्व पैच करने के लिए कोई सार्वजनिक API नहीं है। यह डेटा होस्टेड फ़्लो के माध्यम से जमा किया जाता है। एकमात्र पैच योग्य फ़ील्ड `is_skipped` है (देखें [प्रमुख व्यक्ति पक्ष को छोड़ें](#प्रमुख-व्यक्ति-पक्ष-को-छोड़ें))।## त्रुटियाँ| स्टेटस | अर्थ |
| - | - |
| `401` | क्रेडेंशियल गायब हैं या अमान्य हैं। |
| `403` | कॉल करने वाले के पास आवश्यक विशेषाधिकार नहीं है (`write:sessions` या `write:businesses`)। |
| `404` | सत्र नहीं मिला, या सत्र में वह रिकॉर्ड नहीं है जिसे आप पैच कर रहे हैं (कोई KYC नहीं, कोई POA नहीं, कोई मिलती-जुलती कंपनी नहीं, कोई मिलता-जुलता पक्ष नहीं, या ऐसा पक्ष जो किसी दूसरे सत्र से जुड़ा है)। |
| `400` | सत्यापन त्रुटि: अमान्य देश कोड, अज्ञात `parsed_address` कुंजी, `extra_fields` का ऑब्जेक्ट नहीं होना, आदि। |## आगे के चरण> [card] [सत्र प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md)
>
> अपडेट किए गए फ़ील्ड देखने के लिए पूरा निर्णय प्राप्त करें।> [card] [स्टेटस अपडेट करें](https://docs.didit.me/hi/sessions-api/update-status.md)
>
> डेटा सुधार के बाद सत्र को स्वीकृत करें, अस्वीकृत करें, या फिर से खोलें।> [card] [webhook](https://docs.didit.me/hi/integration/webhooks.md)
>
> `data.updated` webhook इवेंट की सदस्यता लें।


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