企业
Webhook 与通知
企业客户需要将运营事件推送到他们自己的系统中,而不是手动查看仪表盘。
企业客户需要将运营事件推送到他们自己的系统中,而不是手动查看仪表盘。
交付渠道
| 渠道 | 最适合 |
|---|---|
| 电子邮件通知 | 人工审核以及财务或安全警报 |
| Webhook | 自动化和系统对系统处理 |
如何选择渠道
| 事件类型 | 更适合邮件的情况 | 更适合 webhook 的情况 |
|---|---|---|
| 计费 | 财务负责人需要审核或批准 | 你的会计或内部工单系统需要接收事件 |
| 用量限制 | 需要人工决定是否提高限制 | 平台需要自动降速任务或通知值班 |
| 成员变更 | 管理员需要审计通知 | 安全工具跟踪身份生命周期事件 |
| key 变更 | 负责人需要可见性 | 内部系统需要轮换、禁用或排查 key |
| 安全告警 | 安全负责人必须审核 | SIEM、Pager 或事故流程需要收到事件 |
典型电子邮件通知
- 生成账单
- 支出或使用量警告
- 成员变更
- 安全警报
Webhook 配置模型
当前企业方案描述了三个关键字段:
- webhook URL
- 订阅的事件类型
- 签名密钥
接收端要求
Webhook 接收端应按生产集成点设计:
- 使用公开 HTTPS 端点。
- 在信任 payload 前校验签名密钥。
- 快速返回,把慢任务放入队列。
- 让处理具备幂等性,避免重复投递触发重复动作。
- 保存 event ID、事件类型、任务或资源 ID、接收时间和处理状态。
- 保留轮询或控制台查看作为 webhook 延迟时的兜底。
示例事件领域
billing.generatedbilling.paidbilling.overdueusage.alertusage.limit_reachedmember.invitedmember.joinedmember.removedkey.createdkey.disabledkey.deleted
集成检查清单
在生产中依赖 webhook 前,请确认 webhook URL、订阅的事件类型、签名密钥、重试行为,以及你的系统需要保存的事件 payload 字段。