跳转到主要内容
警报 Webhook 会将您团队的警报发送到您拥有的 HTTPS endpoint。您可以用它对接值班工具、工单队列或您自己的运营仪表板。 警报 Webhook 与验证 Webhook相互独立。验证 Webhook 会将会话、实体和交易结果发送到您的应用程序。警报 Webhook 则告知您的团队某件事需要关注:等待审核的验证、失败的支付或服务事件。它们拥有各自的 payload、签名密钥、签名和重试计划。

设置目标

您需要在 Business Console 中配置警报 Webhook,而不是通过 API。有权管理组织设置的成员可以添加、修改和测试目标。
1

添加目标

在 组织设置 > 团队通知 中,使用您的 endpoint URL 添加一个 警报 Webhook 目标。 URL 必须使用 https://,并解析到公共地址。
2

保存签名密钥

Didit 只会显示一次完整的签名密钥,它以 whsec_ 开头。 请立即保存:之后控制台只显示其最后四个字符。
3

将警报路由到该目标

仅添加目标不会向其发送任何内容。 将该目标添加到您希望它接收的警报的路由规则中。
4

发送测试

点击 发送测试,发送一条 alert.test 警报,并检查您的 endpoint 是否接受它。
一个组织最多可以在 团队通知 中添加 25 个目标。 只有实时活动会发送到目标。沙盒验证、企业验证、交易和 AML 命中的警报永远不会发送到该目标。

警报类型

Payload

每条警报都是一个带 JSON 请求体的 POST 请求。 Didit 以紧凑格式发送请求体,键按字母顺序排序。 以下示例为便于阅读而进行了格式化:
data 始终包含:
  • event:事件键,例如 session_in_review。
  • label 和 value:警报所涉及的内容,例如 Session 和 #1042。
部分警报类型会在 data 中添加其他键:
  • alert.billing.autorefill_failed 会添加 paused,这是一个布尔值。当自动充值已暂停、需要您更新银行卡后才会恢复时,其值为 true。
  • alert.service.degraded 和 alert.service.recovered 会添加 service、status、incident_id、service_name、state、affected、country_name、started_at、resolved_at、duration_minutes、title 和 body。 对于 alert.service.degraded,status 为 degraded 或 down;对于 alert.service.recovered,为 recovered。 service 使用 GET /v3/status/ 中的服务键,incident_id 与其中某个事件的 id 一致。
警报永远不包含终端用户的个人数据或证件数据。 它们通过编号来标识会话、交易或其他项目,并在控制台中提供相应链接。 请忽略您不认识的 webhook_type 值和 data 键,以免新增的值或键导致您的 endpoint 出错。

请求头

验证签名

X-Signature-V2 是对字符串 <X-Timestamp>.<raw body> 计算的 HMAC-SHA256 十六进制编码值,密钥为你的 Webhook 目标的签名密钥。
  • 使用 Didit 显示的完整密钥,包括 whsec_ 前缀。
  • 对收到的原始请求字节进行签名。解析 JSON 后再重新序列化可能改变字节内容,导致校验失败。
  • 以恒定时间方式比较签名。
  • 如果 X-Timestamp 与你的时钟相差超过 5 分钟,请拒绝该请求。Didit 会为每次尝试(包括每次重试)使用新的时间戳签名,因此此时间窗口不会拒绝真正的重试。
  • 校验失败时返回 400。收到 401、403、404 或 410 响应会将该 Webhook 目标标记为需要重新连接(参见重试)。
警报 Webhook 的签名方式与验证 Webhook 不同。 该请求头同样名为 X-Signature-V2,但签名字符串不同,并且警报 Webhook 不发送 X-Signature 或 X-Signature-Simple。 请勿复用你的验证 Webhook 验证器。

Node.js(Express)

Python(Flask)

轮换签名密钥

你可以在团队通知中为 Webhook 目标轮换密钥。 Didit 只会显示一次新密钥,并使用新密钥签名之后的所有尝试,包括轮换前创建的警报的重试。 旧密钥会立即失效。 不存在过渡期,任何请求头中的签名都不会使用旧密钥生成。 轮换后请立即将新密钥部署到你的 endpoint。

重试

Didit 将任何 2xx 响应视为投递成功。 每次尝试最多等待你的响应 5 秒,并且不会跟随重定向。 在发生超时、连接失败、5xx 响应,或 408、425、429 响应后,Didit 会重试该警报。 最多重试 5 次,历时约 24 小时: 其他所有响应均为最终结果,包括 3xx 以及其他任何 4xx 响应。 使用发送测试发送的测试只会尝试一次,且永不重试。 收到 401、403、404 或 410 响应时,同样会将该 Webhook 目标标记为需要重新连接,控制台会显示重新连接状态。 如果 Didit 发送时,某个 URL 解析到私有或其他被封锁的地址,也会出现同样的标记。 Didit 会继续向该 Webhook 目标发送新警报,在下一次成功投递后或你更新其 URL 后,该目标会重新变为活动状态。 团队通知中的最近通知会列出每次投递及其结果,你可以在此处重试失败的投递。

相关内容

  • 验证 Webhook:为你的应用提供会话、实体和交易结果。
  • 服务状态:alert.service.degraded 和 alert.service.recovered 所依据的公开信息源。
  • 人工审核:处理处于审核中的验证。
最后修改于 2026年11月7日