设置目标
您需要在 Business Console 中配置警报 Webhook,而不是通过 API。有权管理组织设置的成员可以添加、修改和测试目标。1
添加目标
在 组织设置 > 团队通知 中,使用您的 endpoint URL 添加一个 警报 Webhook 目标。
URL 必须使用
https://,并解析到公共地址。2
保存签名密钥
Didit 只会显示一次完整的签名密钥,它以
whsec_ 开头。
请立即保存:之后控制台只显示其最后四个字符。3
将警报路由到该目标
仅添加目标不会向其发送任何内容。
将该目标添加到您希望它接收的警报的路由规则中。
4
发送测试
点击 发送测试,发送一条
alert.test 警报,并检查您的 endpoint 是否接受它。警报类型
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 目标标记为需要重新连接(参见重试)。
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所依据的公开信息源。 - 人工审核:处理处于审核中的验证。