如果您收到类似“We're sorry, something went wrong”（抱歉，系统出错）的错误，并且无法确定原因，您可以选择启用更加详细的错误消息，从而可能获得更加实用的信息。 对于 SDK 的 init() 方法的调试标记，可从以下网址找到更多相关文档：https://developers.facebook.com/docs/accountkit/webjs/reference
当 Android 用户输入的手机号码与他们在 Facebook 中列出的手机号码匹配时，Account Kit 即时身份验证不会要求通过短信提供验证码。
这仅在用户使用 Android 版 Facebook 应用的情况下可行。如果我们无法确认匹配，用户将需要完成常规流程并通过短信接收验证码。
Account Kit 将为以下列表中的语言显示经过本地化的 UI：https://developers.facebook.com/docs/accountkit/languages。
请参阅以下网站，获取受支持国家/地区和区号的最新列表：https://developers.facebook.com/docs/accountkit/countrycodes。
否，我们仅支持通过 https://sdk.accountkit.com/en_US/sdk.js 来链接 JavaScript SDK。此脚本会获取 SDK 加载程序，而此程序会从 accountkit.com 或您的浏览器缓存加载最新的 SDK。
如果您想通过自己的服务器托管 SDK，则总共可以托管 24 小时。此期限之后，SDK 就会开始发出警告，并在 7 天后停止运行。
将 enableSendToFacebook 参数 (iOS) 或 setFacebookNotificationsEnabled 参数 (Android) 设置为 true。
如果登录应用的用户使用的手机号是其 Facebook 帐户关联的主要手机号，则在无法送达短信的情况下，用户将通过 Facebook 通知收到确认消息。
We’ve moved all Messenger permissions to the Permissions and Features page.
We've consolidated this into one Permissions and Features page for Business apps, where you can see what access levels you have for each permission and feature.
Yes, developers may opt out of the Business app type and return to the previous App Review process for their app by selecting “Change App Type” on the App Dashboard. However, developers may not opt back into the Business app type and will need to create a new app to do so.
Additionally, apps previously in Development Mode that opt out to the legacy experience that have been approved for Advanced Access via App Review in the new model will lose access to data beyond what their business or anyone with a role on their app owns until they turn their app to Live Mode.
No.
We have replaced Development and Live Mode with Standard and Advanced Access. Standard Access is always active and allows you to access data that a developer’s business or anyone with a role on their app owns. You may submit for App Review for permissions and features to access data owned by other businesses or people. Refer to our Access Levels document to learn more.
To access one of these fields, you will need to submit for Advanced Access for the Business Asset User Profile Access feature through App Review.
- 应用迁移至其他未认证的公司。在这种情况下，所有之前获批的权限都将被封锁。
- 如果应用之后迁回已认证的公司，这些权限将解除封锁。
- 应用被标记为为其他公司提供服务，但之后迁移至未经认证的其他公司。
Yes, ALL apps that leverage permissions that require review (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions, Marketing API and Lead Ads API) must submit for app review in adherence with the communicated deadlines.
Active apps that leverage permissions with an August 1st deadline (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions) and have not yet proactively submitted for review will be auto-enrolled in the review process. You can accelerate the App Review process by submitting your app for review prior to auto-enrollment. This will give you more control over when your app is reviewed and what information is used for the review.
是否需要接受应用审核取决于应用编号的级别。必须提交使用这些权限或功能的所有应用，以接受审核。
Yes, if your apps have made calls to the Graph API in the last 28 days as of July 31, 2018 and require access to the reviewable permissions with an August 1st deadline, your app will be auto-enrolled in the app review process. We will notify you when we have a process available to send us the additional information needed to complete the review process.
As we announced earlier this year, all apps accessing the Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, and Facebook Login were expected to submit for app review by August 1.
To help protect the integrity of our platform, we have removed API access for apps that require these permissions, have not gone through app review, and have not been active within the last 28 days as of July 31, 2018. If you still need access to our APIs, we encourage you to submit for review through your app's App Dashboard.
All active apps that require these permissions will be auto-enrolled in app review in the coming weeks. Developers will be notified if we require additional information to complete the app review submission. If responses are not received in the allocated timeframe, reviewable API access will be disabled.
如果您当前提交的内容需要补充信息，您可以在收到请求后的 30 天内解决并重新提交审核。在这 30 天内，应用审核团队可能会要求您提供更多信息。请注意，在此期间，这个 30 天的期限不会随着每次重新提交而重置。
如果客户同时也是应用的“所有者”，则他们需要以直接开发者身份完成审核流程。如果客户的第三方开发者是应用的“所有者”，则应用的开发者需要接受审核。
您需要请求 leads_retrieval 和 pages_manage_ads 权限。
应用审核流程针对需要某些 API 权限的应用。请在此处阅读文档，了解通过审核方能取得的权限。设置 SDK 本身不需要应用审核。但是，SDK 确实支持应用对 Facebook API 进行调用，而如果此类 API 需要审核，则应用需要提交以接受应用审核。
如果您已有商务管理平台帐户，建议您将应用关联至已有的商务管理平台。
如果您的多个商务管理平台帐户隶属于同一公司，建议您确定拥有多个商务管理平台帐户的原因，并将应用关联至最适当的商务管理平台。如果公司通过商务管理平台设置了信用额度，建议您将应用关联至有信用额度的商务管理平台帐户。
如果存在开发者想要我们使用的其他配置、白名单或测试用户个人主页信息，开发者可提供特定的测试用户帐户。如果他们不提供测试用户帐户，我们仅会使用自己的帐户。字段应标记为可选字段，即使未填写，也不应阻止它们。
每个应用都必须接受应用审核。我们建议您查看应用面板，了解需要审核的具体权限清单。
每个商务管理平台需要完成一次公司验证。如果您选择将所有应用与同一个商务管理平台关联，则只需进行一次公司验证。
应用应与对其拥有最终所有权且可访问其生成数据的公司的商务管理平台相关联。应由此公司完成公司验证流程。
在应用面板的应用审核选项卡中找到公司验证面板，在公司验证面板中可以随时查看公司验证状态、合同以及要采取的步骤。我们将在整个过程中向您发送通知，以便您了解需要采取的操作。
You need to initiate app review before August 1, 2018 for these APIs: Pages API, Groups API, Events API, Instagram Platform API, Messenger Platform, Business Manager API, and Facebook Login.
You need to initiate App Review before February 1, 2019 for these APIs and features: the Marketing API and the Lead Ads Retrieval feature.
在审核过程中，我们可能会要求您提供公司信息，例如公司的法定名称、地址和电话号码。此外，您可能还需要提供业务文档，例如，水电费账单、营业执照、公司注册证明或公司章程等。
Same as other permissions, you will lose access.
自 2018 年 8 月 1 日起，您只需验证与应用关联的商务管理平台即可。
随着新的 API 投入使用，您需要通过应用审核请求这些 API。但是，每个商务管理平台实体仅需进行一次公司验证，因此，为应用请求新的权限或 API 时无需再次进行公司验证。
所有调用 Facebook 登录扩展权限和 6 个 API（主页、Messenger、商务管理平台、Instagram、小组和活动）的现有应用都需要提交到新的应用审核流程，该流程包括公司验证和合同签订。无需在此日期前完成应用审核，只需完成提交即可。如果在 2018 年 8 月 1 日前未完成提交，则从 2018 年 8 月 2 日起将无法使用这些 API。
所有调用市场营销 API 和潜在客户信息调取 API 的现有应用都需要在 2019 年 2 月 1 日前提交到新的应用审核流程，该流程包括公司验证和合同签订。
一家公司仅需验证一次。在公司级别，仅需签订一次合同。后续的应用提交会要求接受应用审核，但不需要进行公司验证。
是否需要接受应用审核以应用编号为依据。使用这些权限或功能的每个应用都必须提交供审核。
图谱 API v3.0 中的商务管理平台 API 没有任何变更。需要访问 Business_Management 权限的应用必须接受 Facebook 的审核。
Facebook 的应用审核政策没有任何更改，不会影响使用 Facebook 市场营销 API 的应用。有关对实际 API 的更改，请查看图谱 API 更新日志。
是。如果不进行应用审核，则应用仅可访问用户的名称、电子邮件地址，以及个人照片。其他所有权限均需接受 Facebook 的审核。
Instagram API 不受图谱 API v3.0 的影响。但是，所有使用 Instagram API 的应用都需要接受 Facebook 的审核。
在图谱 API v3.0 中，访问活动的应用需要使用 user_events 权限。使用该权限的应用需要接受 Facebook 的审核。
user_managed_groups 权限已在图谱 API v3.0 中停用。应用可使用新的小组 API，以及 publish_groups 和 read_groups_user_data 权限作为替代。新的 API 和权限要求应用接受 Facebook 的审核
publish_actions 权限已在图谱 API v3.0 中停用。应用仍可通过网页上的 Facebook 分享对话框或 iOS 和 Android 分享表等中介体验发布动态。应用可以通过 publish_groups 权限将相关内容发布到小组，这需要应用接受审核。
是。在 v3.0 中，所有 Messenger 平台 API 都包含在 Pages_messaging 权限下，需要接受审核。
是。访问公共主页内容的应用需要请求“主页公开内容访问”功能，并要接受 Facebook 的审核。
在审核期间，我们的审核团队会按照您的说明，重现在应用内使用相关权限的体验。如果我们无法重现此体验（例如，因为无法按照您提供的说明操作或无法登录应用），则无法批准对应的提交材料。
为避免出现这种情况，请：
- 提供使用相关权限且可运行的应用版本
- 确保“添加备注”部分的说明清晰明确
- 确保所请求的登录权限能够为用户提供个性化体验，且遵循我们的原则
特别要注意的是，对于 publish_actions 权限，请务必正确配置应用的发布功能。因为在审核过程中，我们需要将应用内容发布至 Facebook。
应用审核流程包括在各个受支持的开放平台上加载应用，通过 Facebook 登录，以及使用您在审核中请求的每个 Facebook 集成。这通常会造成所谓的“常见问题”，这些问题通常是与加载应用、登录应用或应用的一般功能相关的错误或漏洞。这意味着我们无法测试您在提交材料中请求的权限。
由于这些问题会阻止我们审核您集成的 Facebook 功能，所以我们不能详细评论您的应用使用所请求的 Facebook 功能的方式。因此，我们会拒绝您的请求，并标注为“常见问题”，同时针对各个开放平台提供相关反馈。
如果收到“常见问题”导致的拒绝，请仔细阅读所有反馈。我们会针对每个开放平台提供单独的反馈，说明在审核过程中遇到的问题。
审核员会在反馈消息中清楚说明应用未获得批准的原因，以及您接下来应该采取的措施。我们希望能够帮助您尽快完成此流程，因此请务必仔细阅读此反馈。作出必要更改后，您可以重新提交应用以接受 Facebook 审核。
如果应用以违规的方式使用权限，反馈将会清楚说明，且您不应重新提交以接受审核。
要让应用通过审核在应用中心上架，应用必须满足我们的资格要求。在 Facebook 应用中心上架的条件是：应用必须采用 Facebook 登录方式，或者使用 Facebook Canvas 开发。
以下应用符合在 Facebook 应用中心上架的条件：
- 使用 Facebook Canvas 开发的应用
- 分别使用 iOS 版 Facebook 登录或 Android 版 Facebook 登录的 iOS 或 Android 版移动应用
- 使用 Facebook 登录的网页应用或移动应用
此外，您使用的文本素材和推广图片还必须符合我们的守则。
激励用户使用社交插件或为主页点赞属于违反开放平台政策第 4.5 条的行为。这包括根据用户是否赞了某个主页而提供奖励或者控制应用或应用内容的使用权限。以上用途的 User_likes 权限请求不会获得批准。
为确保高品质的关系网络，同时帮助商家面向重要用户推广业务，我们希望用户为主页点赞是因为他们自身想要与商家联系并获取业务信息，而不是被人为的激励机制刺激的结果。我们坚信此政策能够为用户和广告主等群体带来益处。
为完成审核，我们的审核团队可能需要您额外提供应用的登录凭证。
如果您的应用在 Facebook 登录之前或之后需要二次登录，请务必提供二次登录流程需要的帐号和密码。这可能包括测试或演示服务器、应用二次登录或电子邮箱注册流程的登录凭证。
托管于暂存或开发服务器上的应用可能需要额外的登录才能访问您的服务器。所以，请同时提供此流程必需的所有登录凭证。
如果您仍然不确定缺失了哪些凭证，可以在下一次提交时提供视频，展示提交以接受审核的 Facebook 登录选项和所有相关 Facebook 集成。
为审核您的应用提交材料，我们的审核团队需要登录您的应用并检查所有 Facebook 集成。
如果审核员无法加载或使用您的应用，请确保：
- 应用网址可公开访问，且未配置为本地主机
- 已提供访问您的开发或暂存站点所需的帐号和密码
- 站点的安全证书是最新证书，且不会对新用户产生错误
- 您可以通过新创建的测试用户登录和使用自己的应用
- 您提交以接受审核的项目已构建完成，且能够在您的应用中正常运行
如果您再次因为相同的原因未通过审核，则应更新审核说明或添加备注部分，以要求审核员提供更多详细信息。
我们的审核团队会使用您提供的说明测试应用的 Facebook 集成。
如果您认为我们的审核员错误地拒绝了您的应用，您应当更新审核说明，为审核员提供更多信息，然后重新提交应用供他们审核。
审核流程是与审核员沟通联系的最佳方式。请更新说明，解决所收到的反馈。
不需要，权限请求获得批准后，您就可以在任何开放平台上为应用的任何版本使用权限。
即使在新的开放平台上扩展并开发应用，也无需再提交权限请求供 Facebook 审核。只有当您想要请求新权限时（例如，向应用添加新功能时），才需要重新提交以接受审核。更改和提交应用详情或开放图谱操作不会影响已通过审核的权限。
对于使用 Facebook Canvas 的游戏应用
您可以通过以下两种方法邀请新玩家玩您的游戏：
- 请求对话框。如果使用请求对话框，则您可以设置“filters=app_non_users”筛选对话框，这样邀请消息便会仅显示给未使用应用的人。如果您的应用使用 Canvas，您还可以使用 iOS 和 Android 版请求对话框。
对于未使用 Facebook Canvas 的应用
您可以使用 iOS 版消息对话框和 Android 版消息对话框，或网页版发送对话框。这些产品让用户能够直接向其好友发送包含应用链接的消息。
此类消息是直接与小部分用户沟通的绝佳方式。“消息”对话框和“发送”对话框都包含预输入，方便用户轻松选择接收邀请的多名好友。
审核员只有在确认您的应用能够根据用户提供的点赞信息为用户提供个性化体验后，才会批准 user_likes 请求。因此，我们的审核团队会通过不同的测试用户（每个测试用户都有不同的兴趣爱好）测试您的应用。
提交 user_likes 请求时，您应该提供包括以下要点的详细说明：
- 清楚说明请求 user_likes 权限的原因，以及使用此权限改善用户应用内体验的方法。
- 提供示例主页列表，以便审核员点赞，从而验证 user_likes 的使用方式。请在审核员测试您的应用之前，提供指向要点赞的主页的直接链接。
如果将 user_likes 用于算法内，审核员就必须查看此算法的结果，以及此算法如何影响用户看到的内容。
您需要清楚准确地说明在应用内测试每个权限或功能的方法，以便我们能够确保各个权限或功能正常运行并遵守我们的政策。如果我们无法全面地测试应用集成 Facebook 的方法，就无法批准应用。提供详细的说明有助于提高一次性通过审核的可能。
应针对您请求的每个权限分步列出体验的重现说明。所有说明必须使用英文。
您的说明不得：
- 引用其他提交材料或文档中的说明
- 总结应用进行的操作，而非提供说明
- 提供 API 运行原理的技术详情
以下是分步说明的优秀示例：
- 按下左侧菜单中的“设置”按钮。
- 选择使用 Facebook 登录
- 完成第三步
- 完成第四步
如果您仍然不确定应该提供哪些内容，请在“应用审核”的示例部分查看更多示例。
由于审核流程有所更改，且预计提交量较大，您提交的应用可能需要数周时间才能完成审核。
请尽量提供对审核员有帮助的信息，包括清晰的截图、详细的分步说明、应用及其 Facebook 集成的录屏视频。
使用社交插件、分享对话框和共享表等中介共享产品或部分 Facebook 登录的应用不必接受 Facebook 审核。如要详细了解需要审核的对象，请查看我们的应用审核文档。
我们会审核您的应用，以确保高品质的跨应用 Facebook 体验。总之，用户必须对他们正在登录 Facebook 以及发帖至 Facebook 知情。用户应能控制其与应用分享或分享回 Facebook 的信息。
注意：应用的“身份”选项卡所列的用户可以获得扩展权限（例如，user_posts），无需接受审核。但是，当应用公开上线后，其必须接受应用审核才能获取应用中有特定身份的用户的信息。
当应用处于开发模式时，所有应用功能都应可用，但您只能访问自己的数据、测试用户的数据或您的主页数据。如果想让应用公开上线，即使您是唯一用户，您的应用也必须通过应用审核。
如果通过 /BUSINESS_ID/pages 请求商家的主页列表，无法请求主页的所有字段，且 API 可能以此错误信息来响应：(#100) Unknown fields: <FIELD_NAME>。
这是因为此端点不会像其他类似端点一样返回主页对象，它还包含尚未通过审核的待定请求等。正因为如此，无法使用字段扩展来从主页返回字段。
您可以使用 <BUSINESS_ID>/owned_pages 或 <BUSINESS_ID>/client_pages，这两个端点应该都能够返回主页对象并支持字段扩展。
若要向已验证主页发送请求，Facebook 合作伙伴经理必须对商家进行配置，使之能向主页关联的组织发出此类请求。没有 Facebook 合作伙伴经理的商家将无法发出此类请求。
您必须分开确认公司所管理的各个应用的数据使用情况。
管理大量应用的开发者可选择一次性完成多款应用的数据使用情况检查。前往应用面板中“我的应用”页面，即可进入此流程。在这里，您将看到您担任管理员的所有应用，还能筛选出一个子集（例如仅显示需要进行数据使用情况检查的那部分应用），并完成数据使用情况检查。
您需要完成所管理的各个应用的数据使用情况检查（每个应用可拥有多项权限）。您可按照自己希望的顺序分开确认各个应用的数据使用情况，只要您在各个应用的截止日期之前完成此流程即可。
系统会提示您确认所有可用权限的使用情况。但是，如果发现自己不再需要某些权限，您可以移除这些权限，届时您将无需再确认其使用情况。
上线模式和开发模式是应用的两种模式，可对应用功能和数据使用情况检查产生影响。开发模式通常用于测试和探索 API 产品/权限以及完成应用审核，处于开发模式的应用无法调用用户层级的数据。上线模式用于实际使用环境，不会限制应用在应用审核中已获准使用的数据/权限。只有处于上线模式的应用才需要完成数据使用情况检查。
一般来说，对于拥有相同管理员的应用，我们会尽量将其截止日期归为一组管理，在这种情况下，这些应用拥有相同的截止日期。但在一些例外情况下，某些应用管理员需要在多个不同的截止日期完成该流程。例如，某款应用如果创建于其他应用已完成数据使用情况检查之后，则其每年的检查截止日期会与其他应用不同。
前往应用面板中“我的应用”页面，即可查看需要完成数据使用情况检查的所有应用。在这里，您可以查看您管理的所有应用，并将需要完成数据使用情况检查的应用筛选出来。
任一应用管理员均可确认应用的数据使用情况。若应用设有多位管理员，只需其中一位进行确认即可。
自流程开始（当您收到第一条开发者提醒通知时）直至截止日期，您有 60 天的时间完成此认证流程。
截止日期之后，我们将在此后一个月内限制 API 调用，借此开始撤销您的应用对开放平台的使用权限。在此期限内，您可以前往应用面板并完成数据使用情况检查，让您的应用恢复合规状态，完全恢复对开放平台的使用权限。但一个月过后，我们将全面撤销您的应用对开放平台的使用权限。
您仍可返回应用面板，完成数据使用情况检查，并恢复权限。但我们会定期回收不活跃应用中长时间未使用的权限，这表示停用一段特定的时间后，相关权限可能会被永久移除，届时如需重新获得权限，您将需要提交应用审核请求。建议您在截止日期之前完成数据使用情况检查，以免出现这种情况。
数据使用情况检查版块会展示您的应用拥有的所有权限，不论您是否经常使用它们。建议您利用这项功能来评估集成情况，深入了解应用功能，移除不需要的任何权限。
由系统自动授予的某些基本权限使用广泛，可提供用户数据的访问权限。为此，我们要求开发者确认它们的使用情况。不过，即使您并未使用这些权限，仍应完成这一流程，这是因为通过认证即表示权限的所有使用情况均合规，其中包含权限未被使用的情况。
不用。在应用面板中移除权限后，您可以刷新“数据使用情况检查”页面，届时已移除的权限应会消失。
您必须就应用拥有的所有权限完成数据使用情况检查。
我们将分阶段启动数据使用情况检查，您应在未来几个月里完成此流程，但具体截止日期不尽相同。请务必及时更新应用面板上的联系方式，并查看开发者提醒通知，了解具体的截止日期。
In order to comply with certain legal obligations, Meta’s developer services may not be available in all locations, including countries and regions currently subject to U.S. sanctions prohibitions.
Meta’s services are not available in all regions.
Registration reviews may take longer and you may be unable to access our service during that time. Please try again in a few days. For more information, please refer to Meta’s Terms of Service.
We are currently reviewing your registration details. This takes 24 to 48 hours. Once completed and approved, you may be able to login and complete your registration.
您无法删除已获批准用于应用中心的屏幕截图或横幅图片。要将这些图片替换为新图片，请点击屏幕截图或横幅上的“编辑”，并选择替换图片。
检查您在未发出用户照片请求时是否能够看见错误消息，并验证最初的错误消息是否可见。 然后继续发出 API 请求 me/photos，然后返回检查是否仍然能够看见错误消息。 在测试 me/photos 调用时，确保您使用的是预期应用，并获得正确的访问口令（此口令需要 user_photos 权限），之后您就准备就绪啦！
此检查的目的是确保开发者在向我们请求相同权限之前已经全面测试其应用内的相关功能。在测试应用内测试相关功能并不能保证主应用内有相同的稳定行为。我们需要您通过主应用发出测试请求，以确保您能够先看见其如预期运行，然后再对外面向受众启用。 请按照提供的手动请求步骤操作，并检查确保您的面板上不会再出现此警告。
“信息流帖子网址保护”迁移会阻止您的 Facebook 平台应用发布未指向应用域名的任何网址。如果您的应用会向其他网站发布链接，请不要开启此选项。
这是预期行为（详情请参阅相关文档 https://developers.facebook.com/docs/apps/test-users#rules）— 测试用户无法成为 Facebook 公开主页的关注者，也无法在这类主页上创建内容，例如在主页的涂鸦墙上留言。但测试用户可以查看与相关应用关联的主页上的任何应用选项卡，以及与这些选项卡互动。
这是有意的。出于安全考虑，我们禁止输入多个任意域名。
这是预期的行为。登录对话框使用的是固定宽度，不会为适应更大的屏幕而扩展。
这是预期行为。由开发者负责根据用户的设备设置适当的“redirect_uri”，所以，如果用户使用移动设备，则“redirect_uri”应该是移动网站的网址。
这是预期行为，因为这可以防止可能存在的安全漏洞。一些浏览器会将网址中的散列片段附加到新网址的末尾，这个新网址是浏览器被重定向前往的网址（如果新网址本身没有散列片段）。
举例来说，如果 example1.com 返回前往 example2.com 的重定向链接，则前往 example1.com#abc 的浏览器就会前往 example2.com#abc，且 example1.com 中的散列片段可供 example2.com 上的脚本使用。
由于可以将一个身份验证流程重定向至另一个身份验证流程，所以一个应用中的敏感验证数据也可以在另一个应用中使用。向重定向网址附加新的散列片段，防止这种浏览器行为，从而降低上述风险。如果所生成的网址的美感或客户端行为非常重要，则可以使用 window.location.hash（或您自己的服务器端重定向）删除违规字符。
Test apps created from Business apps will have Standard Access for all permissions and features.
No. The access level model only applies to permissions and features.
No. For a given permission, Business apps have either None, Standard, or Advanced Access.
Yes. A Business app will be auto-granted Standard Access and may request Advanced Access for a given permission.
Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.
要分享网址，相关的图片必须至少为 200x200 像素。如果不符合这个条件，您就会收到如下所示的错误消息“Provided og:image is not big enough.Please use an image that's at least 200x200 px.”（所提供的 og:image 尺寸不够大，请使用至少为 200x200 像素的图片。）
为网址选择图片时，我们首先会检查您的“og:image”标签，查看其是否存在，以及是否达到至少 200x200 像素的要求。如果“og:image”标签不存在，我们就会选择在网页中看到的第一张图片。
如果您收到错误消息，但您认为网站图片的尺寸大于 200x200 像素，则应该检查您是否正确设置了“og:image”标签，因为最可能的原因是我们从您的网站检索了错误的图片。
我们更改了分享插件的行为，以便与 Facebook 平台上的其他插件和功能一致。
分享插件将接受自定义参数，且 Facebook 会从网址 OG 元标签中将要展示的信息加入预览，其方式与这些信息作为帖子展示在 Facebook 的方式相同。
不可以，无法改写已分享网址的“caption”，只能更改“title”和“description”。
应用无法向其他应用创建的相册上传内容。
在某些情况下，存在不与任何应用关联的相册（涂鸦墙照片相册）。我们建议检查 can_upload 字段。如果 can_upload 字段返回 false，则表示用户无法通过其个人主页上的“相册”视图直接将照片添加到此相册。
行动号召会在视频播放结束后显示在“重播”图标下。
GIF 的大小必须小于 8MB 才能在 Facebook 中播放。
目前尚不支持通过 API 评论未发布的帖子。
内联创建的视频帖子不会显示在“promotable_posts”端点内，因为这些帖子已经被推广。内联创建的视频帖子是指，在广告创建流程内创建的帖子，因此无法单独速推。
所以，内联创建的帖子不显示在 /promotable_posts 端点内是预期行为。
如果您使用主页访问口令，而与口令关联的用户在主页“设置”下的“主页用户身份”版块显示为分析员，就会出现这种情况。
使用图谱 API 发出数据请求时，会应用各种隐私规则，这会导致某些数据不会返回，即使这些数据可以在网站中查看。这取决于用户隐私设置和应用级别权限等各种因素。这意味着通过 API 返回的数据不一定会包含网站上看见的所有数据。
如果帖子的分享次数超出 10 次，就会返回 shares 字段。如果帖子的分享次数不足 10 次，系统就会省略这一字段或尝试返回一个数字。
如需详细了解此端点，请访问以下链接：https://developers.facebook.com/docs/graph-api/reference/v2.4/post。
这是在旧版机制中使用的旧值，我们在移动至新版机制时保留了反向兼容性。
这种情况会发生在以前创建的帖子身上，不会发生在近期创建的帖子身上。
这是预期的效果。帖子和其中的照片没有连接。系统只会返回帖子中上传的第一张图片。
如果帖子属于 Facebook 网站或移动应用，就不会返回“application”字段。这类帖子与网站对应，相关网站不会显示这类帖子的属性。
帖子的“privacy”字段会包含帖子在 Facebook 的可见性的信息，但如果主页帖子仅定位或限制对某特定的受众群可见，“privacy”字段的信息就不会显示所有选定的定位选项。
要查看帖子的定位选项或限制条件的完整详情，请检查“targeting”字段（限制）和“feed_targeting”字段（动态消息定位）。请参阅帖子文档，详细了解可用的字段。
返回的帖子的 comment_count 值可能包含被隐藏或删除的评论。帖子的可见评论数量绝不会超出 comment_count。
无法改写已分享网址的“caption”。您只能改写对应网址的“title”和“description”。
如需更多信息，以及了解您可以通过图谱 API 发布的字段，请点击以下链接参阅 /feed 文档：https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish
这是有意的设计。这符合 Facebook 应用（移动版或网页版）发布的内容的展示方式（未归因为 Facebook 本身）。
我们对通过 API 检索和呈现信息流和帖子数据的方式发生了更改。
如果您在通过 API 获取帖子时遇到问题，并认为过程的运行方式与文档记录的不同，请检查以下方面：
- 您使用的访问口令有适当的权限，能够访问您需要的帖子。
- 请确保您为检索帖子发出的所有 API 调用都使用的是之前调用中向您返回的“id”，且您未手动创建主页编号、用户编号或其他编号。
这是有意的。对于已被删除或对 privacy/permission 检查不可见的对象，我们的系统会返回上述错误消息。
这是预期行为，因为评论不支持这种形式的分页。
端点 /{user-id}/accounts 的摘要参数的 total_count 字段可能会返回高于预期的数值。这是因为 total_count 还包括由用户担任管理员的所有已删除主页。
但是，端点本身返回的数据将仅包含未删除的主页。
/user/likes 端点已从时间分页方式（使用“since”和“until”作为参数）更改为游标分页方式（使用“before”和“after”参数）。
您可以参阅以下链接，详细了解这两种分页方式的区别：https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging
采用应用范围用户编号后，我们对端点返回数据的方式做出了更改。
由于 v1.0 已被弃用，所以我们会专注于 v2.x。/v2.0/{id} 可能会返回 https://www.facebook.com/{id}，也可能会返回 https://www.facebook.com/app_scoped_user_id/{id}。
这是有意的。此错误消息表示，您尝试扩展的访问口令无法访问尝试扩展对应口令的应用编号。
最可能的原因是，您的应用具有人口统计数据限制，而我们检测到您尝试扩展的访问口令所属的用户不符合这些限制（或不再符合这些限制，他们可能移动了位置或我们现在检测到这些用户更准确的位置）。
较为可能的原因是，我们无法确认用户是否符合相关要求（例如：我们不知道他们的位置），以及您的应用限制条件不允许这些用户访问您的应用。
关于“User”对象的“email”字段的文档以下面的话说明了这里出现的预期行为，即：“this field will not be returned if no valid email address is available”（如果没有可用的有效电子邮箱，此字段就不会返回）。
很多时候，您可能会认为 user 对象会返回电子邮箱，但实际并不会返回。由于隐私和安全因素，我们无法详细说明未返回任何特定用户的电子邮箱的准确原因。
一些可能的原因如下：
- 帐户未关联电子邮箱
- 帐户未关联经确认的电子邮箱
- 帐户未关联经验证的电子邮箱
- 用户输入的安全检查点要求他们重新确认电子邮箱，但他们尚未进行确认
- 无法获得用户的电子邮箱
这些帖子无法通过 API 获取，这类帖子中的用户内容是在主页中获得重新分享，且相关用户未向应用授予查看其内容的权限。
如果用户没有适用于帖子内容类型的基本权限，则此用户在主页时间线分享的帖子就无法通过 API 获得。
作为解决这一问题的权宜方法，您可以使用主页访问口令获取主页的相册 — 相关照片应位于“时间线照片”相册
在以下情况下，某些应用（或任何应用）因 Facebook 用户的隐私设置而无法获得任何关于这些用户的信息 — 包括在您的应用预期能够看见的情况下，访问由该用户创建的帖子时（例如：主页管理）
例如，当用户屏蔽应用或禁止所有开放平台应用通过 API 获取他们的信息时。
图谱 API 2.1 发布后，此功能已被删除。对于在 2014 年 8 月 7 日之前创建的应用，这一字段不会再显示于 signed_request 内。
对于在这一日期之前创建的应用，liked 属性会始终返回 true，无论用户是否赞了对应主页。
请直接使用响应中返回的 paging.next 和 paging.previous 链接获取其他结果页面。使用提供的链接可确保您的应用不会在今后分页链接格式有所更改时崩溃。
与 API 的大部分条目一样，并非完全 1:1 对等映射 Facebook 主网站上的特性和功能。主页成效分析界面的“自然覆盖”版块非常不同，且统计方法与通过 API 获得的自然覆盖也不相同。
例如，主页成效分析用户界面中的“organic”（自然）值对应通过 API 可用的 page_impressions_by_paid_non_paid_unique 指标中的“unpaid”（未付费）值。
我们正着手于匹配这两个值，但可能需要一些时间。
此错误消息表示，与访问口令关联的用户因隐私原因无法查看此主页。例如，相关主页可能被取消发布，对应的用户也不是主页的有效管理员。
通常，在您尝试获取非常活跃的主页的成效分析时，就会出现此错误。如果使用“since”和“until”字段减小请求的成效分析的时间间隔，此问题就得以解决。
只有管理员、编辑或审核员才能读取和发送主页消息。其他身份的用户（如广告主管和分析员）无法读取主页对话。
如需详细了解各种主页用户身份，请访问此帮助页面： https://www.facebook.com/help/289207354498410。
“page_fans”和“page_fans_country”的总数量并不一定始终相同。有许多因素会影响“page_fans_country”的值。例如，一些主页关注者可能未在帐户中设置所在国家/地区，或一些主页关注者可能设置了隐私设置，隐藏他们所在的国家/地区。
如需详细了解 Facebook 隐私设置，请访问帮助中心的以下页面：https://www.facebook.com/help/445588775451827。
一些公开帖子是从用户内容重新分享产生的。如果创建帖子的用户未向应用授予必需的权限，应用就无法通过图谱 API 访问对应的帖子，因此也就不能评论这些帖子。
在广告创建流程中内联创建的帖子无法被单独速推。所以，这类帖子也不会显示在对主页端点 /promotable_posts 的调用中。
如果您使用仍处于开发模式的应用来排期帖子，就会出现这种情况。请使用已经上线的应用，此功能就会正常运行。
很抱歉，我们暂时不支持通过 API 创建、更新或删除封面照片。
如需详细了解封面照片 API，请访问 https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating
不可以，无法通过图谱 API 编辑主页选项卡的宽度。
这是目前的行为。主页管理员无法通过图谱 API 以其用户身份向主页发帖，此功能仅对 http://www.facebook.com/ 和我们的移动版应用开放。
不可以，无法获取为主页点赞的用户的完整列表。这是有意的设计。
以主页身份执行操作时，请确保您使用的是主页访问口令。此错误消息表示您使用的是用户访问口令，而不是主页访问口令。
如需了解不同类型的访问口令，请访问以下链接： https://developers.facebook.com/docs/facebook-login/access-tokens
无法获得，因为置顶帖子和读取置顶帖都只能用过原生的 Facebook 产品实现。
如果针对外部网址打开了评论同步功能，则会针对网址本身记录评论被同步的帖子所获得的心情，并会在调用 {URL-id}/reactions> 时返回相关心情
目前不支持拉取 /app_insights/app_event 端点超过 1000 个细分数据值的数据。如果您有兴趣将数据细分为特定类别，我们建议使用 Facebook 分析 UI 将其分割为特定数据点，例如特定国家/地区。
这有可能是因为您过快调用端点，而数据甚至尚未传播到我们的服务器。
应等待 1-2 秒后再执行 API 调用，让信息能够传播到所有服务器。
“page_fans_country”指标通常是 page_fans 计数的子集。只要我们能够准确确定用户所在的国家/地区，此指标就是按国家/地区细分列出的主页关注者数量。
此外，该指标仅针对主页关注者数量靠前的国家/地区，而不是关注者所在的所有国家/地区；对于关注者分布于许多国家/地区的主页，关注者最少的国家/地区不会纳入在此指标中。
图谱 API 不支持使用偏移分页方式。
相反，您应该使用“paging”（分页）链接（在图谱 API 的每个响应末尾返回）或使用“cursor”（游标）分页方式，后者是首选方案。
如需详细了解如何通过图谱 API 正确地分页，请访问：https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging
这是预期的行为，搜索 API 会遵守 Facebook 的隐私设置，专为持有您所使用的访问口令的用户量身定制，不支持对 # 标签的搜索，且其设计意图也不是为了与 Facebook.com 上的预输入搜索机制相同。
我们明确表示，不支持搜索 API 与 Facebook.com 返回相同数量的搜索结果或相同数量的特定搜索结果，也不会以此为目标 — 一般来说，相较于 Facebook 上的同类帖子，通过 API 返回的帖子受限于更多限制性隐私和安全检查。
我们的系统对应用发出的 API 调用量强制设定了上限。如需详细了解各种限制并防止应用受到限制，请访问 https://developers.facebook.com/docs/marketing-api/api-rate-limiting
您可以在不同的主页上重复使用同一个源网址，但请注意，系统只会采集权威链接与相关主页所认领的域相匹配的文章。
我们建议对各个主页使用单独的 RSS 源，且该源应仅包含会被各主页采集的文章。
如果文章是草稿模式，则只有主页管理员才能以即阅文的形式查看此文章。文章发布并处于已发布模式后，则任何 Facebook 用户都可以分享此文章，且所有人都能以即阅文的形式查看此文章。
如果使用 dir="rtl" 属性在文章中显示从右到左 (right-to-left) 语言，那么您可能是在不支持即阅文从右到左 (right-to-left) 语言的应用中查看文章。
请确保您使用的是最新版应用。支持从右到左 (right-to-left) 语言的各应用的最低版本是：
- iOS 版 Facebook：52.0
- Android 版 Facebook：69.0
- iOS 版主页管理工具：44.0
请检查是否在文章的 <body> 标签中设置了 dir="rtl" 属性。如果文章未使用从右到左 (right-to-left) 语言，则不应该在文章中设置此属性。
如果在即阅文发布之前分享文章的网址，该网址就会重定向至文章的移动网页版。即阅文发布后，之前所有的链接分享（包括在即阅文发布之前发布的链接）都将在移动设备上自动显示为即阅文。
Android 版主页管理工具尚不支持开发源。作为目前在 Android 设备查看文章的权宜方法，您可以尝试以草稿形式向生产源添加文章。
要编辑即阅文，您可以使用主页界面。为此，您可以在浏览器中前往主页，并找到“发布工具 > 即阅文”。您可以在这里查看并编辑即阅文。详情请访问以下链接：https://developers.facebook.com/docs/instant-articles/publishing。
目前，源下载的超时时间为 30 秒。
不可以，分享的链接必须是文章的权威链接。如果网址有所更改（如添加参数），则将被视为不同的网址。
采集 RSS 源时发现的任何错误或警告都会显示在设置页面的“即阅文”选项卡中。您还可以查看个别文章的警告和错误，只需在发布工具页面的即阅文选项卡中点击对应的文章即可。
系统会尝试在 10 秒内完全加载并分析 RSS 源。这一错误表示此过程失败。
解决此错误的一个方法是，在 RSS 源中添加 less（小于）项，例如只添加在过去 10 分钟之内新发布/更改的文章。由于系统会每 3 分钟提取一次源，所以无需添加未更改的文章。
很遗憾，我们没有针对爬虫的静态 IP 地址列表。但您可以使用 Facebook 爬虫的用户代理：facebookexternalhit/1.1
请检查重复的文章是否使用了不同的权威链接。我们将文章的权威链接用作其唯一标识符，所以拥有不同权威链接的文章将被视为不同的文章。
这个问题的常见原因是，您的内容管理系统可能向具有不同网址的文章发布更新，导致更新被采集为新文章。
是的，每个主页都对应一个唯一的域名，这是一种一对一映射关系。 根据我们的要求，属于特定主页的即阅文的权威链接应属于特定域或其子域。
但 RSS 源网址本身的域无需与映射至相关主页的域一致。此限制仅适用于源内文章的权威链接。
如果想要根据主页语言将文章发布到不同的主页，您应该为各个语言设置不同的 RSS 源，并为各个主页配置适当的 RSS 源。
不会，从 RSS 源中采集到文章后，该文章仍然会保存为即阅文，直至通过主页的发布工具将其删除。然后，您可以安全地将其从 RSS 源中删除，以加快进行下一次提取。
目前无法通过 API 发布或删除文章，但我们正着手开发相关功能。
“赞”按钮会使用样式设置中配置的主题色。请检查您配置的颜色在标题中是否显眼。
此外，只有当没有给相关主页点赞的用户查看文章时，“赞”按钮才会显示，即是说，此按钮不会对已经赞过相关主页的主页管理员可见。
请确保您未在一行内使用多个 <br> 标签。要将文章文本拆分为多个段落，我们建议使用段落 (<p>) 标签，而不是换行符。
请确保您已向封装追踪像素的 <figure> 标签添加“op-tracker”类。如果没有此标签，像素将被视为图片嵌入。
此警告通常会在以下情况下出现：您在段落（<p> 标签）内封装了非文本内容，如图片或交互式嵌入内容。段落应只包含正文文本，其他任何内容都应添加到 <figure> 标签或其他适当的容器元素中。
不可以，说明 (<figcaption>) 元素只支持 <h1>、<h2> 和 <cite> 标签。不支持段落 (<p>) 标签。
<video> 元素目前尚不支持“muted”（静音）属性。
即阅文中的广告使用标准的 HTML5 <figure> 元素指定，其中封装了包含广告标记的 <iframe> 元素。您可以将 op-ad 类应用到一个 <figure> 元素，以便在文章中指定广告。有两种方法可以指定广告：使用 iframe 中的“src”属性直接指定广告网址，或在 iframe 中嵌入整套未转义 HTML 和脚本。
如需获取更多广告信息，请点击以下链接：https://developers.facebook.com/docs/instant-articles/reference/ad。
标准的图片元素不支持使用 SVG 图片。您可以使用交互式嵌入内容 ("op-interactive")，并在 iframe 内添加 <img> 元素，同时将“src”属性设置为 SVG 图片的网址。
请点击以下链接，参阅地图元素文档：https://developers.facebook.com/docs/instant-articles/reference/map。这是向即阅文添加地图的推荐方法。
如果以交互式嵌入内容的形式向文章嵌入 Google 地图，则嵌入内容的运作方式存在一个已知问题，可能会阻止地图显示。作为解决这一问题的权宜方法，您需要将加载地图内容 ("https://www.google.com/maps/embed?...") 的 iframe 放入另一个 iframe 中。
您可以使用 op-interactive figure 元素嵌入交互式模块。如需查看更多详情和代码示例，请点击以下链接：https://developers.facebook.com/docs/instant-articles/reference/interactive。
要定义高度，请将“height”（高度）属性添加到封装嵌入内容的 <iframe> 元素中。属性值应为表示高度的整数值，单位为像素。可设置的最大高度为 960 像素。
要在图片之间添加间隔，您可以在其间添加空段落，例如 <p> </p>。
要添加属性，请在 <figcaption> 元素中添加 <cite> 元素。
对于封面图片，您可以将属性指定为始终可见，为此只需在 <cite> 元素中明确指定一个 Vertical Alignment（垂直对齐）属性即可。否则，引用内容将仅在图片展开时才会显示在图片上。
要将视频设为封面，需要使用视频文件（如 mp4 文件）的直接链接。托管于 Facebook 的视频不提供直接链接，因此您需要将视频托管到其他地方，才能将其设为封面。
您可以在列表项中使用一些 HTML 标签，如用于加粗文本或添加链接。要自定义颜色或字体，您可以使用 Facebook 主页界面上的样式编辑器（设置 -> 即阅文）。
如果使用 <video> HTML 元素嵌入视频，则将无法添加视频播放列表，因为我们不支持按顺序播放多个视频。
如果您将视频播放器作为社交嵌入内容嵌入到 iframe 中，则只要嵌入的播放器支持，即可添加视频播放列表。
不支持块引用，块引用需要放置在段落标签之外。
如果文章标题足够长，可以显示为两行，则只有标题会显示在动态消息中。但如果标题只有一行，动态消息还会显示文章文本内容开头的几个字。
要求在每篇文章的 HTML 标记中添加使用 op-published 类的 <time> 元素，以指定文章的最初发布日期/时间。
不要求添加 op-modified 类。如果是更新文章内容，并希望系统更新已保存的文章版本，您只需添加使用此类的 <time> 元素。
请确保未将 <figure> 封装在段落（<p> 标签）内。图片应包含在 figure 标签内，且此标签应直接嵌套在文章标签下。
在指定交互式嵌入内容项的宽度时，请使用整数值表示宽度，并以像素为单位。默认情况下，这些内容项会以全宽显示。
要在显示交互式嵌入内容的同时不显示任何边缘，您可以将“no-margin”类添加到包含内容的 iframe 中。
如果 Facebook 已批准主页的 RSS 源，则无需在更改源网址后重新提交源供审核。
系统会将每个主页映射到唯一的域名。RSS 源的网址无需与此域名匹配。但源内单篇文章的权威链接必须属于同一个域或其子域。如果您只更改了 RSS 源的网址，则不会出现任何问题。
如果您还将文章的权威链接更新为指向新域，就需要通过您的合作伙伴经理请求更新此域，他们可以在整个过程中为您提供指导。
请确保您的 Facebook 应用设置了真实的 iPhone Store 编号、iPad Store 编号（用于测试目的时，不必是真实的编号，您可以使用 Apple App Store 内任何可下载应用的编号）组，并在“应用中心所列平台”中启用 iOS - iPad。
这是有意的设计。动态发布对话框可以发布包含附件的内容，所以无法自定义其他附件。
这是我们的有意更改。为提高游戏请求与合适玩家之间的相关度，我们缩短了好友列表。注意，玩家仍然可以使用“搜索”字段根据需要选择很多好友。
好消息是，做出此更改后，点击量有所增加，总点击率也有显著增加。我们希望能够继续优化这一渠道，并找到新方法，确保能够将适当的游戏呈现给合适的用户。
更改 og:title、og:image 等仅适用于以后对该链接的分享。
用户或主页分享链接，并且相关帖子获得的互动（评论、赞、分享等）超过 50 次后，便无法更改标题。这是为了防止网站更改您互动过的链接的详细信息，让您误以为与不同的内容进行了互动。其他所有属性都可以随时更改。
如果您分享链接并更新了对应图片，则原始分享帖仍然会显示旧图片，除非您在帖子中刷新。
如需刷新帖子中的链接图片：- 前往动态消息中的对应帖子。
- 点击帖子右上角的省略号。
- 选择刷新分享附件。
图片的裁剪方式会受多种因素影响。例如，我们尝试将图片以可以检测到的人脸为中心。
对于大图片，请尽量保持图像的宽高比接近 1.91:1，以便在动态中显示未经任何裁剪的完整图片。
通常在公共主页帖子的链接分享中使用较大的横向格式图像。桌面版和移动版动态中都是如此。尽量确保图像宽高比接近 1.91:1，以便在动态中显示未经任何裁剪的完整图片。
图片将采用异步方式缓存，因此，在用户首次分享您的内容时，图片可能不会显示。您可以执行以下操作之一，避免出现这种情况：
- 使用分享调试器触发采集操作，从而预缓存图片
- 使用“og:image:height”和“og:image:width”标签显式指定图片
小于 600 x 315 像素但大于 200 x 200 像素的图片将显示为一个小正方形。
所有网址都必须是绝对网址，因为它们代表资源（网页/图片）的权威位置，这样我们才能将分享和赞归于正确的网址并正确缓存图片。
由于临时问题，原始图片不再可用、太大或无法调取。确保对应图片网址的访问权限对我们的网络爬虫开放、大小不超过 8mb，且显示时的延迟时间在几秒钟之内。
在更改某个网页的 og:image 标签时，请勿从您的网站上移除旧图片，否则现有的分享将显示此白框。
这是数据中心之间的复制迟滞导致的。此流程需要数秒钟才能完成，在此之前无法通过 API 获取对象编号。
如果尝试在广告完整保存前读取广告的详细信息，您可能会收到 GraphMethodException其中包含类似 Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation. 的消息
在尝试获取广告详细信息前等待片刻应该能够解决该问题。
有时，尝试在特定的广告系列中使用特定的广告创意时，您可能会遇到验证错误。 当广告系列的目标与您使用的广告创意不适配时，就会出现这种情况。 例如，您的广告创意针对一个 canvas 游戏，而广告系列目标是“MOBILE_APP_INSTALLS”（移动应用安装量），就会出现这种情况。
为解决您可能遇到的验证错误，您可以按照市场营销 API 验证最佳实践操作。
请检查以确保未包含提及商品的上传会话没有任何错误。
当 deletion_enabled 设置为 true 时，只有不再存在于成功上传会话的提要中的商品才会被删除。
如果您收到此错误消息，请检查所指定的广告账户的状态。如果广告账户处于“尚未支付”的状态，就会出现此错误。
这是预期行为，因为主页成效分析的数据只会在后端存储 2 年。因此，您发出的请求预计会返回零值。只有帖子的内联赞/评论/分享等指标项不会是零，这些指标项的数据由帖子本身保留。
请检查定位参数的语法，特别要确保定位参数包含有效的 geo_locations 参数和值。
以某些目标创建广告时，将设置默认的转化参数。如果更改转化参数，当前的参数将被覆盖。
请注意，某些目标没有默认转化参数，必须明确指定。
出现这种情况的原因是：您定位的国家/地区的 work_positions 受众规模太小，以致于无法影响预计覆盖人数。我们正在不断收集数据，有望提升添加到 work_positions 排除条件的用户数量，这将会影响预计覆盖人数。
用户可以通过商务管理平台关联账户，这类关联不会显示为显式图谱 API 关联。
请确认您在适当的定位字段中指定了合作伙伴类别。通过“/partnercategories”端点检索的合作伙伴类别包含“targeting_type”字段，此字段用于指定您在指定定位类型时需要使用的定位字段。
例如，如果您的合作伙伴类别返回“targeting_type”为“behaviors”，则您应该在定位参数的“behavior”字段使用此合作伙伴类别。
如需详细了解定位类型及合作伙伴类别，请访问以下链接：https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types
这一错误可能由下列原因导致：自定义受众没有任何包含/排除设置。解决此问题最好的方法是，创建新的自定义受众，并确保设置一些包含/排除条件。
如需详细了解自定义受众，请访问以下链接：https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3。
广告组可以同时使用 daily_budget 和 lifetime_budget。以账户货币指定的 daily_budget 值必须至少为 100 美分，且投放期必须至少为 24 小时。如果您查询任何这些字段，就会返回这两者。如果未使用某字段，就会返回 0 值。
如需详细了解，请访问：https://developers.facebook.com/docs/reference/ads-api/adset。
adcampaign_groups 端点使用的是游标分页方式，所以不会返回 count、limit 和 offset 字段。为获得一致的结果，我们建议对所有端点使用游标分页方式。
如需详细了解如何使用游标分页方式，请参阅以下链接：https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging。
一些帖子可能是内联创建的。要检索这些内联帖子，请参阅以下文档底部关于 /promotable_posts 端点“is_inline”字段的说明： https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec
只要用户回复了第一个问题，消息窗口就会打开。如果用户提供的答案不符合条件，或者用户没有回复，那么广告体验将结束，广告将向目标应用传递对话控制权并提供元数据“messenger_lead_gen_incomplete”，令商家得以回退，将非潜在客户转换为客户。请参阅 线索广告完成后的 HOP（移交协议）Webhooks 获取更多信息。
仅当在广告中的“创建模板”对话框中选择某应用，“发送摘要”才会默认启用。请注意，在选择绑定应用后，摘要可在广告中禁用。即使未选择应用，线索广告也会将对话控制权传递给“移交协议”的主要接收者（如设置），或释放对话控制权。线索提交后，所有跟进消息都将被发送给已订阅的应用。应用可以查询对话 API 以检索消息记录并获取开发潜在客户期间共享的信息。
投放线索广告时，会默认屏蔽发送 API 和 Webhooks。Messenger 线索广告应用（应用编号：413038776280800）将拥有对话控制权。可通过广告中“创建模板”对话框的“屏蔽发送 API”开关禁用此行为。
在线索提交结束后，应用将获取关于用户消息的 Webhooks 并可以进行回复。如果有应用被选中作为此应用的一部分，则只有所选应用可以进行回复并将获取消息渠道的 Webhooks。消息窗口会打开，应用可通过发送 API 进行回复。
使用 Facebook 登录 并向特定公共主页授予 pages_messaging 权限，即可从应用网站安装应用。授权应用将显示在高级消息功能中的公共主页设置。
菜单仅显示公共主页的授权应用。您可以在高级消息功能中的公共主页设置查看授权应用。使用 Facebook 登录 并向特定公共主页授予 pages_messaging 权限，即可从应用网站安装应用。
可以，单个 Facebook 应用可以订阅多个主页。与 pages_messaging 权限一样，在接受应用审核后，应用即可订阅接收多个主页的 Webhook。您可以根据负载情况获取每个 Webhook 的环境。
下面是在 Messenger 平台集成中使用平台测试用户的解决方法：
- 在应用的用户身份页面，点击“添加”按钮，创建新的测试用户。
- 打开为应用授权测试用户？开关，并授予“manage_pages”和“page_messaging”权限。
- 点击“编辑”按钮，获取此用户的访问口令（使用 2.6 版），并保存供日后使用。
- 点击编辑按钮，以测试用户的身份登录。
- 登录后，以测试用户的身份创建一个主页。
- 使用该测试用户的用户访问口令，获取其主页访问口令。您可以通过如下调用实现：
https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]
（文档） - 使用此主页访问口令关联您的 Facebook 平台应用与主页：
https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]（文档） - 按照上述步骤操作后，您会收到测试主页的实时更新，且可以通过测试主页向测试用户发送消息。
除了上述操作外，您还可以将很快就会过期的访问口令替换为长期口令，方便测试。请点击阅读此处的参考文档：
GET /oauth/access_token? grant_type=fb_exchange_token& client_id={app-id}& client_secret={app-secret}& fb_exchange_token={short-lived-token}
发生这种情况的原因有以下几个：
- 您使用的用户编号是通过 Facebook 登录获得的。 通过 Facebook 登录获得的用户编号不能与收发消息 API 兼容。只有通过 Messenger 平台身份验证流程获得的用户编号才能用于 Messenger 平台。
- 您在使用用户编号时，使用了错误的主页访问口令。 Messenger 平台的用户编号是主页范围编号，因此与特定主页关联。如果您使用了有效的用户编号，但所使用的主页访问口令却与另一个主页关联，则调用会失败。请确保您使用的用户编号和主页访问口令均与同一主页关联。
- 接收您所发消息的手机号码近期未经过验证。 您结合使用发送 API 和手机号码时，我们只会向近期经过验证的手机号码发送消息。即使手机号码显示为已验证，但如果近期并未经过验证，消息发送就会失败。请重新验证您的手机号码，并等待 24 小时后重试。
如果使用“发送到 Messenger”插件，您可以使用 data-ref 作为传递参数，发送有关点击情境的任何信息。
用户还可通过 Messenger 中的搜索功能发现您的主页。这种情况下，您不会获得传递参数，但您可以使用帐户绑定功能将对话关联到您网站上的用户帐户。
Messenger 设置内的应用面板提供了名为“显示近期错误”的按钮，此按钮会显示 Webhook 是否收到 200 的响应代码或发生错误。
有工具能显示近期 Webhook 出现的错误。如果系统无法发送 Webhook，则 Facebook 服务器将取消订阅您的网址。如需寻找此工具，请前往应用面板 > Messenger > 设置，您可以在 Webhook 说明卡内找到名为显示近期错误的按钮。
您应确保 Webhook 的响应包含状态代码 200。系统可通过此响应代码判断 Webhook 成功接收。如果未返回状态代码 200，系统就会重新调用，直到成功完成。此外，如果 Webhook 长时间一直未返回状态代码 200，我们就会发送开发者提醒。
另请注意，应及时返回成功状态代码。Webhook 调用若在 20 秒内无响应，即被视为超时。在设计代码时请确保 Webhook 得到异步处理，以便能够立即返回并单独处理成功状态代码。
Webhook 调用的 X-Hub-Signature 标头包含一个字段，可用于验证调用是否来自 Facebook。
分享开放图谱动态并提供主页的 OG 标签时，您无法控制帖子在动态消息或时间线中的展示方式。Facebook 会自动优化帖子，以确保您的内容能够获得最大的参与度。
是的，操作链接功能已被弃用。Facebook 网站已不再支持操作链接，所以此功能也将从平台中弃用。此功能可能会在今后恢复使用，但目前尚未列入计划当中。
如果您的网页使用我们的 OpenGraph 元标签，并包含 og:image 条目，我们就会获取对应的图片，并在预览中展示。此外，如果您的网站同时提供 og:image、og:image:width 和 og:image:height，此图片就将用于创建的第一次分享。
不提供这些信息则意味着您需要等待我们的爬虫程序先获取和分析图片。如需查看此流程的示例，请参阅 http://ogp.me/#structured。
这是有意的设计。REST API 已被弃用很长一段时间，且预计不会再继续运行。存在以下限制：主页访问口令无法与 REST API 结合使用。
您可以使用 JS SDK 中的“locale”参数设置赞按钮的语言环境。这适用于非登录用户。如果用户已登录，系统就还会考虑他们的语言首选项。如果语言首选项设置为特定语言，赞按钮就会以这个特定语言显示。
您可以测试这一行为，方法是：在未登录 Facebook 的情况下访问您的应用（或使用浏览器的隐私会话）。
向 Facebook 分享时，预填充文本区域属于违反 Facebook 政策的行为。必须由应用的用户自行填写想要分享的文本。
分享时预填写文本区域违反了开放平台政策第 2.3 条 ( https://developers.facebook.com/policy/#control )。我们实施此政策的目的是，确保用户确实能够根据自己的意愿向 Facebook 分享，且不会意外地分享他们不愿意分享的文本。
如果您更改或修改网页的网址，就会出现这种情况。每一个包含评论插件的网址都会被视为独立的开放图谱对象，而评论与这个对象关联。所以，如果您修改网址，即创建了一个新对象，所以现有评论就不会展示在相关页面上。
不可以，您不能通过 API 向评论插件发布评论。
分享插件不允许您传入自定义参数，相反，会直接拉入主页的开放图谱元标签中的元数据。
如需详细了解内容分享的最佳实践，请参阅此文档： https://developers.facebook.com/docs/sharing/best-practices
No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.
We will provide a seven day grace period post sending the warning. This will allow time for businesses to adjust their behavior. If businesses continue to exceed our internally set threshold of calls to the Contacts API vs. number of messages sent, we will permanently disable the phone number.
Interactive messages can be reopened by the user in order to resend an option. This is in case of mistyping the desired option or wanting to choose a new option.
Through user testing we’ve identified 10 as the optimal number of rows to provide a good user experience. If you have a list of more than 10 options, and cannot condense into one list message, we recommend creating an additional step in the flow and using two list messages. During testing businesses had higher response rates and conversions with this approach than using text-based lists.
Through user testing we’ve identified 3 as the optimal number of buttons to provide a good user experience. If you have a list of more than 3 options, and cannot condense it into one button message, we recommend using list messages. During testing, businesses had higher response rates and conversions with list messages than using text-based lists.
There may be a very small number of users for whom their app version does not support this feature, the business will receive a webhook notification throwing an error that describes why the message was unable to be received. It is up to the business to determine how to handle this error elegantly. Best practice would convert the interactive message to a text-based list to allow the user to complete the workflow.
If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.
不可以，目前我们不支持改变媒体存储的默认路径 (/usr/local/wamedia/)。所有媒体需存储在默认位置下才能正常工作。
没有，目前我们必须使用 AWS EFS 才能在核心应用和网页应用之间共享媒体卷。
没有，我们不支持 KOPS。但我们支持基于 ECS 的 AWS 解决方案。同时也提供了一份通用的 Kubernetes minikube 设置指南。
核心应用将在核心应用容器内检查 /usr/local/waent/data 和 /usr/local/waent/log 目录，以确保系统至少还有 10 MB 存储空间可用，否则核心应用会将此错误视为严重错误。
请检查您的记录和数据目录以确保拥有足够的存储空间。
否，目前无法在同一个 WhatsApp Business API 客户端设置中使用多个号码。我们正在开发妥善的解决方案以便未来支持您实现此操作。
使用数据库垃圾回收 services API 端点即可清除 messageStore.messages 和 messageStore.messages_receipt_log 表格中的消息和相应消息回执。
仔细检查 pass_through 应用程序设置。如果您已在 WhatsApp Business API 客户端 v2.29.1 或更高版本中启用 pass_through，将无法接收任何读取状态回调。
如果您想接收读取状态回调，请禁用 pass_through 应用程序设置。请注意，禁用 pass_through 后，数据库存储空间会快速增加。如需有关管理数据库的详细信息，请参阅数据库管理文档。
数据库垃圾回收会定期清理 messages 和 messages_reciept_log 表格，以协助数据库管理。
垃圾回收器会保留某些消息，以允许消息成功发送/得以处理。例如，保留在特定时间段内传入的消息可支持业务集成工具将消息标记为已读。
核心应用会以随机的时间间隔执行垃圾回收（例如，每几个小时执行一次）。这样做是为了防止在高可用性堆栈中由于数据库争用而可能出现的性能退化。
垃圾回收与回调队列无关。例如，如果 Webhook 服务器持续 4 天不可用，则会存储回调，以在 Webhook 服务器连接恢复时发送回调。
只有在收信人已将您的企业号码保存为联系人或您具有官方商业帐号的情况下，链接才可显示为可点击状态。
在 v2.29.x 版本之前，可能会因为系统错误而导致传出消息队列数量持续增加。升级至 v2.29.3 可解决此问题。
您需负责根据预期的用户位置和语言来使用适合的二维码。
现在可以在 WhatsApp Business 管理 API 中直接生成和管理二维码，而用户可以使用 WhatsApp、iOS 或 Android 相机扫描二维码。
另外，通过 WhatsApp 二维码
- 可完全自定义预先填好的消息，而且可以随时更改或删除这些消息，
- 用户将始终能直接进入应用，而不会打开任何插屏广告页面，
- 已过期二维码的应用内体验会向用户发送清除消息。
如果用户试图访问已删除的二维码或短链接，他们将会看到二维码/短链接已过期的错误消息。
如果用户已安装 WhatsApp 桌面版客户端，点击链接将开启用户与您公司之间的对话。否则，系统会提示用户安装 WhatsApp 桌面版客户端。
在新的短链接中，您可以随时编辑或删除与链接相关的预先填好的消息。短链接还可将网址语法简化为随机代码，因此您无需在网址中嵌入消息，也不需要使用掩码来遮盖电话号码。
为呈现最佳打印质量，我们推荐您使用 .svg 文件格式。
您可通过 WhatsApp Business 管理 API 或在商务管理平台用户界面查看、创建、编辑及删除二维码和短链接。
We are announcing the deprecation of Groups through the WhatsApp Business API. Starting July 8, 2020, only API phone numbers in a group created prior to July 8th can continue to use/manage Groups through the WhatsApp Business API. All other API phone numbers won’t be able to create/manage Groups through the Whatsapp Business API. On October 8, 2020, we will deprecate this feature for all API phone numbers (i.e., API phone numbers will be removed from their groups and no longer be able to send messages to their group).
如果您或您的最终客户想申请成为 WhatsApp 官方公司帐户，请查看申请官方公司帐户文档部分的说明。
不适用。目前，营销信息限制仅适用于公司发起的消息（通知）。
以相册的形式从 WhatsApp Business API 中发送图片时，您需要至少连续发送 4 张图片。如果在接收图片时，用户的对话视图正处于活动状态，则在下次访问时才可使用相册视图。
如果符合以下任何条件，则无法创建相册：
- 图片包含说明文字
- 存在未读分隔符 - 用户查看了部分图片，但并未查看剩余图片
- 日期标头不一致 - 存在跨天的消息传送
不可以。WhatsApp Business API 客户端目前无法在 Docker for Windows 上运行。如果有开发需要，我们建议您使用 Linux 虚拟机，在该虚拟机中运行 Docker。至于生产工作负载，我们建议您使用 Linux Server，以避免兼容和性能问题。
471 错误代码与基于质量的流量限制有关。详情请参阅基于质量的流量限制文档。
所有公司均从最低等级开始，随着其发送更多优质营销信息，限制等级也会自动提升。
是。发送消息模板后，如果模板无法在接收端显示，您将会收到“发送失败”的状态回调，错误对象为“结构不可用”，表示消息未能显示。根据接收方的情况，您还可能收到“已发送”的状态回调，这表示消息已成功发送给接收方，但接收方未能显示消息。
以下为消息模板发送端验证错误，及出现此类错误的原因：
- “消息模板无适用语言（您使用的语言）”或“消息模板无适用语言（您使用的语言）和区域（您所在的区域）”— 给定语言包不存在。请检查您的商务管理平台帐户。
- “该语言版本（您使用的语言）的模板（您的模板名称）不存在”或“该语言版本（您使用的语言）和区域（您所在的区域）的模板（您的模板名称）不存在”— 您在尝试使用并不存在（尚未创建或尚未通过审核）的模板。如果您尝试使用已删除的模板发送消息，亦会出现此错误。
- “localizable_params 的数字（num1）和预期的参数数字（num2）不符”— 您在尝试发送带有参数的消息模板，该参数与预期参数值不符。请检查您的 API 调用是否准确无误。
- “your-template-name 是一个多样式模板，需要模板消息 API 才能使用”— 您正在尝试将媒体消息模板作为一般消息模板发送。确保消息类型为
template。详情请参阅媒体消息模板文档。 - 在商务管理平台批准（或删除）模板后，WhatsApp Business API 客户端至多需耗时 20 分钟来接收更新后的模板。如果您尝试使用刚刚获准的模板来发送消息，则系统会发出“模板不存在”的错误，您可在 20 分钟后重新尝试发送消息。
为了确保消息至少能被接收一次（而非恰好一次），用户可能会向 WhatsApp Webhook 发送重复消息。如果这种做法影响了您这一端的消息处理，我们建议您根据消息编号删除重复的 Webhook 消息。
如果未完整填充公司主页，则系统会返回空白的 profile 对象。请升级至 v2.21.4 以解决此问题。
请参阅“商家主页设置”文档，了解关于如何完整填写商家主页的详细信息。
如果您在设置 AWS 部署时，遇到类似以下内容的错误，请尝试改用不超过 8 个字符的堆栈名称。
国家/地区名称（双字母代码）[AU]：州或省名称（全称）[Some-State]：地点名称（例如，城市）[]：组织名称（例如，公司）[Internet Widgits Pty Ltd]：组织单元名称（例如，部门）[]：常用名（例如服务器 FQDN 或您的姓名）[]：字符串过长，常用名（例如服务器正式域名或您的姓名）长度不得超过 64 个字节 []：错误，生成用于创建 internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com 的证书请求设备密钥时，出现配置文件中无指定对象的问题
消息模板中的参数数量不受限制。
每个 WhatsApp 公司帐户最多能可以 250 个消息模板。
如果 Webhook 事件由于任何原因未完成投放（例如客户端处于离线状态），或 Webhook 请求返回 HTTP 状态代码而非 200 代码，我们将重新尝试投放 Webhook。我们将继续重新尝试投放，并将延迟时间增加到特定超时（一般为 24 小时，但也可能有所变化），或直到投放成功。
在某些情况下，您可能需要更多时间来处理消费者查询，或者您只能在 24 小时后回复消息。我们建议您创建消息模板，以：
- 将结果发送给用户，或
- 提醒用户回复以开启客户服务窗口。
在这两种情况中，请务必为消息模板提供尽可能多的上下文。例如：
- “{{1}}，您好，关于您之前报告的问题，我们很遗憾地通知您 {{2}}。对于给您带来的任何不便，我们深表歉意。”
- 我们已更新您的请求单。如果您想继续获得支持服务，请回复。”
通常而言，WhatsApp 会进行试验以衡量和了解 WhatsApp Business API 通知对用户体验和整体产品的影响。如果您向其发送信息的用户正在参与此类试验，即使他们已选择接收，也不会收到您的通知。
如果您备份当前设置，并在新设备上将其还原，则注册信息应和其余实现一起迁移到新设备中。详情请参阅“备份和恢复设置”文档。
是，网页应用容器和核心应用容器的日志轮转行为略有不同：
- 网页应用：系统会保留最近 30 天的日志文件。只有日志文件大小超过 20MB 时才可以对其执行轮转。
- 核心应用：系统会保留最近 30 天的日志文件。只有日志文件大小超过 15MB 时才可以对其执行轮转。系统会对轮转后的文件进行压缩。
WhatsApp Business API 客户端的所有组件，自发布之日起，都有 6 个月的有效期。如果您收到此错误，请尽快升级到最新版本。
用户可以用文本或多媒体素材文件的形式发送消息负载。
如果是文本，我们确信不会有任何危险。
如果是多媒体素材文件：
- 通常情况下，公司应已安装一些保护软件（即杀毒、反恶意软件等）来分析潜在威胁。
- 由于我们会对正在传输的文件使用端到端的加密方式（亦适用于纯文本内容），因此 WhatsApp 无法识别或检查其中的内容。
- WhatsApp Business API 客户端中设有阻止自动下载多媒体素材文件的选项。如果公司不想接收用户发送的任何文件，可将
auto_download字段设为空数组。
不可以，WhatsApp Business API 不支持检测是否有多台设备在使用同一个电话号码。
当手机无法读取模板消息时，会出现“structure unavailable”错误。
模板存储在服务器上。当用户使用 messages 节点发送模板消息时，系统仅会将命名空间、语言、元素名称和本地化参数发送至手机，而不会发送整条消息。手机收到这些值后，会试图显示这条消息。
如果显示期间出现任何错误，系统会向回调网址发送 structure unavailable 错误，其中包含收信人和消息编号。命名空间错误、本地化参数不符、元素名称错误等会导致此类错误。
请前往 Facebook 商务管理平台中的“WhatsApp 管理工具”，查看正确的参数数量。再次确认命名空间是否正确无误，而且元素名称存在。
发生此类错误的一个常见原因是没有为所有正在使用的模板创建译文。例如，如果您通常发送 2 个模板，而您为其中一个模板添加了新语言的译文，则请务必也为另一个模板添加该语言的译文。如果计划支持多种语言，则您需要为所有模板提供全部支持语言的译文。
好消息是， structure unavailable 通常源自 messages API 调用中的错误，可通过更改发送负载来解决。
您可以在 Facebook 商务管理平台的“WhatsApp 帐户”中注册新手机号和删除旧手机号。
- 在“WhatsApp 帐户”中，前往设置。
- 点击 WhatsApp 管理工具。
- 选择手机号选项卡。您可以在此处管理该帐户的所有手机号。
如果是图片，则您可将说明文字添加为图片描述。在 Android 和 iPhone 手机上，系统均可显示图片说明文字的完整文本。
如果是文档，则说明文字会取代文件名。系统不会在用户设备上将其显示为描述文本，而是会将其显示为文件名称。iPhone 手机会显示全部文本，而 Android 手机会截取文件名称，这是当前 WhatsApp 在这两种设备上的实现所受到的技术限制所致。
如果您在使用“短信”注册时，因尝试次数过多而导致失败，并看到带有“拒绝访问”字样的消息，则请使用“语音通话”的方式来尝试注册
目前需要 7 天时间。如果 7 天后缓存仍未更新，则无论包中是否已存在相应元素，系统均会从服务器上下载最新的语言包。
设备首先从缓存中加载消息，如果某个元素已存在，设备就会使用该消息模板打开消息。所以，较之于修改消息模板，最安全的方法是添加包含不同元素名称的新消息模板。这样能够确保当语言包找不到该元素时可以重新下载。消息模板的存储成本可以忽略不计，因此并不十分需要删除消息模板。
详情请参阅发送消息模板 — 语言。
为确保向公司和用户提供优质体验，我们处于受限公开预览状态。如果您想与我们合作，请在我们继续扩大可用范围时，提交有关您公司的更多信息供我们筛选考量，或者如果您已有 Facebook 代表，也可与之联系。
通过 users 端点注销用户可使分配给该帐户的身份验证口令无效。此外，删除用户也有相同的作用，虽然这种做法比较极端。请谨记，通过 users 端点登录用户会返回新的身份验证口令，但并不会使该用户已在使用的身份验证口令无效。任何拥有之前预分配口令的用户均可继续使用该口令，直至口令过期，或通过上述某种方法使其无效为止。
如果发生此错误，但其声称缺失的必要参数在 json 正文中确有设置，则可能是 json 解析错误。当整个 json 有效负载由于 json 的格式错误而无法解析时，便会出现此错误。请查看参数值中是否存在无效的 json 字符，例如末尾处的回车符。有时在复制参数时会产生额外的空格，这些空格可能包含破坏 json 的字符。
原因有很多。可能是因为您的核心应用发生故障，或者您的数据库没有正确设置。如果不是这两种情况，请查看核心应用的日志（如果您正在运行多连接，则请查看核心应用的主日志）。如果遇到数据库连接错误，很可能是因为您的数据库连接已用完。请参阅 MySQL 文档或 PostgreSQL 文档，了解关于此错误的更多信息。
我们建议增加数据库连接的数量。1000 个数据库连接应该比较安全，但请您结合实际做出明智的决定。如果错误仍然没有解决，请打开支持请求单。
消息模板未通过审核的原因可能包括以下几种：
- 包含潜在的侮辱性内容，例如侮辱性语言或垃圾内容
- 包含推广内容
- 与选择的标签类型不符
- 格式不正确
“连接遭拒”错误很可能表示核心应用未在运行。使用 docker ps 查看核心应用是否正在运行。如果其运行，请查看 Docker 日志。核心应用可能无法连接到数据库。确保您的数据库已正确设置。
当 Docker 桥损坏时，会发生此错误。解决此问题的最佳方法是停用并重启 Docker 服务。您还可以尝试对容器执行 docker restart 命令。
WhatsApp 会谨慎验证给定号码是否属于某台手机。如果用户拥有 WhatsApp 帐户，那便表明他们已确认过此号码，并且后续也没有其他人使用此号码注册 WhatsApp。然而，这并不能保证 SIM 卡所处的实际位置。
另一方面，如果用户的手机丢失或遭窃，则用户也可停用自己的 WhatsApp 帐户。如要进一步了解用户如何停用帐户，请参阅手机丢失与遭窃的常见问题解答。
如果客户的手机号已停用，但客户仍在使用 WhatsApp，则其可以继续使用 WhatsApp，直至运营商重新分配该手机号，或有人再次用其注册为止。
WhatsApp strongly verifies whether number provided actually belongs phone. The fact that a user has a WhatsApp account is proof that they confirmed the number and no one else has used that number to register on WhatsApp subsequently. However, It is not a guarantee of the physical location of the sim.
On the other hand, if users phone is lost or stolen, they can deactivate their WhatsApp account. You may read to know more about how users can deactivate their account here.
这是个已知问题。有时使用 CloudFormation 脚本升级 WhatsApp Business API 客户端也需要升级 RDS DB 堆栈。新的 RDS 堆栈与最初的堆栈主机名称有所不同，因此 Docker 容器无法连接至数据库。解决方案是使用 SSH 登入由 CloudFormation 创建的 EC2 实例，并使用新的主机名称更新 whatsapp.conf 文件，然后重启 Docker 容器，以启用新设置。
Use the mcdockerreset script and tear down the webapps then use the mcdockersetup script to bring up a new webapp.
Reason: When the webapp first connects to the DB, it creates the database.yml file. it will never try to create it again. The coreapps will just not start up on a bad DB config; however, the webapp will, so you see the master and slave nodes in your DB because they were setup correctly once you got around all the DB and script issues but the webapps were started by the script in a bad state to begin with.
如果 Webhook 未能发送回调，系统则会将其置入重试队列中。系统无法接收在初始回调失败后发出的任何回调。仅在失败的初始回调发送成功后，系统才可接收其余回调。
WhatsApp Business API 客户端通过核心应用容器向您发送 Webhook 回调。因此，您需要对 Webhook 端点进行配置，使其接受核心应用发出的入站请求。
您应注册第二个手机号，并启动用于第二个 CloudFormation 堆栈或用于测试的 Docker 实例。如果您有两个使用相同手机号的 WhatsApp Business API 客户端，则服务器会因加密密钥冲突而将您踢出。我们建议您先设置第二个可用于测试非生产实例的环境，然后再在生产客户端上开展任何类型的迁移工作。
您需要使用 MySQL 5.7.x、PostgreSQL 9.5.x、9.6.x、10.x。使用之前的版本会造成 Unable to initialize config store 错误。
在发送消息时，只要您获得了消息编号，便意味着系统已将该消息请求存储在数据库中。WhatsApp Business API 客户端会不断尝试发送该消息，直至收到 WhatsApp 服务器的确认为止。这一过程没有结束期限。然后 WhatsApp 服务器会尝试将该消息发送至用户的手机。如果用户的手机不在线，则消息将在 WhatsApp 服务器中存储 30 天，然后失效。
数据库表格会存储应用设置、聊天线程、信息和多媒体素材等应用运行所需的相关信息。
贵公司无法在顾客变更其 WhatsApp 手机号时收到通知。在您使用 contacts 节点时，该号码的状态将变为 invalid。
不可以，您只能为每个实例运行一个单个帐户。如果您需要第二个测试帐户，请务必对第二个实例使用不同的数字。
随着存储空间逐渐变满，您的系统运行速度或会开始变慢。这可能是因为多媒体素材文件、消息和大型日志文件过多。系统会自动轮转日志文件，但如果日志文件开始变大，将其删除也不会造成安全问题。
系统会将消息存储在数据库中。您可在必要时删除消息。此外，如果在应用程序设置中将 pass_through 设置为 false，则在遭到明确删除前，所有消息都将保存在本地数据中。
系统会将用户发给您的多媒体素材文件下载至多媒体素材卷。删除哪些多媒体素材文件由公司决定，但通常情况下，删除任何多媒体素材文件都不会造成安全问题。您可以使用 docker inspect your-container-id 来查看多媒体素材卷文件夹的所在位置。
请遵循 Docker MySQL 指南，使用 Docker 设置本地 MySQL。
请按照 Docker PostgreSQL 指南，使用 Docker 设置本地 PostgreSQL。
大多数情况下，您应该在与核心和网页容器分离的物理服务器上运行数据库。数据库服务器与计算机之间应该只有几毫秒的延迟。
删除多媒体素材的时间由您决定。
上传多媒体素材后，您将收到一个多媒体素材编号，您可以使用此编号发送包含已上传多媒体素材元素的消息。发送多媒体素材消息后，WhatsApp Business API 会将多媒体素材解码并上传至 WhatsApp 服务器，该素材会在服务器中留存 14 天。此时，您可以决定是要提供多媒体素材编号以删除该素材，还是保留素材，以备日后使用。您可以根据贵公司的政策或用例自行决定多媒体素材的保留时间，我们的建议是保留 30 天。
可以，您可以在不接触 WhatsApp 相关表格的情况下，将数据库用于其他用途。
可以！WhatsApp 支持您对消息中的选中文本作加粗、斜体、加删除线处理，或对其采用等宽字体。
是，消息模板支持包括表情、粗体、斜体等内容在内的所有 WhatsApp 消息字符和格式。如要使用表情，您需要使用表情字符（复制/粘贴），而非其对应的 unicode 字符。
不可以！不管在任何时候，一个手机号都只能运行一个 WhatsApp Business API 客户端实例。一旦您注册第二个实例，第一个实例便会遭到关闭并失效。我们正在开发妥善的解决方案以支持您实现此操作。如果有任何进展，我们会及时通知您。
对于在自己控制的服务器上管理 API 端点的 Business API 用户，WhatsApp 在与其通信时会进行端到端加密，因为第三方对端点间的内容无访问权限。
而部分组织可能会选择将其 WhatsApp Business API 端点的管理权限委派给第三方业务解决方案提供商。在此类情况下，通信仍会使用相同的 Signal 协议加密。但是，WhatsApp Business API 用户已选择由第三方来管理其端点，因此 WhatsApp 将不会对此类通信消息进行端到端加密。到 2021 年，此做法也将适用于选择使用由 Facebook 托管的 API 云管理版本的商家。
此外，如果您在向 WhatsApp Business API 客户端发出调用时使用 HTTPS，则系统会对该数据进行 SSL 加密处理（从后端客户端到 WhatsApp Business API 客户端）。
更多详情请参阅我们的“WhatsApp 加密概览”技术白皮书。
此错误由旧版 iOS 客户端中的一个漏洞引起。我们预计随着客户端的总体升级，此类错误会逐渐减少。
不能，我们无法保证消息的接收顺序与发送顺序相同。如果排序对您的用例十分重要，我们建议您在侦听到第一条消息的已发送回调后，再触发第二条消息。
以下是可在外部触发的脚本，其可清除容器的旧日志：
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
该脚本既适用于网页应用容器，也适用于核心应用容器。运行脚本后，系统会移除旧的日志文件，仅保留容器中最近 30 天的日志文件。
注意：请勿使用 WhatsApp Business API 向同一位收信人重复发送相同消息。
送达率不是 100% 可能有很多原因。其中一些常见情况包括：用户的网络断断续续、用户在一段时间内没有任何活动，或为建立 优质用户体验。
可以通过 WhatsApp 送达的消息会有非常高的送达率。但也存在很多原因可能导致消息送达失败。您可以通过监控回调，了解消息的确切状态。这与通过短信发送消息不同，例如，对于短信，您无法访问最终的送达状态，而再次发送消息可能确实会产生不同的成效。
消息未能成功送达的原因可能是用户的手机停机、没电，或者用户的手机遗失，并在更换新手机时弃用了 SIM 卡。也有可能是公司的客户端出错，因而无法连接到网络，或者是因为回调 (Webhook) 没有送达。您可使用 health 节点监控这些状况。您可以开启服务器接收回调，以便在消息进入 WhatsApp 服务器云时收到通知。
当用户重新连接到网络时，您之前发送的所有消息都会送达给用户。对用户而言，收到多条内容相同的消息会是非常糟糕的体验。因此，用户很可能会将您拉黑或者投诉您。您可能会遭到禁言。
如果您在发送消息后收到 API 发送的消息 ID，则说明您已经完成对此消息的发送。请勿向同一个收信人重复发送相同内容。
如果您发现送达率长期偏低，请提交支持工单至 站内支持。
WhatsApp Business 本地 API 客户端需要使用数据库来存储密钥，以解密企业和客户之间发送的消息。WhatsApp 上的所有消息都使用发送者和接收者密钥作加密处理。客户密钥存储在客户的移动设备中，而企业密钥则存储在企业的数据库中。请参阅 WhatsApp 的安全性获取更多信息。
WhatsApp Business 云端 API 是 Meta 托管企业数据库的替代方案。通过使用云端 API，您可以直接实施 WhatsApp Business API，省去使用自己的服务器托管的费用。详细了解。
否。WhatsApp Business API 客户端会开放指向 WhatsApp 服务器上 5222 或 443 端口的出站 TCP 连接。此长期连接会产生 TCP 流量。通常，防火墙将此类流量分类为允许的“出站流量和已确定的流量”。当然，连接建立后，数据包便会在其中来回传输，但由于该连接从 WhatsApp Business API 客户端中建立，因此无需制定允许入站连接的规则。
WhatsApp 支持 MySQL 和 PostgreSQL。如果您自己运行 Docker，则必须为要连接的容器提供 MySQL/PostgreSQL 数据库。使用 AWS 模板将默认设置 MySQL 数据库。
相关要求取决于您的负载和具体情况。该解决方案可在任何运行 Docker 的联网机器上运行。例如，可以在笔记本电脑上进行简单测试。
对于单一实例生产服务器配置，我们建议至少使用 250 GB SSD、16GB RAM 和 4 核 CPU。不建议使用 HDD，因为 I/O 速度在承受负载时会变成瓶颈。
对于单一实例生产服务器配置，我们建议至少针对每个核心应用/主/网页应用容器使用 50 GB SSD、4 GB RAM 和 2 核 CPU。
大多数情况下，您应该在与核心和网页容器分离的物理服务器上运行数据库。数据库服务器与计算机之间应该只有几毫秒的延迟。
此设置支持每秒发送约 20 条消息。
当然可以！请联系您的 WhatsApp 代表，提出此申请。
目前还没有办法做到这一点。如果您无法处理用户通过 WhatsApp 发出的入站响应，我们建议您发送可将其重定向至相应支持渠道的自动回复消息。
可以，我们可以在您准备就绪，能够开始直播时设置新手机号或更改已验证名称。
上传文件大小不能超过 64 MB，也就是说，此限制同样适用于随消息一起发送的任何图片、文档或视频。
不可以。WhatsApp Business API 解决方案需要使用未注册过的手机号码。
如要寻找多媒体素材卷的挂载点，则可运行 Docker 命令。
请求
docker volume inspect whatsappMedia
响应
[
{
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
"Name": "whatsappMedia",
"Options": {},
"Scope": "local"
}
]然后，您可在已接收的 Mountpoint 文件路径中运行 ls 命令，以查看全部入站多媒体素材文件：
ls /var/lib/docker/volumes/whatsappMedia/_data/
如要设置 AWS，您可将多媒体素材卷挂载到主机上的 /mnt/wa/media 路径中。
我们并未针对出站或入站的多媒体素材设置清理机制。您可在文件系统中找到这些多媒体素材文件，然后将其手动删除。
您可以通过运行以下代码重启 Docker 容器：
核心应用 Docker 容器
docker restart wacore<Current_WABA_Version>
网页应用 Docker 容器
docker restart webapp<Current_WABA_Version>
您可以查看自己正在运行哪个版本
docker ps
- The Page must be categorized as "App Page"
- You should have access to the page via a role
- The App Page should not already be linked to an existing app
- The Page must have the same name (or a subset of the name) of the app
- An admin of the campaigns
- A full admin of the page
2. There won't necessarily be a read receipt for each message. The read receipt means that ALL messages before this watermark timestamp have been read by the user.
- 应用到用户游戏请求通过 /apprequests API 端点发送。它们在游戏活动动态中生成请求，但不会在网站中生成通知。https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
- 用户到用户请求通过请求对话框发送。它们在游戏活动动态中生成请求，并会在网站中生成通知。https://developers.facebook.com/docs/games/services/gamerequests
- 此外，还有通过 /notifications API 端点发送的应用到用户通知。它们会生成通知，但不会在游戏活动动态中生成请求。https://developers.facebook.com/docs/games/services/appnotifications