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

> صحّح حقول KYC أو إثبات العنوان أو KYB المستخرجة بـ OCR في Didit. ثلاث نقاط نهاية PATCH، تحديثات جزئية، تُطلق 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) أحيانًا في قراءة هوية أو فاتورة خدمات أو مدخل في سجل الشركات. يوفّر Didit ثلاثة endpoint من نوع PATCH يمكنك استدعاؤها لتصحيح البيانات المستخرجة دون إعادة تشغيل عملية التحقق كاملة.| endpoint | استخدمها عندما |
| - | - |
| [`PATCH /v3/session/{id}/update-data/`](#تحديث-بيانات-هوية-kyc) | تصحيح القيم المستخرجة من وثيقة الهوية في جلسة **التحقق من المستخدمين (KYC)** |
| [`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 الخاص بالعميل أو ترويسة تفويض المستخدم، وترسل جميعها webhook بالحدث `data.updated` عند النجاح، حتى يبقى نظامك والتحليلات اللاحقة متزامنين.## المتطلبات المشتركة- **التفويض**: مفتاح API الخاص بالعميل (بالترويسة القياسية `x-api-key` أو `Authorization` بصيغة bearer)، أو رمز مصادقة المستخدم.
- **الصلاحية**:
  * KYC وPOA: `write:sessions`
  * شركة KYB وطرف الأشخاص الرئيسيين: `write:businesses`
- **حالة الجلسة** (لـ KYC وPOA فقط): يجب أن تكون إحدى القيم `APPROVED` أو `DECLINED` أو `IN_REVIEW` أو `KYC_EXPIRED`. لا يمكن تعديل الجلسات التي لم تصل بعد إلى حالة قابلة للمراجعة. تحديثات شركة KYB لا تخضع لشرط على الحالة.
- **يجب أن يكون سجل الميزة موجودًا**: لا يمكنك تعديل حقول KYC إلا إذا كانت الجلسة قد سجّلت ميزة KYC، ولا تعديل حقول POA إلا إذا كانت قد سجّلت ميزة POA، ولا تعديل بيانات شركة KYB إلا إذا كانت الجلسة تتضمن فحص سجل.
- **التحديثات الجزئية**: لا يتغير إلا الحقول التي تُرسلها. أغفل الحقل لإبقائه كما هو. أرسل `null` لمسح مفتاح من `extra_fields`.
- **webhook**: عند نجاح التحديث يُطلق الحدث `data.updated` مع `session_kind: "user"` أو `"business"`، ويسجّل سجل تدقيق الجلسة الحقول المحددة التي تغيّرت ومن غيّرها.## تحديث بيانات هوية KYC**`PATCH /v3/session/{sessionId}/update-data/`**عدّل أي حقل مستخرج من وثيقة الهوية. يدعم سير عمل متعدد المثيلات يعتمد على المخطط عبر معامل الاستعلام الاختياري `node_id` أو حقل في نص الطلب، لاستهداف سجل KYC محدد عندما تحتوي الجلسة الواحدة على عدة خطوات 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` | حقول إضافية مخصصة من وثيقة الهوية (مثل `blood_group` و`municipality`). أرسل `null` لمفتاح لإزالته. |يقبل `parsed_address` مفاتيح متداخلة محددة فقط: `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" }
  }'
```في سير عمل متعدد المثيلات يعتمد على المخطط، أضف `?node_id=feature_ocr_2` إلى الرابط (أو مرّر `"node_id": "feature_ocr_2"` في الجسم) لاستهداف سجل KYC محدد.## تحديث بيانات إثبات العنوان (POA)**`PATCH /v3/session/{sessionId}/update-poa-data/`**عدّل الحقول المستخرجة من وثيقة إثبات العنوان. تنطبق عليه شروط الحالة نفسها والصلاحية نفسها كتحديثات 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` | عنوان منظّم، بالشكل المتداخل نفسه لـ `parsed_address` في KYC. |
| `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` معاً، فيعكس عرض "المستخرج من السجل" في الكونسول تصحيحاتك. لا يُعدَّل `user_provided_data` (ما أكّده المستخدم النهائي في الصفحة المستضافة). يُسجَّل `last_console_edit_at`، ويُطلق webhook من نوع `data.updated` مع `trigger: "console_registry_edit"`.### المتطلبات- **الصلاحية**: `write:businesses` (تختلف عن صلاحية KYC / POA).
- يجب أن ينتمي `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`. تُسلسَل التواريخ كسلاسل بصيغة ISO 8601 عند دمجها في `registry_data`.### مثال```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 كاملاً، بالبنية نفسها لـ `registry_checks[].company` في [قرار الجلسة](https://docs.didit.me/ar/sessions-api/retrieve-session.md#التحقق-من-الشركات-kyb).## تخطي طرف من الأشخاص الرئيسيين**`PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/`**استثنِ طرفاً من الأشخاص الرئيسيين من التحقق. هذا هو المخرج الاستثنائي لطرف لن يتمكن أبداً من إكمال فحصه. السبب المعتاد هو جلسة فرعية محذوفة: فبمجرد حذف جلسة KYC الفردية المُسنَدة إلى مستفيد حقيقي أو مدير، تتجمد حالتها ولا يمكن حسمها أبداً، فلا يبقى في KYB ما يمكن أن ينقل الطرف خارج الحالة `Awaiting User`. يؤدي تخطي الطرف إلى إخراجه من تجميع الأشخاص الرئيسيين، فيُعاد احتساب الفحص فوراً، ويمكن للجلسة عندئذٍ أن تُحسم فتُقبل أو تُرفض.### المتطلبات- **الصلاحية**: `write:businesses`.
- يجب أن ينتمي `partyUuid` في العنوان إلى `sessionId` المحدد، وإلا ستحصل على 404.
- **غير مقيّد بـ `allow_skip`.** يحدد هذا الإعداد للدور ما يمكن لمقدّم الطلب تخطيه أثناء تعبئة شاشة الأشخاص الرئيسيين في الصفحة المستضافة. أما هذه النقطة فهي تجاوز يملكه المشغّل، لذا تعمل حتى على الأدوار التي لم يكن مقدّم الطلب ليتمكن من تخطيها.### نص الطلب| الحقل | النوع | ملاحظات |
| - | - | - |
| `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 }'
```الاستجابة: الطرف المحدَّث، بالبنية نفسها لعنصر من `key_people_checks[].submitted.parties[]` في [قرار الجلسة](https://docs.didit.me/ar/business-verification/response-schema.md#key_people_checks).يُطلق webhook من نوع `data.updated` مع `trigger: "console_key_people_skip"`.> [!NOTE]
>
> يُعلَّم الطرف الذي حُذفت جلسته الفرعية في حمولة القرار بالقيمة
> `kyc_session_deleted: true` (أو `kyb_sub_session_deleted: true` للأطراف من الشركات)،
> ويُعاد `kyc_session_url` / `kyb_sub_session_url` الخاص به بالقيمة `null` لأن الرابط
> لم يعد يُفتح. حذف جلسة فرعية لا يؤدي، من تلقاء نفسه، إلى قبول الطرف أبداً، إذ ينتقل فحص الأشخاص الرئيسيين
> إلى الحالة `In Review` ليتخذ إنسان القرار.## ماذا يحدث بعد التحديث- **webhook**: يُطلق `data.updated` على الجلسة، ومعه `session_kind` الخاص بالجلسة في الحمولة (`"user"` أو `"business"`). اشترك مرة واحدة على مستوى الوجهة، ووجّه الأحداث حسب `session_kind`.
- **سجل التدقيق**: تسجّل الجلسة بدقة الحقول التي تغيّرت، والقيم السابقة والجديدة، و(لاستدعاءات المصادقة للمستخدم) بريد الفاعل الإلكتروني. تظهر هذه السجلات في تبويب الأحداث في الكونسول.
- **إعادة الترميز الجغرافي للعنوان**: بالنسبة لتحديثات KYC وPOA التي تغيّر `address` أو `poa_address`، يعيد Didit الترميز الجغرافي في الخلفية. تُتجاهل الأخطاء، فلا يفشل التحديث أبداً بسبب مشكلة في الترميز الجغرافي.
- **إعادة تقييم AML**: قد تعيد تحديثات KYC التي تغيّر الاسم أو تاريخ الميلاد أو الجنسية تشغيل فحص AML إذا لم يكن قد انتهى في الجلسة. وتظهر النتائج في قرار الجلسة.## متى لا تستخدم هذه الـ endpoints- **إعادة تشغيل التحقق كاملاً**: إذا كان على العميل إعادة التقاط صورة هويته أو إعادة رفع مستند، فاستخدم [update-status](https://docs.didit.me/ar/sessions-api/update-status.md) لنقل الجلسة إلى `Resubmitted` بدلاً من ذلك.
- **تغيير حقول الملف الشخصي لكيان المستخدم أو الشركة**: استخدم [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/ar/management-api/users/update) أو [`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/ar/management-api/businesses/update)، فهذه الـ endpoints تحدّث بيانات على مستوى الكيان لا على مستوى الجلسة.
- **تعديل تفاصيل الأشخاص الرئيسيين**: لا توجد واجهة API عامة لتعديل اسم الطرف أو أدواره أو ملكيته، إذ تُرسل هذه البيانات عبر الصفحة المستضافة. الحقل الوحيد القابل للتعديل هو `is_skipped` (انظر [تخطي طرف من الأشخاص الرئيسيين](#تخطي-طرف-من-الأشخاص-الرئيسيين)).## الأخطاء| الحالة | المعنى |
| - | - |
| `401` | بيانات الاعتماد مفقودة أو غير صالحة. |
| `403` | المستدعي لا يملك الصلاحية المطلوبة (`write:sessions` أو `write:businesses`). |
| `404` | الجلسة غير موجودة، أو أنها لا تحتوي على السجل الذي تحاول تعديله (لا توجد بيانات KYC، أو POA، أو شركة مطابقة، أو طرف مطابق، أو طرف يتبع جلسة أخرى). |
| `400` | خطأ في التحقق: رمز دولة غير صالح، أو مفتاح غير معروف في `parsed_address`، أو `extra_fields` ليس كائنًا، وغير ذلك. |## الخطوات التالية> [card] [استرجاع الجلسة](https://docs.didit.me/ar/sessions-api/retrieve-session.md)
>
> استرجع القرار الكامل لمعاينة الحقول المحدَّثة.> [card] [تحديث الحالة](https://docs.didit.me/ar/sessions-api/update-status.md)
>
> قبول الجلسة أو رفضها أو إعادة فتحها بعد تصحيح البيانات.> [card] [webhook](https://docs.didit.me/ar/integration/webhooks.md)
>
> اشترك في أحداث `data.updated`.


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