前提条件
- 拥有 monitor 访问权限的 Pubrio API 密钥
- 一个可公开访问的 HTTPS 端点(或来自 usewebhook.com 的测试 URL)
步骤 1:创建带有 Webhook 投递目标的 Monitor
headers 对象会在每次投递时添加自定义 HTTP 请求头(用于身份验证)。body 对象会在 webhook 负载的根级别添加自定义字段。
步骤 2:验证你的 Webhook 连接
使用验证 Webhook 端点测试你的端点是否可达。这会发送一个包含占位数据的示例负载——不消耗积分,不获取真实信号。步骤 3:使用真实数据测试
连接验证通过后,使用处理尝试端点触发一次真实运行。这会获取实际信号并投递到你的 webhook——使用tried_at 设置一个近期的过去时间以确保有可用数据:
与 validate 不同,try 端点运行真实扫描并消耗积分。使用它来验证真实负载正确到达,并在计划扫描启动前快速预估结果。
步骤 4:验证签名
每个 monitor 都有唯一的签名,用于验证传入的负载确实来自 Pubrio。monitor.monitor_id 进行比较以验证真实性。
Webhook 负载结构
负载根据 monitor 的detection_mode 而不同:
- 信号优先
- 公司优先
在 每个信号条目包含信号详情以及关联的已补充公司和人员。
signal_first 模式中,负载包含顶层的 signals 数组:来自
destination_config 的自定义 body 字段会出现在根级别(例如上面示例中的 "pipeline": "my-webhook")。电子邮件投递目标
对于偏好电子邮件投递的团队,将destination_type 设置为 "email":
Pubrio 为代理商和团队提供白标邮件投递支持。联系我们了解自定义发件人域名和品牌。
故障排除
Webhook 未接收到负载
Webhook 未接收到负载
- 确认你的端点是可公开访问的(不在防火墙或 VPN 后面)
- 确保它返回
200状态码——其他状态码会被视为失败 - 使用验证 Webhook 端点测试连通性
- 检查统计日志中的错误信息和响应码
Monitor 在失败后暂停
Monitor 在失败后暂停
如果你的 webhook 持续返回非 200 状态码,monitor 在达到
max_failure_trigger 次连续失败后会暂停。修复问题后通过更新 Monitor 重新激活。重复负载
重复负载
如果投递失败且配置了重试,你可能会多次收到相同的负载。使用
triggered_at 或日志 ID 在你端进行去重。负载过大
负载过大
减小
max_records_per_trigger 以限制每次投递的记录数。你也可以缩小筛选范围以减少匹配的信号量。
