WhatsApp Webhook：将消息直接路由到您的服务器

Meta 实际向 Webhook 发送什么？

事件分为不同类别，而类别之间的区别会决定您的架构。

消息路径承载客户发送的内容；在 Coexistence 号码上，也会包含团队通过 WhatsApp Business 应用发送内容的回显。这些字段是 messages 和 smb_message_echoes，也是包含对话内容的字段。

运营路径承载其他所有内容：连接状态变化时的 account_update、质量或吞吐量变化时的 phone_number_quality_update、account_alerts、account_review_update、business_capability_update 和 phone_number_name_update。这些事件不含对话内容，也是监控的基础。

把自己放在消息路径中的服务商会收到第一组事件。不在消息路径中的服务商则不会收到。

Meta 如何验证端点？

Meta 会先发送 GET 请求，验证失败是设置看似完成却始终收不到消息的最常见原因。

Meta 会调用您的 URL，并设置 hub.mode 为 subscribe，发送您的 hub.verify_token 以及 hub.challenge 值。您的端点必须将该 challenge 作为原始响应正文返回，不能包装在 JSON 中，也不能添加任何内容。如果没有返回，Meta 就不会开始发送事件，任何控制台都不会提示原因。

端点还必须使用 HTTPS。返回静默 404 的端点，或位于会拒绝 Meta 的身份验证层之后的端点，在第一条消息迟迟未到之前，看起来都与正常设置完全一样。

目标可以指向您自己的服务器吗？

可以，而这正是不同服务商之间的区别。

Meta 允许应用覆盖某个 WhatsApp Business Account 接收 Webhook 的位置。我们会将该覆盖项设为您的 URL，把消息路径事件从我们的 callback 移到您的端点。运营事件仍由我们保留，因为控制台和警报都依赖这些事件。

结果是架构上的变化，而不是我们发布的一项政策。对话内容从未发送给我们，因此我们这边没有地方可以存储这些内容。未设置覆盖项的账户会回退到我们的默认 callback，处理程序会丢弃这些事件而不保存。

号码重新连接时，目标会怎样？

目标会被移除，这是几乎没人会提前规划的故障。

目标不是电话号码的属性，而是我们应用对 WhatsApp Business Account 的订阅所设置的覆盖项。当连接被移除时，无论是因为 Meta 的 14 天不活跃规则还是其他原因，应用都会从该账户卸载，覆盖项也会随之消失。

重新连接会恢复发送和监控，但不会恢复向您服务器的发送，也不会报告错误。因此，第一个迹象可能是客户说没有人回复。我们会在每次重新连接时重新应用覆盖项，因为确实有一个号码顺利重新连接后变得完全安静。

常见错误

• 在验证 GET 中返回 JSON。Meta 要求只返回原始 hub.challenge 值，不能有其他内容。
• 使用临时或测试 URL。生成该 URL 的工具停止监听后，Meta 仍会继续向它发送事件。
• 假设目标会在重新连接后保留。目标属于应用订阅，应用卸载时它也会被移除。
• 将端点置于会拒绝 Meta 请求的身份验证之后。

常见问题

继续阅读