跳转到主要内容
本指南将带您完整了解通过 REST API 集成 Didit 身份验证的流程:获取凭证、创建会话、将会话呈现给用户,并接收结果。

步骤 1: 获取您的凭证

您有两种方式获取 api_key:

选项 A: 通过编程方式注册 (无需浏览器)

适用于 CI/CD 和 AI 智能体。依次调用两个 API 接口 POST /programmatic/register/ 和 POST /programmatic/verify-email/,即可直接返回 api_key。 → 有关完整流程、密码规则、JWT 有效期和锁定策略,请参阅 编程方式注册。

选项 B: 从 Didit 控制台获取

  1. 前往 Didit 控制台。
  2. 创建或选择您的组织。
  3. 进入 Settings → API & Webhooks。
  4. 复制以下内容:
    • API Key:用作每次验证调用中的 x-api-key 请求头。
    • Webhook Secret Key:用于验证 Webhook 的 HMAC 签名。

环境变量


步骤 2: 创建工作流

在创建会话之前,您需要一个验证工作流。工作流定义了用户需要完成的验证步骤。

在控制台中创建

  1. 前往 Didit 控制台 → Workflows
  2. 点击 Create Workflow
  3. 选择基础模板:
  1. 添加可选功能:
  1. 复制您的 Workflow ID
有关详细配置选项,请参阅 工作流文档。

Step 3: 创建验证会话

调用 API 为您的用户创建会话。

请求

请求参数

包含全部选项的完整示例

expected_details.expected_document_types 会将身份证件验证步骤限制为特定证件类型,证件选择页面只显示所请求的类型。允许的值:P(护照)、ID(国民身份证)、DL(驾照)、RP(居留许可)、HIC(医疗保险卡)、TC(税卡)、SSC(社会保障卡)。值不区分大小写,并会去重;未知值返回 400。完整结构请参见 创建会话参考。

响应

返回 201 Created:

关键响应字段

幂等性。 提供 vendor_data 时,如果工作流最新已发布版本上已存在具有相同 vendor_data 且未完成的会话(状态为 Not Started、In Progress、Resubmitted 或 Awaiting User),则直接返回该已有会话(仍为 201),而不会创建重复会话。此时其 callback 和 metadata 会更新为新值,status 反映已有会话的状态。
缺少 x-api-key 时返回 403,响应体为 {"detail": "You do not have permission to perform this action."},与拥有但无权限的有效密钥返回的响应体相同。错误、已撤销或已过期的密钥返回 401。额度不足时返回 400。完整文档请参见 创建会话 API 参考。

Step 4: 向用户展示验证流程

选择向用户展示验证流程的方式:

选项 A: 原生 SDK(推荐用于移动端)

将 session_token 与原生 SDK 配合使用,以集成摄像头、NFC 和生物识别功能。 → iOS SDK · Android SDK · React Native · Flutter

选项 B: InContext iframe(推荐用于 Web)

使用步骤 3 返回的 url,将验证嵌入您的页面。
→ InContext iframe

选项 C: 重定向

将用户重定向至验证 URL。
→ Web 重定向

选项 D: 移动端 WebView

适用于没有原生 SDK 的移动应用。
→ iOS/Android 中的 WebView

步骤 5: 接收结果

通过 Webhook (推荐)

Webhook 会在验证状态变化时实时通知您的服务器。 设置:
  1. 在控制台(API 和 Webhook)中创建 Webhook 目标,或通过 POST /v3/webhook/destinations/ 创建,并设置 webhook_version: "v3" 以及 subscribed_events 数组(例如 ["status.updated"])
  2. 保存创建时返回的 secret_shared_key,它是所有签名变体通用的 HMAC 密钥
  3. 在您的服务器上实现 Webhook endpoint
Webhook payload 示例: 在 decision 内部,每项功能的结果都以复数数组形式返回(id_verifications[]、nfc_verifications[]、liveness_checks[]、face_matches[] 等),工作流中的每个节点对应一个条目。这是 V3 协议约定,不得更改:永远不要基于单数的 nfc / id_verification / liveness 键编写代码。
只有当 status 为 Approved、Declined、In Review 或 Abandoned 时才会包含 decision 对象(Resubmitted 事件则携带 resubmit_info)。Didit 在重试和分发到多个目标时会复用同一个 event_id,请以它作为幂等性的判断依据。有关所有复数数组和字段,请参阅数据模型。 验证签名(X-Signature-V2,推荐): X-Signature-V2 是对 JSON 请求体的规范化重新编码结果计算的 HMAC-SHA256:值为整数的浮点数会被转换为整数,键按递归方式排序,使用紧凑分隔符,并保留 Unicode 字符。
→ 完整 Webhook 文档,包括基于原始字节的 X-Signature、已弃用的仅包含信封的 X-Signature-Simple,以及如何选择签名方式。Didit 会对失败的投递(5xx、404、超时)重试最多 2 次(约 1 分钟后,再约 4 分钟后),超时时间为 5 秒,因此请尽快返回 2xx。

通过 API (可选)

您可以随时获取相同的决策 payload:
该响应结构(复数数组)与 Webhook payload 中的 decision 对象相同,并且可以在会话生命周期的任意时间点调用此 endpoint。实时更新请使用 Webhook,API 调用仅用于数据回填、审计和重建。/decision/ 端点的限流为每个 API 密钥每分钟 600 次 GET 请求(参见速率限制)。错误语义如下:未知的 session_id 返回 404 和 {"detail": "Not found."};认证失败时返回 403,此端点绝不返回 401。响应中的媒体 URL 是短期有效的预签名链接,请及时获取,不要持久保存。 → 获取会话 API 参考

完整代码示例

Node.js / Express

Python / FastAPI


会话状态

以下是 status 的 10 个可能值,均为区分大小写的精确字符串(注意 Kyc Expired 中的 K 为大写): 有关完整的生命周期、状态转换和 Mermaid 图,请参阅验证状态。

后续步骤

  1. 选择您的集成方式:
  2. 配置 Webhook:Webhook
  3. 规划容量:速率限制
  4. 处理每一种状态:验证状态
  5. 自定义您的工作流:工作流
  6. 验证 API 是否可访问:健康检查

需要帮助?

最后修改于 2026年11月7日