跳转到主要内容
会话是 Didit 上的验证单元。开始一次验证时，系统会创建一个 会话；验证完成后，该会话会携带完整的决策 payload。同一套会话 API 同时处理两种类型： 在 Academy 的用户体验课程中，第 5:34 章节对比了托管流程与自建界面，这正是本 API 为您做出的取舍。

​
类型由工作流决定

当您创建会话时，需要传入 workflow_id。工作流的类型决定该会话是用户验证还是企业验证，调用方无法单独选择。KYB 工作流会创建企业验证会话；KYC 工作流会创建用户验证会话。

​
session_kind 判别字段

每个会话响应（包括创建、获取、列出、更新状态、分享和导入）都包含一个顶层字段：
  • "user"：该会话为 用户验证（KYC）会话。响应包含用户相关的功能数组。
  • "business"：该会话为 企业验证（KYB）会话。响应包含企业相关的功能数组。
请据此字段在您的系统中区分处理不同的响应结构。
枚举值是简短的标识符 "user" 和 "business"，为了便于 API 使用，我们保持其简短。完整名称 用户验证（KYC） 和 企业验证（KYB） 在整个文档中使用，以便理解。

​
按类型区分的功能数组

决策中出现的功能数组取决于类型。某一类型不适用的字段不会出现在该类型的响应中（不返回 null，也不返回占位符）：

​
顶层共享字段

每个会话（两种类型）都包含以下字段：

​
涵盖的 endpoint

以下 endpoint 均支持两种类型。没有单独的 /v3/business-session/* 路径。

​
查询的工作方式

用户验证会话和企业验证会话是两种不同的类型。ID 使用 UUID，因此不可能发生冲突。当您使用 session_id 调用 endpoint 时，Didit 会：
  1. 先在用户验证表中查找该 ID（覆盖大部分流量）。
  2. 若未找到，则回退到企业验证（KYB）表中查找。
  3. 若两张表均无匹配，则返回 404。
您无需告诉 API 您要查找的是哪种类型。

​
两种类型的状态完全相同

两种类型的状态值相同，API 会按本页所写的原样返回："Not Started"、"In Progress"、"Approved"、"Declined"、"In Review"、"Abandoned"、"Expired"、"Kyc Expired"、"Resubmitted"、"Awaiting User"。匹配为精确匹配，且区分大小写。完整说明请参见验证状态。

​
Webhooks

Webhook 事件已包含 session_kind 字段，便于您的 Webhook 处理程序按类型分发。 关于签名验证和重试语义，请参阅 Webhook；关于企业验证的事件目录，请参阅 KYB Webhook。

​
后续步骤

创建会话

发起用户验证或企业验证。

获取会话

获取决策结果。两种类型均适用。

列出会话

按 session_kind 过滤。

更新状态

批准、拒绝、审核或重新提交。

生成 PDF

按类型生成 PDF 报告。

分享与导入

在应用之间迁移会话。
最后修改于 2026年11月7日