Messenger定期通知opt-in事件未送达webhook的排查咨询

一、Facebook侧功能准入与配置校验 #

• 核对问题主页的功能开通状态：Recurring Notifications是按主页注册地分批灰度开放的，即使同账号下印度区主页功能正常，也不代表肯尼亚注册主页已获得功能授权。进入对应应用的Messenger产品设置页，找到定期通知板块，确认功能未处于待审核、区域限制、合规封禁状态——未获得功能授权的主页，所有和定期通知相关的messaging_optins事件都会在Facebook侧被拦截，不会向webhook发起推送。
• 检查webhook订阅的绑定粒度：同开发者账号下多主页的webhook订阅是独立配置的，确认messaging_optins订阅项确实在肯尼亚主页对应的应用配置下勾选，而非仅在印度主页的配置下开启，应用级的全局订阅不会自动给所有关联主页生效。
• 核对应用模式与白名单配置：如果当前应用还处于开发模式，必须保证触发opt-in操作的测试账号、后台测试payload的触发主体都在应用的管理员/测试人员白名单内，开发模式下非白名单主体触发的所有事件都会被Facebook侧直接丢弃。
• 查看Facebook官方webhook错误日志：在开发者后台的webhook配置页有专门的失败日志面板，所有推送失败的请求（包括后台Test按钮触发的测试payload）都会在这里记录具体失败原因，比如权限不足、目标地址不可达、响应不符合要求等，80%以上的推送失败问题可以在这里直接定位根因。

二、Webhook接收链路排查 #

• 全链路拉取流量日志校验：不要只检查业务服务的接收日志，拉取德国AWS实例对应的安全组、WAF、负载均衡的全流量访问日志，核对是否存在来自Facebook出口IP段的请求被拦截。Facebook的webhook出口IP是动态更新的，不同区域的事件推送走不同的出口节点：印度区的推送走亚太节点，大概率已经在你之前配置的IP白名单内，而负责肯尼亚区域事件推送的非洲/欧洲节点IP如果没在白名单里，请求会在到达业务服务前就被拦截，表现为业务侧完全收不到请求。
• 检查webhook响应状态与退避规则：Facebook要求webhook收到任意推送请求后必须在10秒内返回200 OK状态码，如果之前该类事件的推送出现过超时、返回4xx/5xx的情况，Facebook会自动启动退避机制，多次失败后会临时屏蔽该类事件的推送。可以在webhook配置页重新触发一次地址验证，重置退避状态后再测试messaging_optins类型的推送。

三、业务配置与测试流程校验 #

• 区分不同场景的messaging_optins事件：Recurring Notifications触发的opt-in事件和其他Messenger插件触发的opt-in事件payload结构、推送逻辑存在差异，不要用通用opt-in的测试payload代替定期通知场景的测试payload。除了后台的Test按钮，必须用真实测试账号在和肯尼亚主页的对话窗口内实际点击opt-in按钮触发流程，避免测试工具本身的异常干扰判断。
• 核对opt-in消息的合规参数：不同地区对营销类通知的合规要求不同，肯尼亚区域对定期通知的频次参数、用户授权提示文案的要求和印度区域存在差异，如果发送给用户的opt-in消息里notification_messages_frequency等参数不符合当地合规要求，用户点击按钮后不会生成有效opt-in事件，自然不会触发webhook推送。

内容的提问来源于stack exchange，提问作者David Tresner-Kirsch