更新会话数据 API：修正 KYC 与 KYB 字段

有时 OCR 会误读证件、水电费账单或公司登记信息。Didit 提供三个 PATCH 端点，您可以调用它们修正提取的数据，而无需重新进行整个验证流程。

端点	使用场景
`PATCH /v3/session/{id}/update-data/`	修正从证件中提取的值，适用于用户验证（KYC）会话
`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}/`	当关键人员方无法完成自身核验时，将其从验证中豁免

四个端点均接受您的 客户端 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 企业字段。
部分更新：仅更改您包含的字段。省略某个字段则保持其原样。发送 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）。

示例

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`）。

示例

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 字符串。

示例

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}/ 将关键人员豁免验证，适用于无法完成自身检查的人员。常见原因是子会话被删除：一旦分配给 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，记录中依然可以看出规则要求过检查。

示例

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。

子会话已被删除的人员，其决策负载中会标记为 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"）。在 Webhook 目标层级订阅一次，并根据 session_kind 进行路由。
审计记录：会话会精确记录哪些字段发生了变化、变化前后的值，以及（对于用户认证的调用）操作人的邮箱。可在控制台的 Events 标签页中查看。
地址重新地理编码：对于更改了 address / poa_address 的 KYC 和 POA 更新，Didit 会在后台重新运行地理编码。地理编码失败会被忽略，因此更新不会因地理编码问题而失败。
AML 重新评估：如果会话的 AML 尚未完成，更改姓名、出生日期或国籍的 KYC 更新可能会重新触发 AML 筛查。结果会显示在会话决策中。

何时不应使用这些端点

重新进行整个验证：如果客户需要重新拍摄证件照片或重新上传证件，请使用 update-status 将会话转为 Resubmitted。
修改用户或企业实体的资料字段：请使用 PATCH /v3/users/{vendor_data}/ 或 PATCH /v3/businesses/{vendor_data}/。这些端点更新的是实体级数据，而不是会话级数据。
编辑关键人员详情：目前没有公开 API 可用于修改人员的姓名、角色或股权数据；这些数据通过托管流程提交。唯一可修改的字段是 is_skipped（参见跳过关键人员）。

错误

状态	含义
`401`	缺少凭证或凭证无效。
`403`	调用方缺少所需权限（`write:sessions` 或 `write:businesses`）。
`404`	未找到会话，或该会话不包含您要更新的记录（没有 KYC、没有 POA、没有匹配的公司、没有匹配的参与方，或参与方属于其他会话）。
`400`	验证错误：国家代码无效、`parsed_address` 键未知、`extra_fields` 不是对象等。

后续步骤

获取会话

获取完整决策，查看更新后的字段。

更新状态

数据更正后，批准、拒绝或重新打开会话。

Webhook

订阅 data.updated 事件。

最后修改于 2026年11月7日

​共享要求

​更新 KYC 身份数据

​可修改字段

​示例

​更新地址证明 (POA) 数据

​可修改字段

​示例

​更新 KYB 企业数据

​要求

​可修改字段

​示例

​跳过关键人员

​要求

​请求体

​示例

​更新后会发生什么

​何时不应使用这些端点

​错误

​后续步骤

获取会话

更新状态

Webhook

共享要求

更新 KYC 身份数据

可修改字段

示例

更新地址证明 (POA) 数据

可修改字段

示例

更新 KYB 企业数据

要求

可修改字段

示例

跳过关键人员

要求

请求体

示例

更新后会发生什么

何时不应使用这些端点

错误

后续步骤