> ## 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、住所証明（POA）、KYBの法人登記フィールドを修正できます。3つの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は、検証全体をやり直すことなく抽出データを修正できる3つのPATCHエンドポイントを提供しています。| エンドポイント | 用途 |
| - | - |
| [`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}/`](#主要人物の当事者をスキップ) | 主要人物の当事者が自身の確認を完了できなくなった場合に、その当事者を検証の対象から除外する |4つのエンドポイントはいずれも **クライアントAPIキー** または **ユーザー認可ヘッダー** を受け付け、成功時には`data.updated`Webhookイベントを送信するため、お客様のシステムや下流の分析と同期を保てます。## 共通の要件- **認可**：クライアント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企業フィールドはセッションに登記チェックがある場合のみ更新できます。
- **部分更新**：含めたフィールドのみが変更されます。フィールドを省略すると、そのまま維持されます。`extra_fields`のキーを削除するには`null`を送信します。
- **Webhook**：更新が成功すると、`session_kind: "user"`または`"business"`を含む`data.updated`が発行され、セッションの監査証跡に、変更された具体的なフィールドと変更者が記録されます。## KYC本人データの更新**`PATCH /v3/session/{sessionId}/update-data/`**身分証明書から抽出された任意のフィールドを更新します。オプションの`node_id`クエリパラメーターまたはボディ内のフィールドを使用することで、グラフベースのマルチインスタンスワークフローに対応しています。1つのセッションに複数の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`はこの2つから自動的に再計算されます。 |
| `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" }
  }'
```マルチインスタンスのグラフワークフローでは、URLに`?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` | 構造化された住所。ネストされた形式は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企業の登記から抽出されたフィールドを修正します。このエンドポイントは正規の企業カラムと`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/ja/sessions-api/retrieve-session.md#法人確認-kyb)の`registry_checks[].company`と同じ形式です。## 主要人物の当事者をスキップ**`PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/`**主要人物の当事者を検証の対象外にします。自身のチェックを決して完了できない当事者のための回避手段です。よくある原因は子セッションの削除です。UBOまたは取締役に割り当てられた個人KYCが削除されると、そのステータスは固定されて決して確定しなくなるため、KYBには`Awaiting User`から移行させる手段が何も残りません。当事者をスキップすると主要人物の集計から除外され、チェックがその場で再計算されるため、セッションが確定し、承認または却下されるようになります。### 要件- **権限**: `write:businesses`。
- URLの`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 }'
```レスポンス: 更新された当事者。[セッション判定](https://docs.didit.me/ja/business-verification/response-schema.md#key_people_checks)の`key_people_checks[].submitted.parties[]`の要素と同じ形式です。`trigger: "console_key_people_skip"`を含む`data.updated` Webhookイベントが発生します。> [!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`で振り分けてください。
- **監査ログ**: セッションには、変更されたフィールド、変更前と変更後の値、および(ユーザー認証による呼び出しの場合は)実行者のメールアドレスが正確に記録されます。コンソールの「Events」タブで確認できます。
- **住所の再ジオコーディング**: `address` / `poa_address`を変更するKYCおよびPOAの更新では、Diditがバックグラウンドでジオコーディングを再実行します。失敗は無視されるため、ジオコーディングの問題が原因で更新が失敗することはありません。
- **AMLの再評価**: 氏名 / 生年月日 / 国籍を変更するKYCの更新は、セッションでAMLが完了していなかった場合、AMLスクリーニングを再トリガーすることがあります。結果はセッションの判定に表示されます。## これらのエンドポイントを使用すべきでない場合- **検証全体のやり直し**: 顧客が身分証明書の写真を撮り直したり、書類を再アップロードしたりする必要がある場合は、代わりに[update-status](https://docs.didit.me/ja/sessions-api/update-status.md)を使用してセッションを`Resubmitted`に移行してください。
- **UserまたはBusinessエンティティのプロフィールフィールドの変更**: [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/ja/management-api/users/update)または[`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/ja/management-api/businesses/update)を使用してください。これらのエンドポイントは、セッションレベルではなくエンティティレベルのデータを更新します。
- **主要人物の詳細の編集**: 当事者の名前、役割、所有構造を変更する公開APIはありません。このデータはホスト型フローを通じて送信されます。変更できる唯一のフィールドは`is_skipped`です([主要人物の当事者をスキップ](#主要人物の当事者をスキップ)を参照)。## エラー| ステータス | 意味 |
| - | - |
| `401` | 認証情報がないか、無効です。 |
| `403` | 呼び出し元に必要な権限(`write:sessions`または`write:businesses`)がありません。 |
| `404` | セッションが見つからないか、更新対象のレコードがセッションに含まれていません(KYCがない、POAがない、一致する企業がない、一致する当事者がない、または当事者が別のセッションに属している場合)。 |
| `400` | バリデーションエラーです。無効な国コード、未知の`parsed_address`キー、`extra_fields`がオブジェクトではない、などが該当します。 |## 次のステップ> [card] [セッションの取得](https://docs.didit.me/ja/sessions-api/retrieve-session.md)
>
> 判定全体を取得して、更新されたフィールドを確認します。> [card] [ステータスの更新](https://docs.didit.me/ja/sessions-api/update-status.md)
>
> データの修正後に、セッションを承認、却下、または再オープンします。> [card] [Webhook](https://docs.didit.me/ja/integration/webhooks.md)
>
> `data.updated`イベントを購読します。


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