meta-whatsapp-cloud-api 是做什么的？
本程序最后于 2026-11-08 在真实的 Meta Business Suite 和开发者控制台上执行。Meta 经常在没有通知的情况下更改这些界面、字段名称和向导流程——如果下面的步骤与你看到的不符，请在本仓库中提交问题，而不是猜测，并在找到修正后提交 PR。
永不（Never）
- 在同一天重新提交被拒绝的验证。修复实际问题，等待 24 小时，然后提交。同日重试往往会触发更长的审查。
- 猜测或“清理”在业务信息中输入的法律名称、地址或电话号码。应一字不差地从用于证明这些信息的文档中复制。
- 不重新检查实际状态字段（见 §2）就认为长期处于“pending”状态是“Meta 只是慢”。它可能会悄无声息地变为“需要更多信息”，而通知邮件往往会落在无人主动监控的收件箱中。
- 提供个体户税务登记证明作为法律名称或地址的证明——除非当地管辖区的等效文件在 Meta 为此目的接受的文档列表中——参见 §1 中的工作示例。Meta 明确声明何时文档“不是可接受的类型”；应阅读该消息，而不是因为文档是官方的就假设其知名地方文档会被接受。
- 提交时网站的首页上缺少法律业务名称。Meta 会拉取
/，而不是关于或条款页面，如果名称不在首页，验证会专门因此失败。 - 仅仅为了获得任务帮助就将外部协作者添加为完整的业务组合用户。这在 Meta 自己的拒绝原因列表中明确列出——应使用更窄的合作伙伴/协作者访问级别。
- 将验证码、两步验证 PIN 或任何密码输入到除了 Meta 自己的控制台之外的任何地方，并由账户持有人亲自输入。
1. 企业验证
验证是什么，不是什么
Meta Business Suite 中的企业验证与付费的 Meta Verified 订阅是不同的事物，并且不会产生验证徽章。Meta 直接声明：“验证您在 Meta Business Suite 中的企业与 Meta Verified for businesses 不同，不会给您验证徽章。”（Meta Business Help Center，“如何在 Meta Business Suite 中验证您的企业”，https://www.facebook.com/business/help/2058515294227817，阅读日期 2026-11-09——相同句子在 https://www.facebook.com/business/help/2342133782492969 重申，阅读日期 2026-11-09）。验证徽章是 Meta Verified 的特定福利：“Meta Verified for businesses 是一个付费订阅，提供帮助您在新受众中建立更多信任度并保护您品牌的工具。此订阅带来验证徽章、增强支持、冒充保护等福利。”（https://www.facebook.com/business/help/308979828303560，阅读日期 2026-11-09）。Meta Verified 按周期计费，与本技能涵盖的免费验证程序是分开购买的。
企业验证实际解锁的功能，根据 Meta 自己的说法：“企业验证是访问某些广告、开发者、计费和消费功能所必需的。”（https://www.facebook.com/business/help/2058515294227817，阅读日期 2026-11-09）。进一步说明于 https://www.facebook.com/business/help/1095661473946872（阅读日期 2026-11-09）：每日消费上限、符合条件的开发者功能、Meta Business Partners 访问、资讯主页索引、WhatsApp Business Platform、页面透明度、位于中国的代理商以及金融服务广告商状态。Specifically for the WhatsApp Business Platform：same page says：“使用 WhatsApp Business Platform 的企业可能需要完成验证才能访问某些功能。” For the developer side：“Advanced Access 现在需要 Business Verification...申请高级访问权限的应用以及允许其他企业访问自身数据的应用必须连接到已完成 Business Verification 的企业。”（https://developers.facebook.com/docs/development/release/business-verification/，阅读日期 2026-11-09）。
在以上任何页面或 Meta 的 WhatsApp 账户扩展页面（https://www.facebook.com/business/help/595597942906808，阅读日期 2026-11-09）中检查并未找到：Meta 关于在停止前应重新提交多少次，或建议修复文件根源而非再次提交的声明。该建议常见于第三方机构博客，但 Meta 在本技能的检查范围内未提及，因此此处不重复作为事实。下面的“永不”列表坚持 Meta 自身页面支持的内容：一个时间规则，而非次数规则。
选择正确的文件集
Meta 自己的可接受文档类别（直接从其“详细信息与后续步骤”对话框中读取，该对话框仅在验证尝试实际运行后出现）：
| 证明 | 可接受的类型 |
|---|---|
| 法律业务名称 | 注册证书/公司章程、营业执照或许可、银行对账单或银行函件 |
| 地址 | 上述四种，加上公用事业账单——水、电、燃气或电话 |
对于注册公司，注册证书通常是最简洁的单一文件。对于没有公司注册的个体户，通常没有完全等效的文件——不要假设某辖区的通用小型企业税务登记证书也算，即使它感觉像明显的文件。工作示例（以色列）： 以色列个体户的 עוסק פטור/עוסק מורשה 证书被 Meta 明确拒绝（“不是可接受的类型”），尽管它是以色列合法的经营状态标准证明。实际有效的方法是：一份银行账户所有权函件用于证明法律名称（大多数银行可以应要求出具，专门用于企业验证），再加一份公用事业账单用于地址——两个可接受类别中各一份文件，每份文件上打印的名称或地址与业务信息中输入的完全一致。
无论司法管辖区如何都适用的通用规则：
- 同时完整、清晰地包含名称和地址的一份单一文件，一次上传即可满足两个要求。
- 希伯来语或任何非英语脚本可直接使用（无需翻译）——但请为名称/地址选择一种语言，并在业务信息、网站首页和文件本身中一致使用。
- 直接拒绝以下类型，不值得尝试：租赁合同、个人（非业务）账单、门户页面截图、任何裁剪、注释或修改过的文件，以及除正式注册文件外超过约 90 天的任何文件。
- 从一种文件格式忠实转换为另一种的文件例如：PDF 转换为高分辨率 PNG）是可以的；裁剪或重新输入任何部分则不行。
在提交前准备业务组合
- 业务信息字段必须与上传的文件完全一致，包括标点符号和法律后缀（公司后缀如“Ltd”要么同时出现在两处，要么都不出现）。确定要标准化的语言，并在所有地方使用。
- 网站必须可访问、提供 HTTPS、所有页面均不显示错误或正在建设中状态，并且——这是单独检查且独立于可达性——在首页上明确显示准确的法律业务名称。最近注册的域名也更容易引起怀疑；有一定年限的域名表现更好。
- 业务电子邮件应与网站使用相同域名。免费的个人电子邮件域名会显著提高拒绝率，并在未被拒绝时减慢审查速度。
- 选择一个与业务真实匹配的分类类别——敏感类别（金融、健康、博彩、酒精）会招致额外审查和额外所需文件。
- 业务组合上有两名管理员且均启用双重身份验证，通常可以减少摩擦；单一未受保护的管理员本身就被列为触发拒绝的原因。
- 任何需要验证的资产（通常为 WABA）在开始前必须已经附加到业务组合中——否则验证入口点本身会显示为灰色“不符合条件”。
如果即使修复了上述问题，网站仍然无法通过自身检查，Meta 记录了两种替代方法用于确认业务身份，而不是使用正常工作的网站：使用与企业真正关联的不同域名上的确认电子邮件，或改用商业电话号码确认。
确认渠道会改变所需的文件
向导中选择的确认渠道会改变上传步骤实际要求的内容：
- 电话、短信或 WhatsApp 消息作为渠道 → 向导随后要求证明法律名称和电话号码的文件。
- 电子邮件作为渠道 → 向导要求证明法律名称和地址或电话号码的文件。
因此，选择渠道应匹配实际最容易获得的文件，而不是反过来——如果有银行函件和公用事业账单，请选择电子邮件。
提交
前往验证入口点（在 Meta 当前布局中的 Security Center），选择与要验证的内容匹配的用例（通常有一个专门用于设置 WhatsApp Business 账户的选项——如果两者都存在，优先选择该选项而非通用的“应用权限”选项），并走完向导：国家、业务类型（未注册的个体经营者通常为“独资企业”，如果当地税务机关已为其颁发了任何注册号，即使没有正式公司，也常回答为“已注册”）、业务详情、CAPTCHA（始终由人类完成，绝不通过自动化代理）、公共记录匹配步骤、确认渠道、文件上传以及最终审核/提交。
在该公共记录步骤和上传步骤中值得注意的两个陷阱：
- Meta 可能会提供一个看起来合理但属于不同、不相关实体的名称相似的公共记录匹配。在接受匹配之前，请验证每个识别细节（地址、域名、显示的任何税务或注册号）——声称他人的业务记录是违反政策的行为，可能导致整个业务组合受限，而不仅仅是本次验证失败。如有疑问，选择“我的企业未列出”。
- 某些文件上传步骤默认将一个容易被忽略的切换按钮（“您的文件是否包含您的电话号码或地址？”）设置为“否”，这会要求另一个完全独立的第二份文件，而大多数申请人没有现成的。如果已上传的单一文件确实包含这两项信息，请将该切换按钮翻转为“是”，额外的步骤就会消失。
提交后，对于通过渠道验证的提交，预计大约 1-2 个工作日；对于基于文件的提交，预计 3-7 天（在 Meta 的政策更新窗口期间可能长达 14 天）。在提交处于“待处理”状态时，不要进行任何操作——不要添加管理员、更改设置或随意开启支持工单；这些都不会加快排队审核的速度，任何导致与提交内容不符的操作只会带来不利影响。
监控“需要更多信息”而不依赖电子邮件
Meta 关于状态变更的通知会发送到设置为业务组合管理员联系人的任何电子邮件地址——这通常不是某人每日检查的收件箱。唯一可靠的无浏览器检查方法是直接调用 API（如果已有 API 访问权限）：
curl -s "https://graph.facebook.com/v21.0/$WABA_ID?fields=business_verification_status" \
-H "Authorization: Bearer $ACCESS_TOKEN"
实践中看到的值：pending（轮到 Meta 处理，只需等待），pending_need_more_info（轮到您——请到控制台中查看具体被要求的内容，仅此字段不会说明），以及 verified。定期轮询此状态，而不是等待被通知——状态静默翻转为“需要更多信息”与有人实际注意到之间的延迟，已经导致真实提交浪费了整整一个审核周期。
2. 启动 Cloud API（在验证完成之前也可工作）
以下每一步都适用于未验证的业务组合——验证只会更改消息量上限，而不会影响 API 本身是否工作。并行启动两者，而不是等待一个完成后才启动另一个。在步骤 1 之前，必须已存在一个业务组合（在 business.facebook.com 创建）——下面的步骤是将新应用附加到该现有业务组合，而不是创建新业务组合。
- 创建应用。 在开发者控制台中，使用以 WhatsApp 为中心的用例（“通过 WhatsApp 与客户联系”，或当前控制台中相应的表述）创建应用，并将其附加到现有业务组合——切勿为此创建新的业务组合，这会从零开始重新验证。
- 附加或创建 WhatsApp Business Account (WABA)。 应用的 WhatsApp 设置面板可连接到现有 WABA 或创建一个。将 WABA ID 和测试电话号码的 ID 记录到可长期保存的地方。
- 先尝试 Meta 分发的测试号码。 它是免费的，有有限试用期，支持少数几个预批准的接收号码（每个号码需要一次性代码才能列入白名单），并且是在接入真实 SIM 卡之前证明 Webhook 和消息发送代码正常工作的最快方法。
- 生成系统用户访问令牌，而不是临时用户令牌。具有合适角色、被分配了应用管理访问权限的系统用户可以生成永不过期的令牌——通常需要的权限是消息传递和 WABA 管理范围；如果集成将通过 API 而非控制台读取验证状态或删除 WABA，还需要更广泛的业务管理范围。来自快速入门向导的临时令牌会在几小时后过期，不适合自动化设置。
- 添加真实电话号码并完成该号码的业务验证（WhatsApp 自己针对该号码的企业验证，与第 1 节的 Meta 企业验证不同）。每个真实号码都需要一个验证码，可以通过短信或语音电话接收。
- 设置 Webhook 以接收入站消息、送达回执和消息状态回调。URL 必须可公开访问、提供 HTTPS，并且在使用 Meta 的验证令牌进行验证挑战时响应正确。
- 进行冒烟测试：从测试号码向真实号码发送一条欢迎消息；从真实号码回复以验证 Webhook 路径；检查消息状态的送达和已读回执。
- 创建消息模板（如果您的用例需要）并提交审查。模板必须符合 WhatsApp 的模板策略（常见拒绝原因包括：包含联系信息、使用促销语言或缺乏明确的退出说明）。
监控验证状态
如第 1 节所述，通过 API 定期检查状态：
curl -s "https://graph.facebook.com/v21.0/$WABA_ID?fields=business_verification_status" \
-H "Authorization: Bearer $ACCESS_TOKEN"
当状态变为 verified 时，消息量上限会自动增加。如果进行中的验证需要文档，控制台中会显示具体要求。
3. 常见陷阱与故障排除
- 验证被拒绝：检查法律名称、地址和电话号码是否与文件完全匹配；确保网站首页显示法律名称；检查使用的文档类型是否在 Meta 的可接受文档列表中（第 1 节中的表格）；等待 24 小时后再重新提交。
- WABA 创建失败：确保业务组合已准备好（验证或未验证均可）；检查业务组合是否具有正确的业务分类（某些类别可能需要额外文件）。
- Webhook 失败：验证 URL 是否可公开访问并正确响应挑战；检查令牌是否与 Meta 开发者控制台中配置的令牌匹配。
- 消息发送失败：验证系统用户令牌是否具有正确的权限；检查号码是否已完成业务验证；确保消息模板已批准（如果是模板消息）。
4. 其他资源
本技能旨在提供作为 Meta 企业验证和 WhatsApp Cloud API 设置的唯一参考，但 Meta 的界面和政策经常变化——如果遇到问题，请提交 Issue 或 PR。