我们发出的每一个 webhook 都经过签名，让接收方能证明确实来自我们

一个 webhook URL 就是一个公开的信箱。任何得知该地址的人都能通过它投递一个伪造的事件——伪造的线索、伪造的预算、伪造的紧迫感——而一个天真的接收方会全盘相信。一个未经身份验证的 webhook 不是投递；它只是一条建议。

我们的事件分发会对每一个负载（payload）进行签名。每一次出站投递都使用一个按端点划分的密钥，以 HMAC-SHA256 进行哈希，结果随附在一个 X-Webhook-Signature 头中。接收方用共享密钥重新计算哈希，并拒绝任何不匹配的内容。这一道检查就把“一个自称是线索的请求”变成了“一个可被证明来自我们的请求”。它还让负载在传输途中具备防篡改可见性：改动正文中的一个字符，签名就会失效。

身份验证只是威胁模型的一半。一个会向任何地址发起 POST 的分发器，就是一件等着被指向内部的服务端请求伪造（SSRF）工具。因此在发送之前，我们会校验目的地，并拒绝私有与回环地址段——10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、链路本地地址等等。结合一个硬性的请求超时，一个配置错误或带有恶意的端点就无法把我们的分发器变成一次针对内网的探测，或一个挂起的连接。

我们拒绝这样做：发送未签名的负载，盲目地向一个黑洞重试，或者让一个端点定义偷偷夹带一个内部地址。只做签名而不设 SSRF 防护，就像在一扇上锁的前门旁边开着一扇窗户；我们把两者都关上。

原则是：一次线索交接应当在接收端可被验证，并且在送出途中无法攻击任何东西。如果您的 CRM 分辨不出我们的线索与陌生人的线索，那么这套集成就只是装饰。密码学证明加上一条严格的出站策略，才是让机器对机器的投递成为您在凌晨两点能够真正依靠的东西。