Webhook
Webhook 把当前 Network 的生命周期与审计事件以 HTTPS POST 推送到你的系统。进入 开发者 → Webhook，为每个接收系统创建独立订阅、独立签名密钥和最小事件过滤范围。
先验签保留原始请求体，用时间戳和独立密钥计算 HMAC-SHA256。
再去重以稳定 Delivery ID 做持久幂等，重复投递不重复执行业务。
最后处理验证后进入自己的持久队列；Webhook 不是唯一事实来源。
创建前准备
- 使用公网可达、证书有效的 HTTPS 地址；不要使用回环、链路本地或私网地址绕过网络边界。
- 为每个订阅生成至少 32 字符的随机签名密钥，并存入接收方密钥管理系统。
- 先实现验签、时间窗口和幂等，再在 NSD 中启用订阅。
- 事件过滤支持动作前缀，例如
policy.或精确动作user.create；留空表示全部事件。
签名密钥是只写字段：创建后不会从 API 或页面返回。编辑时留空表示保留原密钥；填写新值表示轮换。
验证每次投递
NSD 发送以下请求头：
验签输入是原始字节串 <X-Nsio-Timestamp>.<raw request body>。必须在解析或重新序列化 JSON 前保留原始请求体，并使用恒定时间比较计算值与请求头。
接收方至少执行以下顺序：
- 限制请求体大小并读取原始字节。
- 拒绝缺少签名、时间戳或投递 ID 的请求。
- 拒绝超出本系统允许时间窗口的时间戳，降低重放风险。
- 计算 HMAC-SHA256 并恒定时间比较。
- 以
X-Nsio-Delivery去重；重复投递返回成功但不重复执行业务动作。 - 验证通过后再解析 JSON，并把后续工作放入自己的持久队列。
测试和排障
保存后点击 测试，NSD 会发送 webhook.test。只有目标成功接受请求才算链路可用；随后检查最近投递的 HTTP 状态和错误。
单次 HTTP 请求超时为 10 秒，失败最多尝试 3 次，重试前等待约 1 秒和 3 秒。当前投递是进程内尽力而为，不是持久消息队列：接收方仍应通过活动日志或周期性 API 同步补偿关键状态，不能只依赖 Webhook 作为唯一事实来源。
常见问题：
返回 API 访问。