我继承了一个用Node编写的Facebook webhook应用程序，该应用程序跟踪与我们组织相关的几个Facebook页面的帖子。在2017-07-02(大约3周前(，Facebook似乎停止向此应用程序推送Webhook更新。在此之前的几年中，此应用程序已成功运行。
这些是我在应用程序的访问日志中看到的最后一个条目：
724661:173.252.105.118 - - [02/Jul/2017:16:40:23 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
724662:66.220.145.151 - - [02/Jul/2017:16:55:29 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
724663:31.13.114.11 - - [02/Jul/2017:16:55:30 -0700] "POST /callback/facebook HTTP/1.1" 200 5 "-" "Webhooks/1.0"
我已经通过使用 curl 发送它确实成功处理的手动请求来确认我们的应用程序仍在运行。
我在这里看到Facebook将其API的v2.3标记为将于7月8日结束：
- https://developers.facebook.com/docs/apps/changelog
在 v2.3 到 v2.4 的升级指南中，它指出：
您的应用需要考虑 v2.3 和 v2.4 之间的许多页面权限更改。值得注意的是，现在需要页面访问令牌才能与/v2.4/{page_id}/promotable_posts、/v2.4/{page_id}/offer 和/v2.4/{page_id}/milestones 进行交互。
这就是Facebook停止向我们的webhook端点推送更新的原因吗？如果是这样，在哪里可以找到有关将页面访问令牌与 webhook 一起使用的更多信息？
如果您的应用没有足够快地响应 200 状态代码，Facebook 将在一段时间后停止向您的 webhook 回调 URL 发送更新。在这种情况下，您必须重新设置回调 URL。
这是 - 在某种程度上 - 记录在 https://developers.facebook.com/docs/messenger-platform/webhook-reference#response，
当 Facebook 调用时，您的 webhook 回调应始终返回 200 OK HTTP 响应。如果不这样做，可能会导致您的网络钩子被 Messenger 平台取消订阅。
尽快返回 200 OK HTTP 非常重要。Facebook将等待200，然后再向您发送下一条消息。在大容量机器人中，延迟返回 200 可能会导致 Facebook 向您的网络钩子发送消息时出现重大延迟。
这里没有明确提到这一点，但我很确定在一定时间内未能以 200 响应也被认为是失败。
即使是与实时性相关的工具，如Facebook Scraper(从用户共享的链接中获取Open Graph元数据(的超时时间为10秒;因此Facebook对webhooks的耐心不会再长，可能更短，特别是对于Messenger平台相关的webhooks——这些响应时间毕竟直接影响用户体验。
Edit：你意识到你实际上问的是Graph API webhooks，而不是Messenger平台。但对于那些人来说是相似的 - https://developers.facebook.com/docs/graph-api/webhooks#callback
如果发送到您的服务器的任何更新失败，我们将立即重试，然后在接下来的 24 小时内以降低的频率再尝试几次。在这些情况下，您的服务器应处理重复数据删除。24 小时内未接受的更新将被丢弃。
响应
终结点应为所有更新通知返回 200 OK HTTPS 响应。
从FB开发人员组的讨论中，我知道在这种情况下，重复超时也会导致取消订阅Webhook。