> ## 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, POA и KYB из реестра, извлечённые OCR, в существующих сессиях Didit. Три PATCH endpoint, частичные обновления, 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 предоставляет три PATCH endpoint’а, с помощью которых можно исправить извлечённые данные без повторного запуска всей верификации.| 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}/`](#пропуск-стороны-key-people) | Освободить участника типа «ключевые лица» от верификации, если он больше не может пройти собственную проверку |Все четыре endpoint’а принимают ваш **клиентский 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`.
- **Вебхуки**: успешное обновление отправляет `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` к URL (или передайте `"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`, поэтому представление "Extracted from Registry" в консоли отражает ваши исправления. `user_provided_data` (то, что конечный пользователь подтвердил на размещённой странице) не изменяется. `last_console_edit_at` проставляется, а webhook `data.updated` срабатывает с `trigger: "console_registry_edit"`.### Требования- **Привилегия**: `write:businesses` (отличается от привилегии для KYC и POA).
- `companyUuid` в URL должен принадлежать указанной `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 той же структуры, что `registry_checks[].company` в [решении по сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md#верификация-бизнеса-kyb).## Пропуск стороны Key People**`PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/`**Исключение стороны Key People из верификации: способ обойти проверку для стороны, которая не может завершить собственную проверку. Обычно причина заключается в удалении дочерней сессии. После удаления индивидуальной KYC-сессии, назначенной UBO или директору, её статус фиксируется и уже не изменится, поэтому KYB не может вывести сторону из статуса `Awaiting User`. Пропуск стороны исключает её из агрегации Key People, проверка пересчитывается немедленно, и сессия может завершиться одобрением или отклонением.### Требования- **Привилегия**: `write:businesses`.
- `partyUuid` в URL должен принадлежать указанной `sessionId`, иначе вернётся 404.
- **Не ограничивается `allow_skip`.** Эта настройка роли ограничивает, какие элементы заявитель может пропустить при заполнении размещённого экрана Key People. Данный 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 }'
```Ответ: обновлённая сторона той же структуры, что элемент `key_people_checks[].submitted.parties[]` в [решении по сессии](https://docs.didit.me/ru/business-verification/response-schema.md#key_people_checks).Срабатывает webhook `data.updated` с `trigger: "console_key_people_skip"`.> [!NOTE]
>
> Сторона, дочерняя сессия которой была удалена, помечается в payload решения полем
> `kyc_session_deleted: true` (или `kyb_sub_session_deleted: true` для корпоративных
> сторон), а её `kyc_session_url` / `kyb_sub_session_url` возвращается как
> `null`, поскольку ссылка больше не открывается. Удаление дочерней сессии никогда само
> по себе не одобряет сторону: проверка Key People переходит в `In Review`, чтобы
> решение принял человек.## Что происходит после обновления- **Вебхук**: `data.updated` срабатывает для сессии, а в payload передаётся `session_kind` сессии (`"user"` или `"business"`). Подпишитесь один раз на уровне адреса назначения webhook и выполняйте маршрутизацию по `session_kind`.
- **Журнал аудита**: сессия фиксирует, какие поля изменились, их предыдущие и новые значения, а также (для вызовов с аутентификацией пользователя) адрес e-mail исполнителя. Просмотреть это можно на вкладке Events в консоли.
- **Повторное геокодирование адреса**: для обновлений KYC и POA, которые меняют `address` / `poa_address`, Didit повторно запускает геокодирование в фоновом режиме. Ошибки подавляются, поэтому обновление никогда не завершается ошибкой из-за проблемы геокодирования.
- **Повторная оценка AML**: обновления KYC, которые меняют имя, дату рождения или гражданство, могут повторно запустить AML-скрининг, если AML для сессии ещё не завершился. Результаты появляются в решении по сессии.## Когда эти endpoint не подходят- **Повторный запуск всей верификации**: если клиенту нужно заново снять фото документа или загрузить документ, используйте [update-status](https://docs.didit.me/ru/sessions-api/update-status.md), чтобы перевести сессию в `Resubmitted`.
- **Изменение полей профиля у сущности User или Business**: используйте [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/ru/management-api/users/update) или [`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/ru/management-api/businesses/update). Эти endpoint работают с данными уровня сущности, а не сессии.
- **Редактирование данных Key People**: публичного API для изменения имени, ролей или структуры владения стороны нет. Эти данные передаются через размещённую страницу верификации. Единственное изменяемое поле: `is_skipped` (см. [Пропуск стороны Key People](#пропуск-стороны-key-people)).## Ошибки| Статус | Значение |
| - | - |
| `401` | Отсутствуют или недействительны учётные данные. |
| `403` | У вызывающей стороны нет необходимого права (`write:sessions` или `write:businesses`). |
| `404` | Сессия не найдена или в ней нет записи, которую вы обновляете (нет KYC, нет POA, нет подходящей компании, нет подходящей стороны или сторона принадлежит другой сессии). |
| `400` | Ошибка валидации: неверный код страны, неизвестный ключ `parsed_address`, `extra_fields` не является объектом и т. д. |## Дальнейшие шаги> [card] [Получение сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md)
>
> Получите полное решение, чтобы увидеть обновлённые поля.> [card] [Обновление статуса](https://docs.didit.me/ru/sessions-api/update-status.md)
>
> Одобрите, отклоните или снова откройте сессию после исправления данных.> [card] [Webhooks](https://docs.didit.me/ru/integration/webhooks.md)
>
> Подпишитесь на события `data.updated`.


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