在此之前，想知道帖子有没有发出去，只能主动去问。你调用 API，查看状态，过一会儿再调用一次。这样能用，但本质是轮询：问得太勤会浪费请求，问得太少又会知道得太晚。Webhook 把这个过程反了过来。你给 sona.to 一个网址，事情发生的那一刻 sona.to 主动找你。现在所有套餐都已提供。
可订阅的事件有四个，覆盖了值得响应的结果：帖子已发布、帖子发布失败、站点审计完成、站点审计失败。每个 Webhook 接收哪些事件由你决定，所以 Slack 通知可以只听失败，而报表流程可以全都接收。负载使用的字段名与 REST API 返回的一致，因此你已经在 GET 请求里解析的那套代码原样可用。
设置只需一分钟。打开控制台的 API 页面，粘贴你的工具给出的网址，勾选需要的事件，保存。签名密钥只在那一刻显示一次。请当场复制，因为它不会再次显示。
这个密钥就是你判断请求是否真实的依据。每次投递都带有一个签名头，其中包含时间戳，以及由该时间戳和请求体用你的密钥计算出的 HMAC SHA-256。在你这边重新计算一遍，并用常量时间函数比对两者。由于时间戳本身也在签名范围内，被截获的请求无法在之后被重放攻击你。拒绝超过几分钟的请求就足够了。
投递不会因为第一次出问题就放弃。如果你的接收端宕机或返回错误，请求会在 60 秒后重试，然后是 5 分钟，然后是 30 分钟。每次尝试都会记录状态码和耗时，所以一个异常的接收端是可以查看的对象，而不是靠猜。持续失败的接收端会被自动关闭，修好之后你可以重新启用。
最顺手的指向对象是自动化平台。Zapier、Make 和 n8n 都会给你一个 Webhook 网址供粘贴，事件以 JSON 形式送达，可以直接接到后续动作：发到频道的一条消息、表格里的一行、任务系统里的一个任务。你自己的服务器完全一样，中间不需要平台。
关于 sona.to 接受什么地址的说明。目标必须使用 https，并且必须是公网地址。解析到内网的网址会被拒绝，保存时会拒绝，投递时会再次拒绝，并且不会跟随重定向。如果你在局域网自建接收端，请把它放在公网主机名或隧道之后。
Webhook 与 REST API 和 MCP 服务器一起，成为在控制台之外驱动 sona.to 的第三种方式。API 用来发问，MCP 用来被 AI 助手发问，而 Webhook 用来被告知。包括签名校验示例在内的完整说明，都在 API 文档中。