# EasyCoexistence: 简体中文 (zh-hans) EasyCoexistence is an independent Meta Tech Provider. It is not a Meta product and is not affiliated with or endorsed by Meta. Product documentation (English): https://easycoexistence.com/llms-full.txt ## 适用于 Claude、ChatGPT 和 Cursor 的 WhatsApp MCP 服务器 https://easycoexistence.com/zh-hans/whatsapp-mcp-server MCP 服务器让 AI 助手直接使用 WhatsApp：列出您的号码、发送消息和模板、检查连接状态，并将 Webhook 指向您的系统。EasyCoexistence 基于 Meta 的官方 Cloud API 运行 MCP 服务器，因此客户一直联系的号码保持官方状态，不会面临封禁风险。 ### 什么是 WhatsApp MCP 服务器？ MCP，即 Model Context Protocol，是 AI 助手访问其本身不拥有的工具的方式。您只需添加一次连接器，之后助手就能代表您调用该工具。您可以用自然语言提出请求，中间无需编写连接代码。 WhatsApp MCP 服务器会将 WhatsApp 号码公开为其中一个工具。您不必编写脚本来向 API 验证身份、构建负载和处理响应，只需提出请求：给这位客户发送消息、为订单更新创建模板、告诉我这个号码的连接状态。助手会完成这些调用。 关键在于它连接的是哪一个 WhatsApp。两个完全不同的产品使用了相似的名称，而这项差异决定了客户的号码能否继续使用。 ### 为什么大多数 WhatsApp MCP 服务器会导致号码被封禁？ 目前几乎所有可安装的 WhatsApp MCP 服务器都通过驱动 WhatsApp Web 来运行。它会像浏览器客户端一样以绑定设备登录，并自动操作该会话。 这违反了 WhatsApp 的条款，因为条款禁止自动化和批量使用消费者客户端，而绑定设备就是消费者客户端。使用这种方式的号码可能被封禁。所谓防封禁承诺，实际上描述的是供应商无法控制的事情。 对于个人号码，这只是麻烦。对于客户已经联系的号码来说，这就是整个业务。 EasyCoexistence 连接器不会这样运行。它调用 Meta 的官方 Cloud API，并使用通过 Meta 自有 Coexistence 功能接入的号码。没有绑定设备，也没有会丢失的会话。 ### AI 实际上可以用它做什么？ 共有 16 个工具，对应人们实际会提出的请求。 读取：列出您账户中的号码，检查某个号码的连接状态，包括质量评级、消息层级和连接状态，并在其他地方需要时读取其 API 凭据。 发送：在 24 小时会话内发送消息；列出该号码的模板、创建新模板、检查 Meta 是否已批准模板，并向客户发送获批准的模板，以便在时限外开启对话。 配置：设置 Webhook 目的地，让传入消息从 Meta 直接路由到您自己的服务器。还可以开始连接，并返回客户打开后即可接入其号码的链接。此外还有文档工具，让助手能够查找功能用法，而不是自行猜测。 最后这两项让它不只是聊天玩具。代理可以接入号码并将其指向您的系统，无需人工打开控制台。 Partner API：当您自己的软件让其客户连接自己的号码时，另外 5 个工具负责设置托管连接链接。它们可以查看设置状态、创建或撤销 API 密钥、设置接收状态事件的 URL，并为单个客户创建连接链接。 ### 企业还能继续在手机上使用应用吗？ 可以，这正是它能用于企业现有号码的原因。 Coexistence 是 Meta 的官方模式，让 WhatsApp Business 应用和 Cloud API 同时使用同一个号码。团队可以像以前一样继续在手机上回复，保留相同的聊天、历史记录和设备，同时由 API 使用同一条线路发送和接收。API 发送的内容会显示在应用中，团队在应用中输入的内容也会对 API 可见。 因此，代理不会取代任何人。它能处理时就先回复，人员需要时则可在手机上接手同一对话。双方无需知道另一方的存在。 1. Connect the number: Sign up, then run Meta's Embedded Signup and scan the code from the WhatsApp Business app. About two minutes, and nothing about the app changes. 2. Add the connector: In Claude, ChatGPT, Cursor or Claude Code, add a custom connector pointing at https://easycoexistence.com/api/mcp and sign in. OAuth, so no key is pasted anywhere. 3. Ask for something: "Which of my numbers is unhealthy?" or "Send Sarah the booking confirmation." The assistant picks the tool and makes the call. - 在 24 小时会话外发送普通文本。超出时限后，只有获批准的模板可以发送，因此只会使用 send_message 的代理到了第 25 小时就会停止发送。 - 不要期待群聊功能。每个供应商的 Coexistence 号码都无法使用群组 API。 - 不要将 Webhook 指向无法回应 Meta GET 握手的 URL。Meta 会先验证端点，然后才传送内容；无响应的 404 在第一条消息始终收不到之前，看起来与正常设置完全一样。 **客户的号码会因此被封禁吗？** 不会。这是 Meta 的官方 Cloud API，通过 Meta 自有的 Coexistence 功能访问。人们所说的封禁风险来自非官方网关，它们以绑定设备登录，机制完全不同。 **连接器支持哪些助手？** 任何通过 HTTP 和 OAuth 支持 MCP 的助手都可以使用：Claude、ChatGPT、Cursor、Claude Code 和 Codex 目前均可。它是一个远程端点，因此您的设备无需运行任何程序。 **我的对话会经过你们的服务器吗？** 不会。传入消息会从 Meta 直接路由到您指定的 Webhook，我们不会存储对话内容。我们只保留监控连接所需的账户和号码状态，不保存其他内容。 **一个连接器可以用于多个客户吗？** 可以。一个账户可以按需保存任意数量的号码，每个号码单独计为一个连接，连接器会列出所有号码。您可以将它用于所服务的企业，没有此项限制。 --- ## WhatsApp Coexistence：同一号码使用应用和 API https://easycoexistence.com/zh-hans/whatsapp-coexistence Coexistence 是 Meta 的官方模式，让 WhatsApp Business 应用和 Cloud API 同时使用同一号码。团队仍可通过手机回复，保留相同的对话和历史记录，同时由软件在同一号码上发送和接收消息。无需迁移，也无需更换号码。 ### Coexistence 实际解决了什么问题？ 在它出现之前，将企业号码接入 WhatsApp API，就意味着必须放弃应用。号码会被迁移，手机不再作为 WhatsApp 客户端使用，而原本整天回复客户的人，突然必须改用购买的软件来处理。大多数小团队不愿接受这种取舍，因此始终没有进行自动化。 Coexistence 消除了这个取舍。应用继续像以前一样运行。同一个人仍可用同一部手机回复，看到相同的对话，无需学习任何新操作。同时，API 连接到同一个号码，可以发送、接收消息，并接入其他系统。 因此，问题不再是是否要放弃手机，而是您希望软件处理什么，以及您希望人工在任何时候接着同一段对话回复什么。 ### 连接后，手机上会有什么变化？ 几乎没有变化，而这正是重点。应用以相同方式打开，联系人列表不变，旧对话也全部保留。没有人需要在新的地方登录。 变化发生在手机上看不见的地方。API 发送的消息会出现在应用的对话中，因此回复的人能看到完整情况，而不是只看到一半。您在应用中输入的消息也会被 API 看到，这样软件就不会在人工已经回复后再次回复。 号码首次连接时，Meta 会同步大约 6 个月的历史记录，因此 API 不会从空白开始。您需要先知道两项限制：所有提供商的 Coexistence 号码都无法让 API 使用群聊，而且号码不能使用 WhatsApp 消费者应用，只能使用 WhatsApp Business 应用。 ### Coexistence 适合谁？ 有两类人，而他们希望从中得到的东西正好相反。 拥有一个号码和小团队的企业，希望手机继续使用，同时让软件自动处理重复工作，例如确认、提醒，以及营业时间以外的首次回复。他们不是要购买软件来取代任何人，而是想把晚上的时间还给自己。 代理机构、顾问公司或开发人员则希望从另一个角度使用它。他们服务许多企业，每个企业都有一个无法接触或迁移的号码，而他们需要让自己构建的系统连接这些号码。对于仍由客户员工手动回复的号码，Coexistence 是唯一的官方 API 接入方式。 两者归根结底需要同一件事：连接必须保持有效，并且有人要在连接失效时发现问题。 ### 为什么 Coexistence 连接需要监控？ 因为它可能在没有任何通知的情况下停止工作。 号码有质量评级和消息级别，Meta 会根据收件人的反应进行调整。评级会下降，级别会变化，访问令牌会过期。停止响应的 Webhook 目标端点不会永远持续重试。这些情况都不会在手机上触发警报，而应用仍会正常运行，所以通常要等客户说没有收到消息，您才会发现。 Meta 还有一项规则：如果连接连续 14 天没有 API 活动，就需要处理。这个规则并不隐蔽，也并不不公平，但很容易被忽略。 这就是 EasyCoexistence 监控的内容。我们会持续检查连接，发生变化时由我们通知您，而不是等客户告诉您。 1. Sign up: Create an account and add a card. The first 3 days are free, and nothing is charged until they end. 2. Run Embedded Signup: Meta's own flow opens, you pick the number, and you scan a code from the WhatsApp Business app. About two minutes. 3. Point it somewhere: Set the webhook destination to your own system, or add the MCP connector and let an assistant do it. The app on the phone carries on as before. - 尝试连接正在 WhatsApp 消费者应用上使用的号码。Coexistence 需要 WhatsApp Business 应用，号码必须先转到该应用。 - 以为群聊会传过来。所有提供商的 Coexistence 号码都无法让 API 使用群聊，因此任何围绕群组构建的功能都无法运行。 - 在客户最后一条消息超过 24 小时后，仍使用自由文本回复。在这个时间窗口之外，只有获批准的消息模板可以发送。 - 将 Webhook 指向无法响应 Meta 验证请求的 URL。Meta 会在交付任何内容前检查端点，静默失败看起来就像设置正常。 **我的团队必须停止使用手机吗？** 不必。这正是 Coexistence 的意义。WhatsApp Business 应用会继续在同一号码上运行，保留相同的对话，同时 API 与它并行运行。 **我会失去现有对话吗？** 不会。对话会保留在应用中，号码连接时 Meta 会将大约 6 个月的历史记录同步到 API，因此软件能获得上下文，而不是从空白开始。 **我可以撤销吗？** 可以。您可以断开号码，应用会继续像以前一样运行。连接本身不会永久改变号码。 **这和非官方 WhatsApp API 一样吗？** 不一样，这是不同产品。Coexistence 是 Cloud API 上的 Meta 官方功能；非官方网关通过已连接设备驱动 WhatsApp Web，会违反条款并导致号码被封禁。其费用不包含在 EasyCoexistence 订阅中，需向各提供商另行支付。 --- ## 非官方 WhatsApp API：究竟是什么导致号码被封 https://easycoexistence.com/zh-hans/unofficial-whatsapp-api-risks 非官方 WhatsApp API 通过登录为已连接设备，自动操作 WhatsApp Web 会话。这样违反 WhatsApp 条款，Meta 会检测这种模式，号码也会被封。官方 Cloud API 则通过 Meta 支持的接口完成相同工作，并使用企业已经在用的号码。 ### 非官方 WhatsApp API 如何运作？ 不管营销说法如何，它们底层做的事情都一样。它们打开 WhatsApp Web 使用的协议，把自己作为已连接设备配对到账户，然后通过程序操作该会话。库从套接字读取收到的消息，再通过套接字推送发出的消息。 这就是它们价格低、几分钟内即可安装，以及能够使用官方 API 未开放功能的原因。无需申请账户，也无需通过审核。扫描二维码后，您就能开始发送消息。 这也是号码面临风险的原因。这个会话没有任何部分得到认可。WhatsApp 条款禁止自动化或批量使用消费者客户端，而已连接设备就是消费者客户端。便利和暴露风险，其实是同一事实的两面。 ### Meta 究竟如何检测？ 不是通过查找库名称，很多人以为是这样，所以认为重写代码就能解决问题。检测依据是行为，系统会观察流量的形态。 这些信号正是自动化自然产生的信号。发送消息与收到回复的比例，因为真实对话大致平衡，而群发并不平衡。联系人图谱中的距离，因为向从未联系过您、也没有共同联系人的人发送消息，与正常使用完全不同。时间规律性，因为人类不会以固定间隔发送消息。收件人举报的权重很高，而且通常最快到达。 因此，网关运行了一年并不能证明安全，只能证明流量尚未越过某个阈值。这个阈值不取决于发送消息的库。 ### 号码被封究竟要付出什么代价？ 代价超过自动化本身曾经带来的价值，而这正是最容易被低估的部分。 号码会停止工作。不是自动化停止，而是号码停止。号码上的每段对话都会变得无法联系，对话中的客户也不知道发生了什么，只是再也收不到回复。对于把号码印在车辆、店面、名片或数千张旧发票上的企业来说，这个号码更像电话线路，而不是一款软件。 历史记录也会一并失去。那些对话中积累的联系人列表也一样。您可以提出申诉，有时会成功，但过程缓慢，没有人能保证结果。 对于代理机构，账算起来更糟，因为停止工作的号码属于客户，而客户从未被告知这就是运作机制。 ### 官方路线是什么样的？ 过去，人们反对官方 API 是有实际原因的。它意味着迁移号码，这会让手机上的 WhatsApp Business 应用停止工作，因此小团队不会接受这种方案。 Coexistence 消除了这个顾虑。这是 Meta 自己提供的模式，让 WhatsApp Business 应用和 Cloud API 同时使用同一个号码。团队仍可用手机回复，聊天记录和历史记录保持原样，API 也连接到同一条线路。没有已连接设备，没有保存在服务器上的会话，也没有值得窃取的凭据。 取舍确实存在，但影响不大。自由文本只能在客户最后一条消息后的 24 小时内发送，模板需要审核，群聊也不可用。换来的好处是，号码不会因为这种机制本身而被封。 - 相信宣传防封功能的库已经解决问题。检测观察的是流量行为，而不是发送代码的库，因此供应商无法控制这种说法所描述的结果。 - 把数月持续运行当作安全证明。这只表示流量尚未越过阈值，两者是不同的说法。 - 先用个人号码测试。个人号码被封确实麻烦，但无法说明企业号码的情况，后者承载的流量要高得多。 - 把非官方会话存放在共享服务器上。这些凭据可提供完整账户访问权限，也是已知的攻击目标。 **如果我使用这类工具，号码是否已经面临风险？** 只要会话仍在运行，风险就一直存在。风险不会在固定日期触发，所以长时间持续运行并不能让人放心。您可以在不丢失应用的情况下，把同一个号码转到官方 API。 **我可以转到官方 API 而不更换号码吗？** 可以。Coexistence 会连接您已经在使用的号码，WhatsApp Business 应用在手机上也会一直正常工作。无需迁移任何内容。 **官方 API 有哪些功能做不到？** Coexistence 号码不支持群聊。自由文本只能在客户最后一条消息后的 24 小时内发送，超过这个时间后，消息必须使用 Meta 已批准的模板。 **官方路线的费用更高吗？** 无论采用哪种方式，Meta 都会收取自己的消息费用，并直接向您计费。区别在于按号码收取固定月费，而不是承担号码丢失的风险。 --- ## 通过官方 Cloud API 将 WhatsApp 连接到 n8n https://easycoexistence.com/zh-hans/integrations/n8n 将 Webhook 目标指向 n8n Webhook 节点后，发送到该号码的每条消息都会触发工作流。回复可通过 Cloud API 发送，也可通过我们的 MCP server 发送。n8n 的 MCP Client Tool 支持 OAuth2，因此能够连接。整个过程中，手机仍可正常使用。 ### WhatsApp 消息如何进入 n8n 工作流？ Meta 会通过 HTTP POST，将发送到该号码的每条消息传送到您指定的单个 URL。这个 URL 就是整个集成。将 n8n Webhook 节点放在生产 URL 上，把它设置为该号码的 Webhook 目标，工作流就会在每条收到的消息到达时运行。 负载包含发送者、文本或媒体引用、时间戳和消息 id。接下来就是普通的 n8n 工作流：按内容分支、查询客户、调用您运行的其他服务，并决定是否回复。 由于这是 Coexistence，同一条消息也会出现在手机上的 WhatsApp Business 应用中。人工可以回复。工作流能看到人工发送的内容，人工也能看到工作流发送的内容，因此双方不会互相覆盖回复。 ### 工作流如何发送回复？ 使用 HTTP Request 节点调用 Cloud API，并提供该号码的 phone number id 和 access token。这两个字段可以从控制台读取，也可以通过 MCP connector 获取，交由助手代为查询。 要发送什么取决于时间，这是最容易出错的部分。在客户最后一条消息后的 24 小时内，可以使用自由文本，回复内容由工作流自行编写。超过这个时间窗口后，只有 Meta 已批准的模板才能发送。只发送自由文本的工作流在测试时看起来一切正常，因为测试总是在消息发出几秒后进行，但第一次真正的隔夜场景就会停止响应。 稳妥的做法是设置分支：先检查最后一条收到的消息距今多久，再相应选择自由文本或模板。 ### n8n 也能使用 MCP connector 吗？ 可以，而且 n8n 在这方面很少见。它的 MCP Client Tool 节点可以连接远程 MCP server，并支持 OAuth2，这正是我们的连接器所需的功能。因此，工作流中的 AI Agent 节点可以直接调用我们的工具。 这一点值得注意，因为大多数自动化平台无法做到。Make 和 Zapier 都运行自己的 MCP server，但都不能充当客户端，因此都无法连接第三方 server。n8n 可以。 它适合处理执行部分：工作流运行时，由 agent 节点决定发送消息、检查号码的连接状态，或读取模板的审批状态。它不能取代 Webhook，因为 MCP 没有办法因收到消息而被唤醒。 ### 工作流应该使用哪一个？ 两者都要用，但分别负责不同部分，这不是偏好问题。 Webhook 负责启动流程。客户发来消息，Meta 将消息传送到您的 Webhook 节点，工作流随即运行。任何工具都没有 MCP 的对应功能，因为该协议采用请求和响应模式，不能被主动调用来接收事件。 MCP Client Tool 用于让工作流中的 agent 执行操作，而无需您把调用逻辑硬编码进去。如果工作流已经明确知道要发送什么，使用 HTTP Request 节点调用 Cloud API 更简单，出错点也更少。如果由 agent 做决定，连接器会提供 16 个工具及其说明中的规则，包括 24 小时窗口。 ### 这与人们已经在使用的 n8n WhatsApp 节点有什么不同？ 您在实际使用中看到的大多数 n8n WhatsApp 设置，都建立在非官方网关上，并以已连接设备的方式登录。这些方案容易开始使用，却会让号码面临风险，因为这种机制违反 WhatsApp 的条款，Meta 检测的是流量模式，而不是所用的库。 另一条常见路线是不使用 Coexistence 的官方 API。它可以运行，但会迁移号码。WhatsApp Business 应用会在该号码上停止工作，原本全天回复消息的团队必须转移到新工具。对大多数小型企业来说，这不可接受，所以许多企业最初才会使用非官方网关。 Coexistence 补上了缺失的组合：使用官方 API，同时保留手机上的应用。 - 将 n8n Test URL 用作 Webhook 目标。编辑器关闭后，它就会停止监听，消息也就无处投递。 - 没有响应 Meta 的验证请求。在开始投递消息前，Meta 会发送带有 challenge 的 GET 请求；如果节点没有原样返回它，就永远收不到消息。 - 在 24 小时窗口外使用自由文本回复。从工作流角度看，这通常会静默失败，只有已批准的模板才能发送。 **我需要为此安装单独的 n8n 节点吗？** 不需要。Webhook 节点负责接收，HTTP Request 节点负责发送。无需安装任何东西，因为集成就是一个 URL 和一次 REST 调用。 **团队仍然可以用手机回复吗？** 可以。这就是 Coexistence 的含义。WhatsApp Business 应用会在同一个号码上继续运行，工作流和人工都能看到对方发送的消息。 **一个工作流可以处理多个客户的号码吗？** 可以。将每个号码都指向同一个 Webhook，并根据负载中的 phone number id 进行分支。一个账户可以容纳您所需的任意数量号码。 **如果我的 n8n 实例停止运行，会发生什么？** Meta 会在一段时间内重试投递，之后停止。消息仍会到达手机上的 WhatsApp Business 应用，因此对企业而言不会丢失，只会无法进入工作流。 --- ## 使用自定义连接器将 WhatsApp 连接到 Claude https://easycoexistence.com/zh-hans/integrations/claude 在 Claude 中添加 https://easycoexistence.com/api/mcp 作为自定义连接器，然后登录。之后，Claude 可以列出您的号码、检查连接状态、发送消息和模板，并将 Webhook 指向您自己的系统。所有操作都基于 Meta 的官方 Cloud API，而不是已连接设备会话。 ### 如何将它添加到 Claude？ 在 Claude 中打开设置，添加指向 EasyCoexistence MCP 端点的自定义连接器。Claude 会打开登录页面，您完成授权后，工具就会出现。无需生成密钥，也无需将任何内容粘贴到配置文件中，因为连接器使用 OAuth。 Claude Desktop 使用同一个连接器，可在 Settings 的 Connectors 中添加。它的配置文件只描述由自身启动的本地服务器，因此不会在其中写入这样的远程端点。 无论使用哪种方式，服务器本身都是远程的。不会安装任何内容，不会在您的笔记本电脑后台运行任何程序，关闭应用也不会造成影响。无论 Claude 是否打开，号码都会保持连接。 ### Claude 连接后可以做什么？ 您可以用普通语言提出请求，Claude 会选择相应工具。比如：我的哪些号码连接状态不佳？向这位客户发送预订确认。为订单更新创建消息模板，并在 Meta 批准后通知我。将这个号码的 Webhook 指向我的服务器。 读取工具是人们每天都会使用的功能：列出号码、检查号码的质量评级、消息等级和连接状态，以及在其他系统需要时获取凭证。发送工具支持在会话窗口内发送自由文本，也支持在窗口外发送已批准的模板。 对于为客户提供服务的人来说，最重要的是启动连接和设置 Webhook 目的地。这意味着 Claude 可以为客户接入号码，并将其连接到您的系统，无需任何人打开控制台。 ### 这样操作，号码会被封禁吗？ 不会，关键在于底层连接方式，而不是 Claude 本身。 人们通常找到的 WhatsApp MCP 服务器，会将 WhatsApp Web 作为已连接设备运行。这违反 WhatsApp 的条款，Meta 会根据流量行为检测到这一点，因此无论由哪个助手发出指令，号码都可能被封禁。使用更谨慎的助手也没有帮助，因为被禁止的是这种机制。 这个连接器通过 Meta 自己的 Coexistence 功能，在已通过 Meta 流程接入的号码上调用官方 Cloud API。没有已连接设备，不会在任何地方保留会话，也不违反相关条款。适用的是通常的限制：客户最后一条消息后的 24 小时内只能发送自由文本，超过窗口后只能发送已批准的模板，而且不支持群聊。 **这适用于 Claude Code 和 Claude 应用吗？** 适用。这是一个通过 HTTP 提供并使用 OAuth 的远程 MCP 服务器，因此任何支持自定义连接器的产品都可以使用，包括 Claude Code、ChatGPT 和 Cursor。 **Claude 能看到客户的对话吗？** 只有您要求它查看的内容。传入消息会从 Meta 路由到您指定的 Webhook 目的地，我们不会保存对话内容。 **Claude 可以自行连接新号码吗？** 它可以启动流程。连接器会返回一个链接，由企业所有者打开并通过 Meta 的流程授权自己的号码。这一步只有号码所有者可以完成。 **如果 Claude 尝试在窗口外发送消息，会怎样？** Cloud API 会拒绝请求，Claude 会看到错误，因此可以改用已批准的模板。不会有任何消息被静默丢弃。 --- ## WhatsApp Cloud API 还是 Coexistence：号码需要哪一种 https://easycoexistence.com/zh-hans/whatsapp-cloud-api-vs-coexistence Coexistence 不是 Cloud API 的替代品，而是接入它的一种方式。普通 Cloud API 号码完全归软件使用。Coexistence 号码可同时运行 API 和 WhatsApp Business 应用，因此团队仍可通过手机回复消息。 ### Cloud API 和 Coexistence 实际上是不同的东西吗？ 不是，这种说法容易让人混淆。Cloud API 是 Meta 托管的 WhatsApp Business Platform。Coexistence 是让号码接入同一个 API 的一种模式，接入后 WhatsApp Business 应用仍可继续使用该号码。 因此，端点相同，消息格式相同，模板的运作方式相同，24 小时窗口也完全一致。针对其中一种方式编写的内容，也适用于另一种方式。 两者的区别在于手机端会发生什么。以普通方式接入号码后，Business 应用会停止使用该号码：号码从此归软件使用，原本负责回复的人必须通过已搭建的系统回复。通过 Coexistence 接入后，两种界面都处于启用状态，而且双方都能看到对方发送的内容。 ### 什么时候应选择普通 Cloud API？ 当没有人需要通过手机手动回复这个号码时，这种情况其实比想象中更常见。 只发送订单更新的通知号码，不需要保留人工操作。一开始就是为了接入系统而购买的新号码，也从未在任何人的应用中使用。已经通过帮助台运行的高消息量支持热线，其人工流程完全在别处进行；重新加入 WhatsApp Business 应用反而会把流程分散。 在这些情况下，Coexistence 只是平白增加限制：Coexistence 号码的吞吐量由 Meta 固定，不会随着质量评级和消息层级扩展；此外，定期保持设备活动也是您必须承担的维护要求，却没有带来实际好处。 ### 什么时候只有 Coexistence 才能正常运作？ 当号码已经用于业务，而且已经有人通过手机回复时。 大多数小型公司都属于这种情况，代理机构接手的号码基本也都是如此。号码印在车辆、店面、发票和网站上。有人白天用手机回复，也记得每位老客户的名字。告诉这个人应用将停止使用，沟通通常就到此为止，这也是许多企业最终使用非官方网关，而不是官方 API 的原因。 Coexistence 消除了这个取舍。应用继续运作，团队无需学习新的操作方式，软件也能获得原本就会使用的同一个 API。 ### 之后可以在两者之间切换号码吗？ 号码可以断开连接后重新连接，因此这个决定并不像很多人担心的那样永久。真正永久的是聊天记录的选择。 号码首次通过 Coexistence 连接时，Meta 会询问是否要将现有对话共享给 API。这是一次性的接入决定，之后无法重新选择。如果当时拒绝，后来又需要这些内容，唯一的方法就是先断开连接，再重新连接。 所以真正需要谨慎的，不是哪一种模式，而是当天是否同意共享历史记录，因为这个选择之后不会再次出现。 - 把 Coexistence 当成较低级的 API。它使用的是同一个 Cloud API，只是通过不同方式接入，端点和规则也完全相同。 - 为无人手动回复的号码选择 Coexistence。这样会增加设备活动要求和固定吞吐量上限，却换来一个并不存在的手机操作流程。 - 接入时拒绝共享聊天记录，却以为之后可以补充。这个选择只能做一次，之后无法更改。 **Coexistence 比普通 Cloud API 慢吗？** Coexistence 号码的吞吐量由 Meta 固定，不会随着质量评级和消息层级扩展。对于对话式使用，这个上限很少成为限制，但对高消息量发送可能会造成影响。 **两种方式的模板运作方式相同吗？** 相同。模板会提交给 Meta 审核，并以相同方式通过 API 发送。使用 Coexistence 号码时，手机应用无法发送模板，因此 24 小时窗口之外的消息必须通过 API 发送。 **可以把全新的号码放到 Coexistence 上吗？** 号码必须先在 WhatsApp Business 应用中注册，因为 Coexistence 连接的是应用已经在使用的号码。如果没有人会通过手机手动回复，普通 Cloud API 接入方式更合适。 **代理机构为客户号码使用哪一种？** 几乎总是 Coexistence。客户号码通常已经由员工负责回复，迁移后 WhatsApp Business 应用会无法使用，客户不会同意这种安排。 --- ## WhatsApp 错误 131047：重新互动消息 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131047 错误 131047表示客户超过 24 小时未发消息，因此客户服务窗口已关闭，自由文本不会送达。只有 Meta 已批准的消息模板才能重新开启对话。 ### 什么会导致错误 131047？ 向某人发送自由文本时，对方上次给您发消息已经超过 24 小时。 WhatsApp Business 平台只允许企业在客户服务窗口内自由发消息。客户向您发消息时，窗口会开启，并持续 24 小时。在窗口内，您可以发送任何内容。窗口关闭后，API 会以 131047 拒绝自由文本，而不会送达收件人未主动要求的消息。 这个错误会在正式环境出现、测试时却不出现，原因在于时间。测试集成时，通常刚发出消息，几秒后就收到回复，始终处于窗口内。第一次隔夜处理，或第一次遇到客户沉默一天，才会出现这个错误。 ### 如何修复？ 改为发送获批准的消息模板，不要发送自由文本。 消息模板是您预先提交给 Meta、由 Meta 审核的消息。获批准后，您可以随时发送消息模板，包括发送给从未联系过您的对象。发送消息模板会重新开启对话；客户回复的那一刻，您就会获得新的 24 小时自由文本窗口。 因此，持久的修复方式不是重试，而是加入分支：发送前，检查该联系人上次发消息距今多久。未超过 24 小时，发送自由文本；超过 24 小时，发送适合当前情况的消息模板。只会发送自由文本的集成会持续遇到这个错误，而对监看对话的人来说，结果看起来更像是没有回应。 ### Coexistence 号码也适用吗？ 适用，而且还有一个值得注意的后果。 无论号码是否通过 Coexistence 完成接入，窗口规则都完全相同，因为这是平台规则，不是某种接入模式的规则。不同之处在于谁可以执行操作。在 Coexistence 号码上，WhatsApp Business 应用无法发送消息模板，因此窗口外的消息必须通过 API 发送。 这意味着，团队可以用手机自由回复正在进行的对话，却无法从应用重新开启冷淡的对话。重新开启对话属于 API 工作，这也是企业一开始连接号码的实际原因之一。 - 重试同一条自由文本。窗口不会自行重新开启，因此重试会以相同方式失败。 - 从您上次发消息的时间计算窗口，而不是从客户上次发消息的时间计算。是客户的消息开启窗口。 - 以为消息模板可以编写后立即发送。Meta 会先审核，通常几分钟内完成，但有时需要一天。 **我可以延长 24 小时窗口吗？** 不可以。窗口由 Meta 固定，任何供应商都无法延长。只有客户再次给您发消息，才能重新开启窗口。 **客户回复消息模板后，窗口会重新开启吗？** 会。客户发送的任何消息都会开始新的 24 小时窗口，包括回复您发送的消息模板。 **我应该使用哪种消息模板类别？** 交易类消息使用 Utility，推广类消息使用 Marketing。发送 Marketing 消息时，您自己的 WhatsApp Business Account 必须设有付款方式。 **错误 131047和 131049 相同吗？** 不相同。131047表示窗口已关闭；131049表示 Meta 为保护生态系统健康而限制送达，这是另一种情况。 --- ## WhatsApp 错误 131049：为维护生态系统健康而拦截消息 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131049 错误 131049 表示 Meta 为维持健康的生态系统互动，决定不送达这条消息。这不是 24 小时窗口问题，也不是消息模板问题。Meta 的指引是，至少等待 24 小时后，再次尝试向该收件人发送消息。 ### 这里所说的生态系统互动到底是什么意思？ 这是 Meta 用来描述收件人是否愿意接收企业消息的说法，评估范围涵盖整个平台，而不只是您的账户。 当平台判断某次发送可能不受欢迎时，就会拦截该消息并返回 131049。这是针对消息和收件人的判断，不是您违反了某条固定规则，因此即使账户的质量评分看起来正常，也可能出现这个错误。 它最常出现在向近期没有互动的收件人发送营销消息时，也常见于短时间内批量发送大量相似消息。这是对发送模式的信号，不是对号码施加的处罚。 ### 为什么发送消息模板也无法解决？ 因为消息模板从来不是问题所在。 看到发送被拦截后，人们往往会改用消息模板，因为这是另一种常见错误 131047 的解决方式。但 131047 是时间规则：窗口已经关闭，获批准的消息模板是重新开启窗口的合规方式。131049 则是针对这条消息和这位收件人的决定，而消息模板使用的仍是同一送达路径。 无论是否使用消息模板，立即重试都可能强化触发拦截的模式。Meta 自己的指引是，至少等待 24 小时后再尝试向该收件人发送消息，并检查消息是否真的是对方可能想收到的内容。 ### 如何避免再次发生？ 改变发送的内容，而不是发送的方式。 向近期有互动的人发送消息，不要向整份名单发送。调整内容，因为批量发出几乎完全相同的消息，正是系统关注的模式。优先发送与客户操作相关的实用消息，例如订单或预约信息，而不是广播式促销。 同时观察质量评分和消息层级也很重要，因为它们会因同一个根本原因变化：收件人的负面反应。质量评分开始下降时，通常会先出现更多这类错误，之后才可能出现更严重的限制。及早发现变化，才能及时调整，避免受到限制。 - 把它当成 24 小时窗口问题，然后改用消息模板。这是不同的情况，但结果相同。 - 立即重试。Meta 的指引是，至少等待 24 小时后再向该收件人发送。 - 把它理解为封禁。号码仍在正常工作，只是这条消息没有送达。 **我的号码被封禁了吗？** 没有。131049 只会拦截一条消息。号码仍可正常使用，其他消息也可能成功送达。 **我应该等待多久？** Meta 的指引是，至少等待 24 小时后再向该收件人发送消息。目前没有公布确切时长。 **这会影响我的质量评分吗？** 这与同一个根本指标有关，因此频繁出现时，应视为质量下降的早期警报，而不是孤立的错误。 **服务提供商可以绕过这个限制吗？** 不可以。这项限制由 Meta 在送达时执行，因此所有使用官方 API 的服务提供商都会看到相同的行为。 --- ## WhatsApp 错误 131048：达到垃圾消息发送限制 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131048 错误 131048 表示 Meta 因号码质量下降而限制发送，通常是收件人屏蔽或举报消息后出现。号码仍然可以使用。变化在于质量恢复期间，它获准发送的消息数量减少了。 ### 是什么导致号码质量下降？ 收件人的负面反应会导致质量下降，Meta 会根据这些反应衡量，而不是从您的代码推断。 相关信号包括屏蔽、举报，以及更不明显的情况：人们只是没有回复原本需要回复的消息。一个发送很多消息却很少收到回复的号码，和一个持续进行对话的号码看起来不同。这种差异会累积，最终影响质量评级。 评级会在绿色、黄色和红色之间变化。变为红色后，发送就会开始因这个错误失败。手机不会提示任何变化，而且 WhatsApp Business 应用在整个过程中仍可正常运行。因此，对大多数企业来说，第一个迹象不是警告，而是发送失败。 ### 号码如何恢复？ 如果停止导致质量下降的发送行为，质量会自行恢复。 质量是滚动衡量的指标。近期发送获得更好的反应后，评级会回升，发送限制也会随之解除。您不需要提交申诉，服务商也无法通过开关解决这个问题，这也意味着没有人可以向您出售所谓的修复方案。 真正有帮助的是缩小收件人范围。向近期有互动的人发送消息。相比群发推广，优先发送与客户操作相关的实用消息。不要再向名单批量发送，而应针对具体个人发送。导致评级下降的模式，也正是让评级持续低下的模式，因此改变这种模式，恢复才会开始。 ### 发送失败前，如何知道质量正在下降？ 只能直接观察评级本身。这正是应当监控连接，而不只是连接号码的最清楚理由。 Meta 会在电话号码上显示质量评级和消息层级，而且这些指标会在造成损失前发生变化。号码从绿色变为黄色，表示仍有时间采取行动的警告。号码变成红色并开始返回这个错误时，已经有消息发送失败了，而这些受影响的消息不会排队等待发送。 质量下降不会显示在 WhatsApp Business 应用中，因此团队从手机上回复时，一直到发送停止前，看到的都仍像是业务正常。 - 把它当成发送代码中的错误。请求没有问题，受限制的是号码。 - 更换服务商以规避问题。评级归属于号码，并会随号码保留。 - 等待通知。手机不会提示质量下降。 **我仍然可以接收消息吗？** 可以。接收不受影响，WhatsApp Business 应用也会继续在该号码上正常运行。 **恢复需要多长时间？** Meta 没有公布具体时长。质量是滚动衡量的指标，因此会随着近期发送情况改善而提升，而不是等待固定期限后恢复。 **更换服务商会重置质量吗？** 不会。质量附属于电话号码，而不是发送消息的服务商。 **这和被封禁一样吗？** 不一样。封禁会移除号码。这里限制的是正常使用中的号码在质量恢复前可以发送的消息数量。 --- ## WhatsApp 错误 132001：模板不存在 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132001 错误 132001 表示您要发送的模板在指定语言中不存在，或存在但未获批准。模板由名称和语言共同识别，因此同名的不同语言版本是不同模板。 ### 为什么已存在的模板仍会返回 132001？ 几乎总是因为语言代码不对。 模板由名称和语言共同识别。以 en_US 创建的 order_update 模板，在 en、pt 或 pt_BR 中并不存在。使用正确名称但错误语言区域发送时，就会产生这个错误，而错误消息不会明确指出是哪一部分不对。 第二个原因是批准状态。已创建但仍在等待审核的模板无法发送，被拒绝的模板也一样。两者返回的代码与从未创建过的模板相同，因此在认定名称错误前，值得先检查状态。 ### 如何找到正确的名称和语言？ 列出该号码上的模板并读取实际结果，不要只相信已配置的内容。 列表会显示每个模板的准确名称、准确语言代码和审核状态，一次解决导致此错误的 3 个原因。这也是唯一可靠的来源，因为创建模板的操作记录名称后，模板仍可能被编辑或拒绝。 通过 MCP 连接器，这不是 API 调用，而是一个问题：询问某个号码上哪些模板已获批准，助手就会读取结果。使用您自己的代码时，则是针对 WhatsApp Business Account 发出单个 Graph 请求，并使用该连接的 phone number id 和 token。 ### 审核通常需要多久？ 通常只需几分钟，有时最长可达 1 天。 Meta 会在模板可以发送前审核每个模板。大多数模板很快就会完成审核，但时间无法保证，服务提供商也无法加快审核。这对创建模板后立即发送的流程很重要，因为审核仍在等待时，发送会因这个错误而失败。 更稳妥的做法是在设置连接时提前创建模板，然后在使用前检查状态。通过连接器的助手可以完成这两步：提交模板，然后报告它已获批准、已拒绝，还是仍在审核中。 - 模板创建时使用的是 en_US，却发送 en。对于 API 来说，它们是不同的模板。 - 创建模板后在同一轮操作中发送。Meta 会先审核模板。 - 以为被拒绝的模板仍然可以使用。它会和缺失模板一样返回此错误。 **在哪里可以看到准确的语言代码？** 在该号码的模板列表中。列表会同时显示名称、语言和状态，这是唯一可靠的来源。 **可以发送待审核的模板吗？** 不可以。只有已获批准的模板才能送达，待审核模板会返回相同的错误。 **被拒绝的模板必须重新创建吗？** 可以编辑后重新提交。但在被拒绝状态下，它无法发送。 **WhatsApp Business 应用可以发送模板吗？** 在 Coexistence 号码上不可以。模板必须通过 API 发送，这也是连接号码的实际原因之一。 --- ## WhatsApp 错误 132000：参数数量不匹配 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132000 错误 132000 表示您提供的变量与消息模板的要求不符。含有 2 个占位符的模板必须按顺序提供刚好 2 个值。有人编辑模板后，如果发送代码没有同步更新，就很容易出现此错误。 ### 消息模板变量如何计算？ 按组件分别计算，并按照消息模板文本中的编号占位符排列。 一个消息模板正文写着 Hello {{1}}, your order {{2}} has shipped，表示有 2 个变量。发送时，正文组件必须刚好提供 2 个值。提供 1 个或 3 个值，都会返回此错误。虽然提供了 2 个值，但它们属于错误组件，也会出现此错误，因为标题、正文和按钮参数是分别计算的，不会合并成一个列表。 因此，这个错误乍看之下常常令人困惑：值的总数可能正确，但分配到各组件的数量并不正确。 ### 为什么昨天还能正常使用的消息模板今天会出现此错误？ 因为有人编辑了消息模板，而发送代码没有同步修改。 消息模板获批后仍可编辑。添加或删除占位符，会在发送方不知情的情况下改变消息模板的约定。集成没有任何提示，下一次发送就会失败。如果营销团队在 WhatsApp Manager 中编辑消息模板，而工程团队负责发送代码，这就是最常见的错误原因。 解决方法是重新读取消息模板，而不是依赖首次建立时记录的数值。列出消息模板会返回当前定义，这才是发送时唯一重要的版本。 ### 如何正确提供变量值？ 构建与消息模板自身结构一致的组件数组。 每个组件都会标明类型，并按照占位符出现的顺序携带自己的参数。含有 2 个变量的正文，需要一个带有 2 个文本参数的正文组件。如果消息模板的标题也含有变量，还需要另外提供一个标题组件及其参数，而不是把标题值加入正文列表。 通过 MCP 连接器，您无需亲自完成这一步：助手会读取消息模板，确认每个组件有多少个占位符，再根据您的要求填入值。如果使用自己的代码，建议在启动时读取消息模板定义，而不是将可能变化的结构硬编码。 - 将标题和正文变量合并成一个列表。变量按组件分别计算。 - 硬编码变量数量。编辑消息模板后，变量数量会改变，发送方不会收到提示。 - 为未使用的占位符发送空字符串。消息模板仍然定义了该占位符，因此数量必须匹配。 **可以发送不含变量的消息模板吗？** 可以。如果消息模板没有定义变量，就不要发送参数。额外提供参数会返回此错误。 **值的顺序重要吗？** 重要。占位符按编号顺序填入，因此调换两个值会产生错误消息，而不是返回错误。 **为什么同一次发送在一种语言中有效，在另一种语言中却无效？** 每个语言版本都是独立的消息模板，编辑后可能含有不同数量的占位符。 **这是 132001 吗？** 不是。132001 表示找不到消息模板，或消息模板尚未获批。132000 表示已找到消息模板，但变量不匹配。 --- ## WhatsApp 错误 2593107：同步次数已用尽 https://easycoexistence.com/zh-hans/docs/whatsapp-error-2593107 错误 2593107 表示此号码已经完成一次联系人和聊天记录同步。每次接入只能同步一次，无法重复执行，因此必须先断开号码，再重新连接，才能再次运行同步。 ### 这里所说的同步是什么？ 这是把 Coexistence 号码已有的联系人和对话记录带到 API 端的步骤，因此软件不会在一个企业使用多年的号码上从零开始。 这项功能只因 Coexistence 而存在。按普通方式接入的号码没有以往的应用记录可供带入，也就没有内容需要同步。Coexistence 号码两者都有，Meta 会在号码连接时提供一次性转移。 所以，即使长期使用 Cloud API 的人，也可能不熟悉这个错误。它属于一种他们从未使用过的接入模式。 ### 为什么只能执行一次？ 因为它属于接入流程，而不是持续可用的功能，Meta 将其视为连接时作出的一次性决定。 企业所有者在 Embedded Signup 期间会被询问是否分享现有聊天记录。选择是，才能让同步运行。之后没有设置可以重新开启，也没有端点可以重复执行，所以第二次请求会返回此错误，而不是等待速率限制解除。 实际影响是，这个选择在当时比看起来更重要。有人快速完成接入，并因为觉得拒绝更安全而不分享历史记录，就作出了只有完全断开并重新连接才能重新考虑的决定。 ### 如果确实需要再次同步，会发生什么？ 必须先断开号码，再重新连接。这是真正的操作，不是修改设置。 重新连接会从头运行 Embedded Signup，包括在手机上扫描代码，并再次提供接受历史记录的机会。整个过程中，WhatsApp Business 应用不受影响，企业不会丢失任何内容。但这不是静默的后台操作，必须有人操作手机。 还有一个后果值得提前规划。断开连接会移除 Webhook 目标，因为该目标作为应用订阅上的覆盖设置存在，而不是绑定在号码上。重新连接会恢复发送和监控，但除非有人重新设置，否则不会恢复发送到您自己服务器的交付。 - 重试同步请求。同步只能执行一次，因此重试会返回相同错误，不会最终成功。 - 为了谨慎，在接入时拒绝聊天记录。这个选择只能通过重新连接号码来重新考虑。 - 重新连接时没有计划恢复 Webhook 目标，因为它会随应用一起被移除。 **普通 Cloud API 号码会出现这个问题吗？** 不会。同步只适用于 Coexistence 号码，因为只有它们有以往的应用记录需要带入。 **会同步多少历史记录？** Meta 会在接入时同步一段近期对话记录。具体数量由 Meta 决定，而不是由服务提供商决定。 **重新连接会导致手机上的聊天记录丢失吗？** 不会。断开并重新连接 API 端不会影响 WhatsApp Business 应用及其中的对话。 **2593108 是同一个问题吗？** 不是。2593108 表示在接入超过 24 小时后尝试同步，而不是表示同步已经执行过。 --- ## WhatsApp 错误 2593108：在 24 小时窗口外同步 https://easycoexistence.com/zh-hans/docs/whatsapp-error-2593108 错误 2593108 表示联系人和聊天记录同步在号码完成接入超过 24 小时后才启动。该时间窗口由 Meta 固定，超过后只能重新连接号码，才能进行同步。 ### 这是哪个 24 小时窗口？ 不是消息窗口，这正是此错误最容易引起混淆的地方。 WhatsApp Business Platform 有众所周知的 24 小时客户服务窗口，从客户最近一条消息开始计算，决定是否可以发送自由文本。这是完全不同的计时方式。它从 Coexistence 号码完成接入的那一刻开始计算，只决定联系人和聊天记录是否仍可同步过来。 除了都涉及同一个号码，这两个窗口没有任何关系。消息发送成功，也不能说明同步窗口仍然开放。 ### 为什么容易错过？ 因为接入和集成通常不在同一天完成，而且经常由不同的人负责。 常见情况是，企业负责人在下午连接号码，几天后代理商或开发人员才把它接入系统。等有人想起历史记录时，窗口通常已经关闭，失败结果也只是一个陌生的错误代码，而不是提前出现警告。 最好把同步视为接入流程的一部分，而不是集成流程的一部分。只要历史记录有价值，就必须在号码连接当天完成同步，然后再搭建其他内容。 ### 窗口关闭后有哪些选择？ 断开连接后重新连接号码，或者接受从没有历史记录开始。 重新连接会重新启动 Embedded Signup，包括在手机上扫描二维码，并打开一个新的窗口。WhatsApp Business 应用不会受到影响，因此无论选择哪种方式，企业原有的对话都不会丢失。需要付出的代价是再次有人在手机旁完成操作。 没有历史记录通常也没有问题。API 会从连接完成的那一刻起接收所有新消息，而大多数集成更关注新的对话，而不是旧记录。只有在需要立即查看客户过去背景时，历史记录才特别重要，这种情况其实比最初想象的少。 - 把这个窗口和消息窗口混为一谈。它们是分别计算不同事项的两个窗口。 - 等到集成工作开始后才处理历史记录。那时窗口通常已经关闭。 - 重新连接后没有恢复 Webhook 目标地址，断开连接后该地址不再保留。 **这和消息窗口的 24 小时是同一个吗？** 不是。这个窗口从完成接入开始计算，决定同步是否可用。消息窗口从客户最近一条消息开始计算，决定能否发送自由文本。 **可以延长这个窗口吗？** 不可以。窗口由 Meta 设定，任何服务提供商都无法延长。 **重新连接需要付费吗？** 重新连接不收取费用。但需要有人在手机旁再次扫描二维码。 **如果我从未同步历史记录，会怎样？** API 仍会从号码连接的那一刻起接收所有内容。只有在需要立即查看过去背景时，历史记录才重要。 --- ## WhatsApp 错误 131026：消息无法送达 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131026 错误 131026 表示 Meta 无法向该收件人送达消息。最常见的原因是该号码根本没有注册 WhatsApp，但客户端过旧或用户尚未接受相关条款，也会产生相同代码。 ### 为什么看似有效的号码无法送达？ 因为拥有电话号码，不等于该号码已使用 WhatsApp。 最常见的原因是，收件人从未用该号码注册 WhatsApp，或后来移除了该号码。单从号码格式无法看出这一点，所以从 CRM 导入的号码清单会大量产生这类错误：清单里有电话号码，但只有部分是 WhatsApp 号码。 另外两个较少见的原因也会产生相同代码。收件人可能使用过旧的 WhatsApp 客户端，无法接收当前发送的消息类型，也可能尚未接受某项新功能所需的条款。这两种情况都不在发送方可控制的范围内。 ### 收到此错误后应该怎么做？ 将此错误记录到联系人名下，并停止向该号码发送消息，不要重试。 问题出在收件人一方，因此立即重试会得到相同结果，安排稍后重试通常也一样。把它当作暂时性问题，只会让集成在永远无法接收消息的号码上消耗吞吐量。 更有效的做法是将联系人标记为无法通过 WhatsApp 联系，并把消息转到其他渠道。这样也能避免联系人清单随着时间推移悄然失效。如果该号码确实已注册 WhatsApp，应该由收件人解决问题，而不是由您处理。 - 按计划重试。问题在收件人一方，不会因为时间过去而自行消失。 - 把它当作格式问题。Meta 已识别该号码，并在送达时拒绝了消息，不是在验证时拒绝。 - 未筛选 CRM 清单就发送。电话号码不一定是 WhatsApp 号码。 **我可以先检查某个号码是否已注册 WhatsApp 吗？** 无法可靠检查，Meta 也没有提供号码查询功能。实际操作中，首次发送就是检查。 **这会影响我的质量评级吗？** 无法送达的收件人与屏蔽或举报您的收件人并不相同，但向充满这类号码的清单大量发送，最终可能在其他指标中体现出来。 **问题是号码格式吗？** 通常不是。格式错误的号码会返回参数错误。此代码表示号码已被识别，但无法联系到。 **我应该删除该联系人吗？** 将其标记为无法通过 WhatsApp 联系，不要删除。此人以后可能会用该号码注册。 --- ## WhatsApp 错误 131042：商业账户付款问题 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131042 错误 131042 表示 Meta 无法向 WhatsApp Business 账户收取消息费用，因为账户没有可用的付款方式。这些费用由 Meta 直接向您收取，因此应在 WhatsApp Manager 中处理，而不是联系提供 API 访问权限的服务商。 ### 实际是谁向谁收费？ 涉及两家公司，只有其中一项费用与您的服务商有关。 Meta 会针对 WhatsApp Business Platform 上的对话收费，并从您自己的 WhatsApp Business 账户所绑定的付款方式中扣款。您与 Meta 之间存在这项收费关系。服务商在旁边提供访问权限和工具并收费，完全不会接触这些对话费用。 因此，联系服务商无法解决此错误，服务商也无法代您添加银行卡。这也表示，服务商无法对从未经过它的对话费用加价。 ### 在哪里设置付款方式？ 在 WhatsApp Manager 中的 WhatsApp Business 账户内设置，该账户拥有相关号码。 您可以在那里添加或更新付款方式，而且账户必须先完成设置，某些发送操作才会正常运行。营销模板发送尤其需要付款方式，所以当账户过去只回复客户、首次尝试发送推广消息时，往往会出现此错误。 API 刻意不支持这项操作。API 没有用于绑定银行卡的端点，因为这是账户层面的商业关系，而不是消息操作。 - 要求服务商修复问题。收费关系存在于您与 Meta 之间，任何 API 都无法绑定银行卡。 - 以为服务商费用包含消息费用。两者是不同公司收取的两项费用。 - 在没有付款方式的账户上尝试营销模板。Meta 要求此类发送必须设置付款方式。 **EasyCoexistence 可以代我向 Meta 付款吗？** 不可以。费用会从您自己的 WhatsApp Business 账户所绑定的付款方式中扣除，而且没有用于绑定付款方式的 API。 **为什么现在才出现此错误？** 通常是因为您首次尝试发送营销模板。Meta 特别要求此类发送必须设置付款方式。 **这会停止接收消息吗？** 接收消息不受影响。失败的是需要向 Meta 付费的发送操作。 **有没有办法完全避免 Meta 的费用？** 24 小时客户服务窗口内的回复免费。Meta 收费的是在该窗口之外开启的对话。 --- ## WhatsApp 错误 133010：号码未注册 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133010 错误 133010 表示该号码尚未完成 WhatsApp Business Platform 注册。号码可能已关联账户，并显示在控制台中，但在注册完成前无法发送任何消息。 ### 这里所说的注册究竟是什么？ 这是让号码可以发送消息的最后一步，和号码已存在于 WhatsApp Business Account 中是两回事。 入门流程会将号码关联到账户，并提供其标识符。注册则是告诉平台该号码已经可以发送消息。由于控制台通常在这时已经显示号码，用户可能没有意识到自己跳过了这一步。看起来一切都已连接，但第一次发送就会失败。 对于 Coexistence 号码，这一点更容易被忽略，因为手机上的 WhatsApp Business 应用在整个过程中都能正常运行，企业的日常使用不会显示任何流程尚未完成的迹象。 ### 入门流程为什么会变得不完整？ 通常是因为有人关闭了窗口。 Meta 的 Embedded Signup 会以弹窗运行，其中包含多个步骤，包括用手机扫描二维码。号码出现后，如果在流程完成前关闭弹窗，就会留下这种状态。流程进行到一半时手机连接中断，或有人去寻找设备时会话超时，也会造成同样的问题。 解决方法是重新运行流程，而不是重试发送。重新连接会从头开始并完成注册，重复操作不会影响号码或 WhatsApp Business 应用。 - 重试发送。仅仅尝试发送消息并不会完成注册。 - 以为控制台中显示的号码就是可用号码。它可能已关联账户，但仍未注册。 - 从手机端判断问题。无论注册是否完成，WhatsApp Business 应用都可能正常运行。 **号码丢失了吗？** 没有。再次运行 Meta 的入门流程即可完成注册，WhatsApp Business 应用在整个过程中不受影响。 **可以通过 API 注册吗？** 注册属于 Meta 的入门流程，需要浏览器和手机。没有 API 捷径可以跳过扫描。 **为什么我仍然可以接收消息？** 接收和发送不受同一个步骤控制，因此入门流程未完成的号码从手机端看起来仍可正常使用。 **这和 133006 是同一个问题吗？** 不是。133006 表示号码需要先验证，之后才能注册。133010 表示注册本身从未完成。 --- ## WhatsApp 错误 190：访问令牌已过期 https://easycoexistence.com/zh-hans/docs/whatsapp-error-190 错误 190 表示请求使用的访问令牌已过期或失效。每次调用都会以相同方式失败，看起来像是号码消失了。其实号码通常没有问题，出错的是凭据。 ### 为什么令牌过期会像号码丢失？ 因为每个请求都会失败，而且失败方式完全相同。 读取号码、检查连接状态、列出模板和发送消息会同时停止工作。从外部看，这与号码已从账户移除无法区分，而只使用一个凭据的集成也无法判断两者。很多人因此以为自己已断开连接，但事实并非如此。 两者的处理方式完全不同。凭据损坏时应更换凭据。号码被移除时则必须重新连接，这需要业务负责人和手机参与。 ### 如何区分两种情况？ 使用能够读取同一账户的第二个凭据。 EasyCoexistence 会为每个连接保存客户的令牌和自己的系统用户令牌。一个令牌被拒绝时，另一个令牌会读取 WhatsApp Business 账户，从而确认究竟是哪一个出了问题。客户令牌被拒绝，但第二个令牌仍能读取，说明凭据已过期而号码正常。两者都失败，则说明号码本身可能发生了变化。 没有第二个读取凭据时，唯一的区分方法是请业务负责人检查，而这正是监控应该避免的中断。 ### 令牌为什么会失效？ 原因有多种，而且大多数并非有意为之。 令牌有有效期限，会自行过期。Meta 账户密码变更会使令牌失效。在业务设置中移除应用访问权限也会导致失效，Meta 认定令牌已遭泄露并撤销时同样如此。这些情况通常不会提前发出警告，也无法从手机上的 WhatsApp Business 应用中看到。 因此，令牌有效性应纳入监控，而不是只交给错误处理程序。错误处理程序发现问题时，发送通常已经失败。 - 重新连接号码。如果问题出在令牌，重新连接只会让业务负责人执行本来不需要的操作。 - 把它当作间歇性问题并重试。失效的令牌不会自行恢复。 - 只依赖一个凭据。只有一个令牌时，无法区分凭据失败和号码丢失。 **号码还能使用吗？** 通常可以。WhatsApp Business 应用不受影响，号码本身也没有损坏。停止的是 API 访问。 **错误 0 是同一回事吗？** 实质上是。Meta 会根据端点，在这两种代码下报告相同情况。 **重新连接能解决问题吗？** 可以，但这是用繁重办法处理简单问题，而且需要业务负责人和手机；新凭据就能解决。 **可以让令牌永不过期吗？** 系统用户令牌可以长期有效，这也是保存第二个令牌有用的原因之一。 --- ## WhatsApp 错误 130429：已达吞吐量上限 https://easycoexistence.com/zh-hans/docs/whatsapp-error-130429 错误 130429 表示此号码的 Cloud API 吞吐量上限已达。这是速率问题，而不是数量问题：相同消息放慢发送速度后仍可通过。对于 Coexistence 号码，上限由 Meta 固定。 ### 实际受限的是什么？ 受限的是消息发出的速率，而不是您一天可以发送的消息数量。 平台会为一个号码接受每秒一定数量的消息，超过该数量的请求会被拒绝，而不是排队。因此，一次发送一万条消息本身并不是问题，问题在于同一秒内全部发送。把相同批次分散到几分钟内发送，就可以完整通过。 这与消息层级不同。消息层级决定您一天可以主动开始联系多少位不重复的客户；质量限制则会限制收件人反应不佳的号码。这是 3 个不同的上限，对应 3 个不同的代码，却经常互相混淆。 ### 可以提高这个上限吗？ 对于 Coexistence 号码，不可以。Meta 会以固定速率设定上限，任何提供商都无法提高。设计系统时，您应先了解这一点，不要以为可以围绕更高的数字来规划。 对于以普通方式接入的号码，吞吐量会随着质量评分和消息层级逐步提高。这是 Coexistence 少数真正的取舍之一，也正是为什么需要大量发送的号码通常更适合在不使用 Coexistence 的情况下接入。 对于对话式使用，这个上限很少成为限制。只有当某个流程遍历列表，并以代码允许的最快速度发送时，问题才会出现。单从系统设计角度看，这种模式就值得避免。 ### 发送方应该改做什么？ 控制发送速率，并使用退避机制重试，不要立即重试。 采用固定速率的队列是持久可靠的做法，因为它会让限制成为系统属性，而不是上线后才发现的问题。如果这套方案过于复杂，仅针对该代码使用指数退避，也能取得大部分效果。 紧密重试不会奏效。被拒绝后立即重试的循环，会在号码已经超过速率上限的时刻产生更多请求，从而延长问题，而不是消除问题。 - 立即重试。被拒绝时产生更多请求，会让号码继续超过速率上限。 - 把它与消息层级混淆。消息层级管理每日不重复的对话数量，而不是每秒消息数。 - 按会扩展的吞吐量来设计 Coexistence 号码。吞吐量不会扩展，上限是固定的。 **这是否表示我的号码受到限制？** 不是。这是普通的速率限制。号码状态正常，相同消息放慢发送速度后即可成功。 **Coexistence 号码可以发送多快？** Meta 会为 Coexistence 号码设定固定速率，不会根据质量和消息层级扩展。 **80007 是同一种错误吗？** 不是。80007 是 WhatsApp Business Account 的速率限制，不是号码消息吞吐量的限制。 **换一个提供商会发送得更快吗？** 不会。限制属于该号码和 Meta，与调用 API 的提供商无关。 --- ## 通过官方 Cloud API 将 WhatsApp 连接到 Make https://easycoexistence.com/zh-hans/integrations/make 将号码的 Webhook 目的地指向 Make 自定义 Webhook，每条传入消息均启动一个场景。回复通过 Cloud API 和 HTTP 模块返回。Make 不能使用我们的 MCP 服务器，因为 Make 本身是 MCP 服务器，而不是客户端。 ### WhatsApp 消息如何启动 Make 场景？ 在 Make 中创建自定义 Webhook 模块，复制它提供的 URL，再将其指定为号码的 Webhook 目的地。从此以后，Meta 会将发送到该号码的每条消息直接作为 HTTP POST 交付到该 URL，然后场景运行。 消息负载包含发送者、消息正文或媒体引用、时间戳和消息 ID。接下来就是普通场景：根据内容路由、查找客户，再调用您运行的其他服务。 由于属于 Coexistence，同一消息也会出现在手机上的 WhatsApp Business 应用中。人员可以回复，场景能看到人工发送的内容，双方也不互相覆盖回复。 ### 为什么 Make 不能使用 MCP 连接器？ 因为 Make 是 MCP 服务器，不是 MCP 客户端。它向 Claude 和 ChatGPT 等助手公开自己的场景，由助手向内连接 Make。它不向外连接其他人的 MCP 服务器。 方向决定了一切。我们的连接器是等待被调用的服务器，而 Make 没有向外调用服务器的机制，所以两者不会连接。n8n 是不同的产品，提供 MCP Client Tool 节点，可以通过 OAuth 使用远程服务器。 实际无需额外付费。Webhook 路径已涵盖场景所需的一切，而且它能响应传入消息，MCP 在任何工具中都无法完成这一点。 ### 场景如何发送回复？ 通过 HTTP 模块调用 Cloud API，使用号码的号码 ID 和访问令牌。两者都可从控制台读取；如果您希望助手代您获取，也可通过 MCP 连接器读取。 发送内容取决于时间窗口。客户最后一次发来消息后的 24 小时内，可以使用自由文本。超过这个窗口后，只有 Meta 已批准的模板才能送达。只发送自由文本的场景，首次遇到跨夜情况就会停止送达。 可靠的结构是使用路由器：检查最后一条传入消息到达了多久，再选择自由文本分支或模板分支。 - 将 Webhook 留在一个已关闭场景的 Make URL 上。Meta 仍会向它交付消息，但不会运行任何内容。 - 没有回答 Meta 的验证请求。交付任何消息前，Meta 会发送带 challenge 的 GET。 - 在 24 小时窗口外回复自由文本。请求会失败，从场景角度看起来像什么都没有发生。 **Make 能连接您的 MCP 服务器吗？** 不能。Make 是 MCP 服务器而不是客户端，因此无法向外调用我们的服务器。Webhook 路径已涵盖场景所需的一切。 **我需要 WhatsApp 的 Make 应用吗？** 不需要。自定义 Webhook 负责接收，HTTP 模块负责发送。整个集成就是一个 URL 和一次 REST 调用。 **团队仍能从手机回复吗？** 可以。这就是 Coexistence 的含义。应用继续使用同一号码，场景也能看到人工发送的内容。 **一个场景能服务多个客户吗？** 可以。将每个号码都指向同一个 Webhook，再根据负载中的接收号码 ID 进行路由。 --- ## 在官方 Cloud API 上将 WhatsApp 连接到 Zapier https://easycoexistence.com/zh-hans/integrations/zapier 将号码的 Webhook 目的地指向 Zapier 的 catch hook，每条传入消息都会触发一个 Zap。回复通过 Cloud API 和 Webhook 动作发回。Zapier 无法使用我们的 MCP 服务器，因为 Zapier 是 MCP 服务器，而不是客户端。 ### 传入消息如何触发 Zap？ 使用 Webhooks by Zapier trigger 创建一个 Zap，选择 Catch Hook，然后复制 Zapier 生成的 URL。将该 URL 设为号码的 Webhook 目的地后，Meta 会直接把每条传入消息发送到该 URL。 负载会提供发送者、消息内容、时间戳和消息 ID，这些信息足够大多数 Zap 进行分支处理。无需在您的基础设施上运行任何内容，也无需维护 Zapier 应用，因为整个集成只需要一个 URL。 WhatsApp Business 应用会继续在同一个号码上运行，因此，Zap 未处理的对话仍可由人员接手。 ### 为什么 Zapier 不使用 MCP 连接器？ 因为 Zapier 运行的是 MCP 服务器，而不是 MCP 客户端。Claude 和 ChatGPT 等助手会连接到 Zapier，以使用其中的操作。Zapier 不会向第三方 MCP 服务器发起连接，因此无法访问我们的服务器。 实际影响为零。MCP 用于在人提出请求时让助手执行操作，而 Zap 的模式正好相反：某件事发生后，自动化流程作出响应。这在所有工具中都属于 Webhook 范畴，包括那些确实拥有 MCP 客户端的工具。 如果您也想让助手参与流程，可以在 Claude 或 ChatGPT 中将连接器与 Zap 搭配使用，而不是放在 Zap 内部。 ### Zap 如何发送回复？ 使用 Webhooks by Zapier POST action 调用 Cloud API，并使用控制台中的号码 `phone_number_id` 和访问令牌。 发送时机决定您可以发送的内容。在客户最后一条消息后的 24 小时内，可以发送自由文本。超过 24 小时后，只能发送已批准的消息模板。多数 Zap 在生产环境中出问题，原因就在这里，因为测试总是在消息发出几秒后进行。 同时处理两种情况的 Zap，需要根据最后一条传入消息到达的时间设置路径过滤器。只需多加一个步骤，就能让自动化流程不仅在周二下午正常运行，也能在凌晨 3 点正常运行。 - 将 Zapier 测试 URL 用作目的地。它会停止监听，消息也会发送到无处。 - 忘记 Meta 的验证 GET。Catch Hook 必须先返回 challenge，之后才会开始传送消息。 - 在 24 小时窗口之外发送自由文本，从 Zap 的角度看会静默失败。 **有官方的 WhatsApp Zapier 应用吗？** 这里不需要。Catch Hook 负责接收，Webhook action 负责发送，您可以通过官方 Cloud API 完成连接，无需中间服务。 **Zapier 可以使用您的 MCP 服务器吗？** 不可以。Zapier 本身是 MCP 服务器，不充当客户端，因此无法向我们的服务器发起调用。 **我的团队会失去手机上的使用权吗？** 不会。Coexistence 会让 WhatsApp Business 应用继续在同一个号码上运行。 **如果我的 Zap 暂停了怎么办？** Meta 会重试一段时间，之后停止。消息仍会到达手机上的应用，因此业务不会漏掉消息。 --- ## 使用自定义连接器将 WhatsApp 接入 ChatGPT https://easycoexistence.com/zh-hans/integrations/chatgpt 在 ChatGPT 设置中开启开发者模式，添加 EasyCoexistence 连接器。之后，ChatGPT 可列出您的号码、检查连接状态、发送消息和模板，并将 Webhook 指向您自己的系统，全部通过 Meta 的官方 Cloud API 完成。 ### 如何将它添加到 ChatGPT？ 打开设置，进入连接器，再进入高级设置，然后开启开发者模式。这样，您就能通过 URL 添加连接器，而不是从内置列表中选择。 添加一个指向 EasyCoexistence MCP 端点的连接器。ChatGPT 第一次调用工具时会打开登录页面，您可在那里授权。连接器使用 OAuth，而不是 API 密钥，因此不会生成、复制或粘贴任何内容。 服务器本身在远程运行。无需安装任何东西，也不会在您的设备后台运行。关闭 ChatGPT 不会以任何方式影响已连接的号码。 ### 连接后，ChatGPT 可以做什么？ 用日常语言提问，ChatGPT 会选择相应工具。例如：我的哪个号码连接状态异常？把预订确认发给这位客户。创建一个用于订单更新的模板，并在 Meta 批准后告诉我。将这个号码的 Webhook 指向我的服务器。 读取工具可列出号码、检查质量评分、消息层级和连接状态，并在其他系统需要时提取凭据。发送工具可在会话窗口内发送自由文本，也可在窗口外发送已批准的模板。 16 个工具中的一个会以 Markdown 格式向 ChatGPT 提供我们的文档，因此它能根据我们的文档回答相关问题，而不是凭空猜测。 ### 它不能做什么？ 它不能自动回应收到的消息。这一点需要说清楚，因为很多人会以为助手应该这样做。 MCP 采用请求和响应模式。您要求时，ChatGPT 才会调用工具。没有任何机制能让客户的 WhatsApp 消息唤醒 ChatGPT，并让它在凌晨 3 点自行回复。我们的连接器不会改变这一点，任何产品中的 MCP 服务器都不会改变这一点。 自动回复需要使用 Webhook：Meta 将收到的消息交给您运行的系统，再由该系统决定如何处理。两者可以配合使用，连接器甚至可以替您设置 Webhook 目标。 - 期待它自动回复客户。MCP 只有在您提出请求时才会运行；收到的消息需要通过 Webhook 处理。 - 在内置连接器列表中寻找 EasyCoexistence。开启开发者模式后，需要通过 URL 添加它。 - 以为必须使用密钥。连接器通过 OAuth 授权，无需粘贴任何内容。 **需要付费 ChatGPT 方案吗？** 自定义连接器位于设置中的开发者模式后面。是否可用取决于 OpenAI 自身的方案规则，不由我们控制。 **ChatGPT 会看到我的客户对话吗？** 只有您要求获取的内容。收到的消息会从 Meta 发送到您指定的 Webhook 目标，我们绝不会储存对话内容。 **可以连接新号码吗？** 它可以启动流程。连接器会返回一个链接，由企业所有者打开，并通过 Meta 的流程授权自己的号码。 **它能与 Claude 使用同一个账户吗？** 可以。一个 EasyCoexistence 账户、一个端点，您连接的每个助手都能看到相同的号码。 --- ## 通过 MCP 将 WhatsApp 连接到 Cursor https://easycoexistence.com/zh-hans/integrations/cursor 将 EasyCoexistence 添加到 Cursor 的 MCP 配置后，您无需离开项目，编辑器即可连接真实 WhatsApp 号码：列出号码、检查连接状态、发送消息和已批准的消息模板，并将 Webhook 目的地指向您正在构建的内容，全部通过 Meta 的官方 Cloud API 完成。 ### 如何将它添加到 Cursor？ 打开 Settings，找到 MCP 部分，然后添加一个指向 EasyCoexistence 端点的服务器。Cursor 也会读取 mcp.json 文件。如果您要设置多台机器，或希望将配置纳入版本控制，这是更合适的方式。 重新加载后，让 Cursor 列出您的号码。首次使用时，Cursor 会完成登录，此后即可使用这些工具。无需安装软件包，也无需生成密钥。 服务器是远程的，因此编辑器旁边不会运行任何内容。关闭 Cursor 也不会影响已连接的号码。 ### 为什么要在编辑器中使用 WhatsApp？ 因为您通常正在构建的就是这个集成，而没有它，反馈循环会很慢。 配置 Webhook、检查是否已验证、向自己发送测试消息、读取消息模板的审核状态：每一步都需要切换到控制台，再切回来。有了这个连接器，您可以直接在代码所在的位置提出这些请求。 在处理客户项目时，这也是设置客户号码最快的方式。get_connect_link 会返回客户打开的链接，而 set_webhook_destination 会将号码指向您正在构建的内容，无需任何人打开 Meta 弹出窗口之外的浏览器标签页。 - 以为它会接收消息。MCP 会在您提出请求时执行；传入流量需要 Webhook 目的地。 - 把访问令牌放进配置中。连接器使用 OAuth，文件中不需要任何密钥。 - 向一天内没有发过消息的联系人发送自由文本。超过 24 小时后，只有已批准的消息模板可以送达。 **需要安装任何内容吗？** 不需要。这是一个通过 HTTP 和 OAuth 运行的远程服务器，Cursor 会连接到它，而不是在本地运行它。 **可以将配置保存在版本控制中吗？** 可以，通过 mcp.json 实现。文件中没有密钥，因为首次使用时会通过 OAuth 完成授权。 **Claude Code 也能使用吗？** 可以，只需一条命令。每个客户端使用相同的端点。 **可以向任何号码发送消息吗？** 它会从连接到账户的号码发送消息，发送给任何 WhatsApp 收件人，但须遵守通常的时间窗口和消息模板规则。 --- ## 通过 MCP 将 WhatsApp 连接到 Claude Code https://easycoexistence.com/zh-hans/integrations/claude-code 运行一条 claude mcp add 命令后，Claude Code 就能访问真实的 WhatsApp 号码：列出号码、检查连接状态、发送消息和模板，以及设置 Webhook 目的地。所有操作都基于 Meta 的官方 Cloud API，而不是已关联的设备会话。 ### 如何添加？ 在任意终端中，使用 http 传输方式和 EasyCoexistence 端点运行 claude mcp add。然后在 Claude Code 中运行 /mcp 并完成身份验证。之后，这 16 个工具可在该机器的每个会话中使用。 除了配置项外，不会安装任何内容。服务器在远端运行，因此无需保持进程运行，也不会在磁盘上的任何位置保留会话。 授权采用 OAuth，因此访问令牌不会出现在 shell 历史记录、点文件或代码库中。这一点在这里比桌面应用更重要，因为终端配置很容易被意外提交到代码库。 ### 它实际有什么用？ 它适合同时处理 WhatsApp 和代码库的代理任务，这正是我们付费用户大多在做的事情。 代理可以使用 get_connect_link 为客户接入号码，使用 set_webhook_destination 将号码指向正在构建的服务，然后发送测试消息，并读取 Webhook 是否已验证。否则，这个流程通常需要打开控制台、使用手机，还要等待很长时间。 文档也通过它提供给模型。get_docs 会以 markdown 返回我们的产品文档，因此代理回答有关 Coexistence 规则、24 小时窗口或 14 天条件的问题时，可以依据我们的文档，而不是凭记忆作答。 - 以为收到的消息会直接到达代理。MCP 采用请求和响应模式，消息传送需要 Webhook。 - 每个项目都添加一次。它按机器配置，之后的每个会话都可使用。 - 在脚本中于窗口外发送自由文本。请先检查最近一次入站时间，再决定是否改用模板。 **Codex 也能使用吗？** 任何通过 HTTP 和 OAuth 支持 MCP 的产品都可以使用同一个端点。 **访问令牌会存储在磁盘上吗？** 不会。授权采用 OAuth，因此配置文件中不会保存秘密信息。 **代理可以自行连接号码吗？** 代理可以启动流程，但它返回的链接必须由企业所有者打开，因为 Meta 的流程需要浏览器和手机。 **关闭终端会断开连接吗？** 不会。服务器在远端运行，无论本地运行什么，号码都会保持连接。 --- ## WhatsApp Webhook：将消息直接路由到您的服务器 https://easycoexistence.com/zh-hans/whatsapp-webhook WhatsApp Webhook 是您指定的 HTTPS 端点，Meta 会向它发布事件：收到的消息、送达状态、质量变化和账户更新。在 Coexistence 号码上，目标可以设为您自己的服务器，因此对话完全不会经过任何服务商。 ### 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 请求的身份验证之后。 **我的消息会经过 EasyCoexistence 吗？** 不会。覆盖项会将消息路径事件从 Meta 直接发送到您的端点。未设置覆盖项的账户会回退到我们的 callback，事件会被丢弃而不保存。 **之后可以更改目标吗？** 可以，随时都能从控制台或通过 MCP connector 更改。传入 null 会将目标重置为我们的默认目标。 **Meta 发送事件时，如果我的服务器宕机会怎样？** Meta 会重试一段时间，然后停止。消息仍会到达手机上的 WhatsApp Business 应用，因此即使集成中断，业务也不会丢失消息。 **多个号码共用一个 Webhook 可以吗？** 可以。将每个号码都指向同一个端点，再根据负载中的接收 phone number id 分支处理。 --- ## 用 Python 收发 WhatsApp https://easycoexistence.com/zh-hans/integrations/python 接收消息，是 Web 框架中的一条路由，用来响应 Meta 的验证 GET 并接受 POST 请求。发送消息，是向 Cloud API 发出的 HTTPS 请求，其中包含号码的 phone number id 和访问令牌。我们不提供 SDK，也无需安装任何东西。 ### 如何在 Python 中接收消息？ 在您已经使用的任意框架中，用同一路由配置两个处理程序。 GET 处理程序响应 Meta 的验证。它从查询字符串读取 hub.mode、hub.verify_token 和 hub.challenge，将令牌与您自己的令牌核对，然后把 challenge 作为原始正文返回。这里最常见的错误是返回 JSON，而且失败时不会明显提示。 POST 处理程序接收事件。请快速返回 200，然后再处理后续工作，因为 Meta 会把缓慢响应视为失败并重试，导致同一消息被处理两次。请将消息放入队列，或交给后台任务，不要直接在线处理。 消息会带有 wamid 消息 ID。从一开始就按它去重很值得，因为重试是正常情况，不是例外。 ### 如何发送消息？ 向 phone number id 对应的 Cloud API messages 端点发送一次 POST，并附上 Bearer 访问令牌。 这两个值都来自连接：控制台会显示它们；如果您希望由助手获取，get_api_credentials 也会返回它们。这个调用没有任何部分专属于我们，因此任何 HTTP 库都可以使用，请求格式也与 Meta 的官方文档完全一致。 随时间变化的是请求正文。在客户最后一条消息后的 24 小时内，您发送 text 对象。超过 24 小时，则发送 template 对象，并指定已批准的模板及其语言。只了解第一种格式的客户端，在测试中运行正常，却会在第一条隔夜消息时失败，并返回错误 131047。 ### 生产环境中的处理程序还需要什么？ 有 3 件容易跳过、日后却很难补上的事情。 按消息 ID 去重，因为 Meta 会重试。在 Webhook URL 中加入一个足够长的随机密钥，并拒绝不带该密钥的请求，否则任何知道这个可猜测 URL 的人都能向它发请求。签名标头在这里行不通：Meta 使用订阅所属应用的 app secret 进行签名，而这个应用是我们的，其 app secret 从不对外共享。还要根据联系人上次发消息的时间进行分支，让发送路径自动选择 text 或 template，无需人工决定。 这些都不需要框架或库。它们只是一次集合操作、一次检查和一次比较。在第一位客户接入前完成这些工作，才能让集成安静运行，而不是不断触发警报。 - 在验证 GET 中返回 JSON，而不是原始 challenge 值。 - 返回 200 前直接处理消息。Meta 会重试缓慢响应，导致您处理同一消息两次。 - 未检查时间窗口就发送自由文本。这会返回 131047，看起来像什么都没有发生。 **有 Python SDK 吗？** 我们不提供，但您不需要 SDK。API 属于 Meta，由 Meta 提供文档，任何 HTTP 库都可以访问。 **应该使用哪个框架？** 任何框架都可以。您只需要一条响应 GET 并接受 POST 的路由，所有 Python Web 框架都支持。 **如何避免同一消息被处理两次？** 按负载中的 wamid 消息 ID 去重。Meta 的设计就是会重试，因此这是预期情况，不是边缘案例。 **团队仍然可以使用手机吗？** 可以。Coexistence 会让 WhatsApp Business 应用继续在同一号码上运行，您的处理程序也会通过回声事件看到他们发送的内容。 --- ## 使用 Node.js 收发 WhatsApp 消息 https://easycoexistence.com/zh-hans/integrations/node 接收是一个响应 Meta 验证 GET 请求并接受 POST 请求的路由。发送是一次 fetch 调用，通过号码的 phone number id 和访问令牌向 Cloud API 发出请求。我们没有提供 SDK，也没有需要安装的东西。 ### 如何在 Node 中接收消息？ 在 Express、Fastify、Next 路由处理程序或普通服务器中，使用一个包含两种方法的路由。 GET 请求负责回应 Meta 的验证：从查询中读取 hub.mode、hub.verify_token 和 hub.challenge，将令牌与您的令牌比较，然后以纯文本返回 challenge。以 JSON 返回是最常见的错误，会产生一个看似正确却永远收不到任何内容的端点。 POST 请求接收事件。立即响应 200，之后再处理。Meta 会重试任何处理缓慢的请求，而在响应前完成工作的处理程序会看到同一条消息不止一次。尤其在无服务器环境中，先返回响应，再将工作放入队列，才能避免冷启动变成重复处理。 ### 如何发送消息？ 向该 phone number id 对应的 Cloud API messages 端点发出 fetch 请求，并在 bearer 标头中携带访问令牌。 这部分没有任何内容是我们专有的，因此请求与 Meta 自己的文档完全一致，不需要学习或受制于任何包装层。两个值都在控制台中；如果由助手完成接入，MCP 连接器的 get_api_credentials 会返回它们。 请求正文取决于时间。在客户最后一条入站消息后的 24 小时内，发送 text 对象。超过该时间后，发送包含已批准模板名称和语言的 template 对象。只会发送文本的代码可以通过所有测试，却会在第一条夜间到达的消息上失败。 ### 无服务器环境有什么不同？ 有两点，而且都与函数在工作完成前结束有关。 响应 200 后继续处理，无法在函数一响应就冻结的平台上正常运行。请使用平台提供的机制让响应后仍能继续工作，或将负载推入队列，再由另一个函数处理。Meta 只需要快速收到确认，不需要工作已经完成。 冷启动也会让响应变慢，从而导致更多重试和重复消息。在这种架构中，按 wamid 消息 id 去重不是可选项，而是保证可靠性的关键。 - 将 challenge 以 JSON 返回，而不是作为原始正文返回。 - 在响应 200 前处理工作。无服务器环境中，函数可能在响应的瞬间冻结。 - 跳过去重。Meta 的设计就是会重试，重复消息很常见，不是边缘情况。 **我需要使用库吗？** 不需要。一个路由和 fetch 就足够，而且调用与 Meta 的文档完全一致。 **这能在 Vercel 或 Lambda 上运行吗？** 可以，但要注意常见的无服务器限制：先确认收到请求，再通过队列或后台机制处理，而不是在请求内联处理。 **如何验证请求确实来自 Meta？** 在 Webhook URL 中加入一个足够长的随机密钥，并拒绝任何不带该密钥的请求。Meta 使用订阅所属应用的 app secret 进行签名，而这个应用是我们的，其 app secret 从不对外共享，因此您无法在自己这一端检查签名标头。 **我可以使用 TypeScript 吗？** 可以。我们没有需要您进行类型定义的内容，因为负载属于 Meta，且由 Meta 提供文档说明。 --- ## EasyCoexistence 与 BSP 收件箱比较 https://easycoexistence.com/zh-hans/compare/coexistence-vs-bsp BSP 销售的是一个平台：团队使用共享收件箱，消息存储在他们的服务器上。Coexistence 保留手机上的 WhatsApp Business 应用，并将消息转到您指定的地方。选择取决于您需要一个用来工作的产品，还是一个可以在其上构建系统的连接。 ### BSP 实际上提供什么？ 一个产品，而这不是批评。 Business Solution Provider 通常销售共享收件箱：客服人员登录，系统分配对话，提供预设回复、标签、报告和移动应用。对于一支 8 人支持团队来说，如果他们需要分配工作并查看每条消息由谁回复，这确实是合适的选择，而自行构建这些功能反而不明智。 架构上的结果是，消息会经过并存储在他们的平台上，因为共享收件箱不可能脱离消息历史而存在。它需要这些历史来显示内容。这是产品本身固有的设计，而不是某个供应商单独作出的选择。 ### 什么时候 Coexistence 更适合？ 当这个号码属于一家已经有固定工作方式的企业，而且没人想改变它时。 一支通过一部手机回复消息的小团队，不需要分配对话。他们需要找回晚上的时间，也就是让某些自动化流程处理确认消息和首次回复，同时让手机继续完全按原来的方式工作。把他们转进收件箱，只会解决一个他们没有的问题，并制造一个他们从未要求的问题。 代理机构的情况类似，但原因不同。客户不会迁移号码，也不会重新培训员工，而且通常完全不能接受把对话放在第三方平台上。Coexistence 是唯一不要求客户作出这些改变的官方途径。 ### 如果您正在构建软件，应该选择哪一个？ 几乎总是 Coexistence，原因在于架构，而不是功能多少。 如果您正在构建处理对话的系统，BSP 收件箱就是您正在构建的产品的竞争者，也是您与 Meta 之间的一层。您最终需要针对他们的抽象层进行集成，而不是直接使用 Cloud API，这意味着除了 Meta 的限制外，还要面对他们的速率限制、Webhook 形式、发布安排和定价。 使用 Coexistence 时，Webhook 会发送到您的端点，API 请求使用 Meta 自己的接口，并由 Meta 提供文档。集成不依赖任何供应商，这也让您可以随时离开。 - 按价格作选择。这是两种不同的产品，较便宜的一个并不是另一个的简化版本。 - 让一支 8 人支持团队使用没有任何系统支持的原始连接。他们需要收件箱，否则会感到不满。 - 以为 BSP 一定能让 WhatsApp Business 应用继续运行。有些 BSP 可以通过 Coexistence 实现，很多则不行，值得直接询问。 **我可以同时使用两者吗？** 实际上可以，前提是 BSP 支持 Coexistence。您应该询问对方消息内容存储在哪里，因为这才是真正的区别。 **BSP 更可靠吗？** 两者都运行在 Meta 的 Cloud API 上，因此消息送达情况相同。不同之处在于 Meta 与您的系统之间有多少参与方。 **哪一个更便宜？** 通常，固定连接费用低于按席位收取的收件箱费用，但这是两种不同的购买，单看数字进行比较会产生误导。 **如果我离开，历史记录会怎样？** 使用 Coexistence 时，历史记录从未由我们持有。使用平台时，记录存放在那里，取出它需要导出。 --- ## EasyCoexistence 与自行构建 https://easycoexistence.com/zh-hans/compare/build-it-yourself-vs-easycoexistence 本产品发出的每个 API 请求都有 Meta 文档，任何拥有 Meta 应用的人都能使用。构建连接只需一个周末。更耗时的是成为 Tech Provider，而永远不会结束的是发现连接何时悄然失效。 ### 您实际需要构建什么？ 第一版所需的工作比想象中少，而要构建一个经得起运行的版本，工作则比想象中多。 第一版包括一个 Meta 应用、Embedded Signup、一个响应验证握手的端点，以及一次发送请求。对于熟悉 OAuth 和 Webhook 的人来说，这确实只需一个周末，我们自己的文档页面也说明了其中大部分内容。 经得起运行的版本则不同。它会按名称处理 8 种 Webhook 事件类型，区分已撤销的访问令牌和已移除的号码；由于质量评分和消息层级都不会以可依赖的事件形式到达，因此还要定期查询；重新连接卸载 Webhook 覆盖设置后重新应用；并区分 14 天不活跃导致的断开与客户真正离开。每一项都是从实际故障中学到的。 ### 哪一部分无法走捷径？ 成为您自己的 Meta Tech Provider。这是连接一个号码与连接其他人号码之间的区别。 这项资质免费，但申请并不快。您需要经过验证的 Business Manager、通过 App Review 的应用，以及展示操作流程的录制视频。在完成之前，您只能通过别人的 provider 账户工作，这正是现成工具会出现单个连接限制的原因。 如果您只连接自己拥有的一个号码，这些要求都不适用，直接构建即可。如果您要为客户连接号码，这才是真正的项目，等待时间按数周计算，而不是按工作日计算。 ### 监控实际运行起来要付出什么？ 这是唯一没有完成日期的部分，因此与其他工作不同。 连接可能会静默失效。WhatsApp Business 应用在质量下降、访问令牌过期、Webhook 覆盖设置被移除以及 14 天断开期间仍会继续运行，因此手机上没有任何迹象表明出了问题，通常要等客户询问为什么没人回复，您才会收到第一个信号。 要发现这些问题，您需要定时查询程序、Webhook 接收器、储存状态的地方、警报，以及负责查看警报的人。这些都不难，但都必须持续运行；随着 Meta 改变相关机制，它们也必须持续保持正确，而 Meta 确实会这样做。这里真正购买的，是这些持续工作，而不是 API 请求本身。 - 根据第一版估算工作量。连接一个号码只需一个周末，但保持 50 个号码持续连接并不是这样。 - 计划在期限内成为 Tech Provider。App Review 的等待时间不由您控制。 - 把监控留到后期。它要捕捉的故障不会发出明显信号，因此没有发现故障，不代表故障没有发生。 **这里有任何专有技术吗？** 没有。每个请求都是 Meta 有文档说明的 Cloud API。这是有意设计的：您不会被锁定，也可以带着自己的集成完整离开。 **如果我只有一个号码，应该自己构建吗？** 大概应该。自己拥有的一个号码只连接一次，这是一个小项目，也能让您真正了解这个平台。 **取得 Tech Provider 资质需要多久？** 这项资质免费，但需要经过验证的 Business Manager 和 App Review，包括录制视频。等待是最耗时的部分。 **自己构建会失去什么？** 没有技术功能会失去。您需要自行承担监控，而监控永远不会结束，故障也可能悄然发生。 --- ## WhatsApp 错误 368：账户受政策限制 https://easycoexistence.com/zh-hans/docs/whatsapp-error-368 错误 368 表示 Meta 执行政策后限制了 WhatsApp Business 账户。这是账户层面的决定，不是请求问题，申诉应通过 Meta 进行，而不是通过服务商进行。 ### 限制实际意味着什么？ 这表示 Meta 已对企业账户采取执行措施，通常是多次违反政策后的结果，而不是单一事件导致的。 常见原因包括违反 WhatsApp 商务或企业政策的消息内容、收件人反复举报消息，或无法通过核实的企业验证资料。它们的共同点是涉及账户，而不是某一条消息，因此每次发送都会失败，而不是只有部分发送失败。 这需要和质量限制区分开来。质量限制会限制状态正常的账户可以发送多少消息。限制则是在判断账户是否应继续运行，并不会因为少发消息而解除。 ### 如何解决？ 应通过 Meta，在 Business Manager 中处理，而且只有账户所有者可以处理。 Business Manager 中的执行通知会说明涉及哪项政策，以及是否可以申诉。申诉确实存在，有时也能成功，但没有人能承诺处理时限，也没有通过服务商运行的升级途径。任何销售 API 访问权限的人，都无法查看执行决定或影响该决定。 这是少数任何供应商都应诚实说明无法帮助您的情况之一：他们无法处理您最希望解决的事情。他们能告知您哪个账户受到限制，以及限制何时发生，这正是连接时间线的用途。 - 要求服务商解除限制。执行决定属于 Meta，其他人都无法查看。 - 把号码连接到其他地方。限制针对的是企业账户，会随账户一起存在。 - 把它和质量限制混淆。质量限制针对状态正常的账户限制发送量，而不是限制账户本身。 **我可以把号码转到其他服务商吗？** 不可以。限制针对 WhatsApp Business 账户，因此无论在哪里使用该号码，限制都会生效。 **申诉需要多长时间？** Meta 没有公布时限，任何服务商也无法查看处理进度。 **这会影响接收消息吗？** 执行措施因个案而异。可以确定的是，发送消息会停止工作。 **131031 也是同一种错误吗？** 有关联。该代码表示限制同时伴随验证资料不匹配，问题指向企业资料，而不是消息行为。 --- ## WhatsApp 错误 131031：账户受限或资料不匹配 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131031 错误代码 131031 表示 WhatsApp Business 账户受限，通常是因为业务验证资料与 Meta 保存的资料不匹配，或涉及两步验证 PIN。问题需要在 Business Manager 中解决，而不是修改代码。 ### 哪类不匹配会导致这个错误？ Meta 保存的业务资料与您提交的资料不同。看似只是小差异，实际并非如此。 业务验证会将法律实体与账户关联起来，包括名称、地址、注册资料和证明文件。如果业务资料发生变化却没有在 Meta 更新，或提交的内容与 Meta 查验的注册记录不一致，账户可能会受限，直到资料完成核对。 另一个常见原因是两步验证 PIN，处理起来比较简单。PIN 设置在号码上，某些操作需要使用它。如果您忘记了 PIN，或是由已经离职的人设置，就需要先重置，其他操作才会恢复。 ### 实际应该在哪里查看？ 在 Business Manager 中查看业务账户，而不是查看号码。 验证状态和任何政策执行通知都在那里显示，通常可以据此判断是哪一种原因。提供商的控制台可以告诉您号码何时停止工作，但看不到验证记录，因此无法指出哪项资料有误。 如果原因是验证资料，请更新业务资料并重新提交。如果原因是 PIN，请在该号码的 WhatsApp Manager 设置中重置，并将新 PIN 记录在业务人员之后可以找到的位置。 - 把它当成代码故障。请求格式正确，但账户被拒绝了。 - 使用相同的资料重新提交验证，而这些资料之前已经被拒绝。 - 以为 PIN 由提供商保存。PIN 是在 Meta 自己的设置中为号码设定的。 **这是和 368 相同的问题吗？** 有关联，但并不相同。368 表示政策执行；这个错误通常指向业务验证资料或两步 PIN。 **提供商能看到我的验证状态吗？** 不能。验证状态位于 Business Manager 的业务账户中，不会向提供商开放。 **重新连接会有帮助吗？** 不会。限制针对的是账户，因此新连接仍会遇到相同条件。 **如何重置两步 PIN？** 在 WhatsApp Manager 中，进入该号码的设置。请将 PIN 记录在业务人员之后可以找回的位置。 --- ## WhatsApp 错误 132015：消息模板因质量问题暂停 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132015 错误 132015 表示此消息模板已被 Meta 暂停，因为其质量下降，通常是收件人屏蔽或举报了使用该模板的消息。号码没有问题。只有这个消息模板暂时无法发送。 ### 为什么单个消息模板会被暂停？ 因为质量会按消息模板和号码分别衡量，质量不佳的模板可以单独隔离，不会影响其他内容。 Meta 会观察收件人对每个消息模板所发送消息的反应，包括屏蔽、举报，以及收件人是否有任何互动。如果某个消息模板持续引发不良反应，就会被暂停，而同一号码上的其他模板仍可继续使用。这是一种有针对性的处理方式，作用比表面上更大，因为它能准确告诉您哪个消息存在问题。 常见原因包括在实用型模板中加入推广内容、没有清楚说明是哪个商家发送消息，或向没有预期会收到消息的人发送模板。 ### 暂停的消息模板应该怎么处理？ 请编辑消息模板，而不是再次发送，并把暂停视为内容问题的提示。 消息模板在一段时间后可以恢复发送，但如果向同类受众发送相同内容，通常会得到相同反应，并再次暂停。Meta 在多次暂停后会永久停用该模板。届时，唯一的做法是用不同内容创建新模板，因此第二次暂停就值得避免。 编辑通常包括在第一行明确说明用途，写出商家名称，并如实说明收件人为何会收到这条消息。同时也要检查发送对象，因为即使是优质模板，发送给没有兴趣的名单仍会产生相同信号。 - 暂停解除后重新发送相同的消息模板。导致暂停的是内容。 - 把它理解为号码出现问题。同一号码上的其他模板仍可继续使用。 - 等到第三次暂停。反复暂停会永久停用消息模板。 **其他消息模板还能发送吗？** 可以。暂停只适用于这个消息模板，号码上其他已批准的模板不受影响。 **暂停会持续多久？** Meta 没有公布固定时长，而且反复暂停后，持续时间会延长。 **我可以编辑暂停的消息模板吗？** 可以，编辑正是处理重点。重新提交改进后的内容，模板才有机会恢复。 **什么是 132016？** 这是永久停用版本。模板反复暂停后会被停用，必须用新模板替换。 --- ## WhatsApp 错误 100：参数无效 https://easycoexistence.com/zh-hans/docs/whatsapp-error-100 错误 100 表示请求携带了 Meta 不接受的参数：不受支持、拼写错误，或格式不符合该端点的要求。它是确定性的，因此同一请求每次都会以完全相同的方式失败，重试永远无效。 ### 是什么导致这个错误 请求正文或查询参数中有端点无法识别的内容，原因通常很明确。 - 字段名称拼写错误，或大小写不对。 - 参数属于另一个端点。 - 值的类型错误，例如端点要求整数，却以字符串发送数字。 - 嵌套对象被扁平化，或应为对象的位置却传入了扁平值。 ### 为什么重试没有意义 因为两次尝试之间，平台没有任何变化。格式错误的请求在第二次尝试时仍会因同样原因出错，围绕这个错误建立重试循环，只会在原有问题上增加速率限制，不会带来成功。 正确做法是将请求正文与错误一起记录，再逐字段对照端点参考文档。在几乎所有情况下，查看不到 1 分钟就能发现差异。 - 重试。请求具有确定性，每次都会以相同方式失败。 - 以为问题出在号码上。这个错误从不表示连接有问题。 - 把它当作通用失败。它明确指向参数问题，缺少参数和数值超出范围分别有更具体的错误代码 131008 和 131009。 **这是否表示我的号码坏了？** 不是。这个错误只涉及请求，号码不受影响。 **为什么错误信息这么模糊？** 它是涵盖参数问题的通用错误。Meta 针对缺少参数和无效值分别提供了更具体的错误代码。 **服务提供商会导致这个错误吗？** 只有在服务提供商构建请求时才会。直接集成时，请求由您负责。 **我应该使用退避策略重试吗？** 不应该。它是确定性错误，重试只会让非临时问题额外触发速率限制。 --- ## WhatsApp 错误 131008：缺少必需参数 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131008 错误 131008 表示请求缺少必需参数。它比错误 100 更具体，也更有用。错误 100 通常涵盖格式错误的参数，而 131008 明确指出字段缺失，而不是字段值错误。 ### 通常缺少什么 有些字段看似可选，实际上并非如此，所以总是反复出现同几项。 - messaging_product，每次发送都必须设为 whatsapp。 - 需要该字段的消息结构中的 recipient_type。 - 使用模板发送时的语言对象，即使只有一种语言也必须提供。 - 定义了变量的模板中的 components，此时空列表与省略字段并不相同。 ### 为什么这是好消息 因为这是这一类错误中最具体的一种。错误 100 只告诉您某处的参数有问题，而 131008 明确告诉您必需参数完全不存在，因此您只需检查端点的必需字段列表。 修复方法是阅读所调用端点的参考文档，并将请求与其必需字段集合逐一核对。这只需几分钟，也正是为什么日志中值得将此错误与 100 区分，而不是都归为错误请求。 - 将它与错误 100 视为相同。这个错误指出的是缺失，因此更具体。 - 把空的 components 数组当作省略字段发送。对 API 来说，两者不同。 - 省略 messaging_product。每次发送都必须提供它，这是最常见的单一原因。 **缺少哪个参数？** 响应中会列出该参数。若响应未列出，端点参考文档会提供必需字段集合。 **messaging_product 真的必需吗？** 是的，每次发送都必须设为 whatsapp。这是最常见的遗漏字段。 **这和 100 相同吗？** 不相同。100 针对已存在但错误的参数，而 131008 针对缺失的参数。 **重试有帮助吗？** 没有。请求是确定性的，在添加字段前，每次都会以相同方式失败。 --- ## WhatsApp 错误 131009：参数值无效 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131009 错误 131009 表示一个或多个参数值无效：字段存在且可识别，但其中的内容不被端点接受。大多数情况涉及语言代码、号码格式和枚举值。 ### 最常出错的值 有 3 种格式占大多数，而且从阅读者角度看都像是正确的。 - 语言代码：消息模板创建时使用的是 en_US，却传入 en；或创建时使用的是 pt_BR，却传入 pt。 - 号码带有标点、开头的 0 或加号，但端点要求的是国际格式的纯数字。 - 枚举值的大小写错误，例如消息模板类别使用了小写。 - 日期或时间戳使用了端点文档未说明的格式。 ### 为什么要特别注意语言代码 因为不同端点会返回不同的错误，导致人们追查错误方向。 发送不存在该名称对应语言的消息模板时，会返回 132001，看起来像是消息模板缺失。向先验证语言代码的端点提供格式错误的语言代码时，则会返回此错误。两者本质上是同一个错误，修复方法也相同：读取消息模板列表，复制准确的语言字符串，不要凭格式猜测。 - 以为 en 和 en_US 可以互换。它们对应不同的消息模板。 - 发送带加号或标点的号码。应使用国际格式，且只含数字。 - 重试。这个值确定是错误的。 **哪个值不正确？** 响应通常会指出参数。若没有，请先检查语言代码和号码格式。 **号码应如何设置格式？** 使用国际格式，仅含数字，不加加号或标点。 **为什么同一个错误有时会返回 132001？** 因为发送消息模板时会同时匹配名称和语言，未知组合会被视为缺少消息模板。 **这是我的号码有问题吗？** 不是。这个错误只涉及请求。 --- ## WhatsApp 错误 131051：不支持的消息类型 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131051 错误 131051 表示发送的消息类型不受支持。有时是类型值格式错误，但对于 Coexistence 号码，更常见的情况是该类型不属于平台允许在此类连接上使用的类型。 ### 两种不同原因 第一种是常见原因：类型值拼写错误，或该类型不在 API 定义范围内。查看端点参考即可在 1 分钟内解决。 第二种是结构性限制，容易让人误判，因为错误代码相同。Coexistence 号码无法执行普通 Cloud API 号码支持的所有操作，尝试其中一项时，就会返回这个错误，而不是更明确的提示。连接的号码会停用消失消息、一次性查看媒体、实时位置和广播列表，群聊则完全不属于 API 范围。 ### 如何判断属于哪一种 看您尝试发送的内容即可。 - API 定义了该类型，而且您之前发送过：这是格式错误，请比较负载。 - 任何发送到群聊的内容：这是结构性限制，任何服务商都无法启用。 - 实时位置、一次性查看媒体或消失消息：这是 Coexistence 号码上的结构性限制。 - 之前从未发送过的新类型：检查该类型是否适用于您的账户和所在地区。 - 围绕群聊构建功能。所有服务商的 API 都不支持群聊。 - 以为服务商可以启用已停用的类型。这些是平台限制。 - 反复重试。两种原因都不是暂时性问题。 **可以向群聊发送消息吗？** 不可以。对于 Coexistence 号码，群聊不属于 API 范围，所有服务商都一样。 **为什么不支持实时位置？** 启用 Coexistence 后，该号码会停用这项功能。 **可以修复吗？** 如果原因是类型格式错误，可以。如果是平台限制，不可以。 **会影响接收消息吗？** 不会。此错误只涉及发送不被允许的类型。 --- ## WhatsApp 错误 131052：媒体下载失败 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131052 错误 131052 表示 Meta 无法下载消息附带的媒体。问题在于媒体本身，而不是您的请求，因此实际做法是请对方通过其他方式发送，无需修改代码。 ### 为什么会发生 因为入站媒体需要单独获取，而不是随消息直接传送。消息会携带媒体 ID，系统再使用该 ID 单独获取媒体字节。 获取可能因发送方的问题而失败：上传未完成、文件在获取前已过期，或生成文件的过程导致格式无法正常使用。您无法从自己的端看到这些原因，修改请求也无法解决问题。 ### 该怎么做 把它视为一条收到但缺少附件的消息，并像处理其他不完整输入一样处理。 - 记录消息，并将媒体标记为不可用，不要丢弃整个事件。 - 及时获取媒体：ID 不会永久有效。 - 如果流程中有人参与，请客户重新发送，这通常可以解决大多数情况。 - 不要无限重试。如果首次获取和重试 1 次都失败，媒体就不会再来了。 - 丢弃整条消息。没有附件时，文本和上下文仍然有用。 - 收到消息很久后才获取媒体。ID 会过期。 - 循环重试。获取失败后，稍后很少会成功。 **消息丢失了吗？** 没有。消息已经到达，失败的是获取它的附件。 **我应该请客户重新发送吗？** 如果有人参与流程，可以。这样通常能快速解决大多数情况。 **媒体 ID 的有效期有多长？** 不是永久有效，所以及时获取很重要。 **131053 也是同样的问题吗？** 不是。那是您发送媒体时上传失败。 --- ## WhatsApp Cloud API 错误代码 https://easycoexistence.com/zh-hans/docs/whatsapp-error-codes 这里列出我们记录的所有 WhatsApp Cloud API 错误代码，并在一张表中说明每个代码的含义，以及重试是否有帮助。大多数情况下没有帮助：这些错误是确定性的，同一个请求会以同样方式失败，而重试循环只会让错误请求最终触发速率限制。 ### 如何阅读重试栏 它有 3 个值，选错值是整份参考资料中代价最高的错误。 否表示失败是确定性的。出问题的是请求、模板或收件人的状态，完全相同的请求会再次产生相同错误，同时消耗您之后会需要的吞吐量。是表示问题出在 Meta 一侧，退避重试确实可以解决。等待表示条件确实存在，但只是暂时的，例如会自行解除的限制或锁定。在解除前重试没有作用，还可能延长限制时间。 ### 为什么大多数代码都不适合重试 因为平台会返回具体代码，而不是笼统的错误。参数格式错误、不存在的模板、已关闭的消息窗口和已选择退出的收件人，都会在响应返回时确定，因此 Meta 会明确指出问题，而不是含糊地失败。 - 请求问题不会在第二次尝试时自动变正确。 - 模板问题存在于模板本身，请求无法改变它。 - 窗口或选择退出问题涉及收件人的状态，而不是您的状态。 - 账户限制是一项决定，重试不是申诉。 ### 收到这些代码时要记录什么 记录足够的信息，让您无需重现问题也能诊断。这就是 5 分钟修复和整天猜测之间的区别。 - 完整错误响应，包括 trace id，这是 Meta 支持团队要求的信息。 - 实际发送的请求正文，而不是您原本打算发送的内容。两者之间的差异通常就是错误所在。 - phone number id，这样可以区分单个号码的问题和整个账户的问题。 - 时间戳，这样可以对照该时刻的连接状态检查失败原因。 ### 只存在于 Coexistence 中的代码 有 2 个。它们看起来像普通的发送失败，因此容易让人困惑。2593107 和 2593108 都与聊天记录同步有关，也就是号码首次连接时，从 WhatsApp Business 应用复制近期对话的步骤。 它们不是消息错误，也不表示连接失败。如果同步超过限制或在窗口之外运行，号码仍会保持连接并正常发送，只是复制的历史记录少于预期。把它们看成连接中断，会导致有人断开连接后重新开始，这样只会丢失更多历史记录，而不是恢复记录。 - 默认重试。大多数代码是确定性的，循环重试还会额外触发速率限制。 - 只记录错误，不记录请求正文。实际发送内容与原本意图之间的差异通常就是错误所在。 - 把同步错误看成连接中断。号码仍然保持连接并正常发送。 - 丢弃 trace id。它是让支持工单能够获得处理的唯一关键信息。 **哪些错误应该重试？** 131016 和 131000，使用指数退避。130429、132015 和 133008 等待后会自行恢复。其他错误都是确定性的。 **错误代码是否表示我的号码已断开连接？** 通常不是。大多数代码涉及请求、模板或收件人。连接问题通常会以账户和质量 Webhook 的形式出现，而不是发送错误。 **什么是 trace id？** 它是错误响应中的标识符，让 Meta 支持团队能够找到具体请求。每次失败都应记录它，否则支持工单无法获得处理。 **这些代码在每个服务商那里都相同吗？** 是。它们来自 Meta 的 Cloud API，因此无论哪家服务商连接该号码，代码都相同。服务商只能影响这些错误能多清楚地传达给您。 --- ## WhatsApp 错误 131053：媒体上传失败 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131053 错误 131053 表示 Meta 无法上传您请求中的媒体。与相关的入站错误 131052 不同，这个错误涉及您控制的文件，因此可以修复：检查大小、格式，以及您发送链接时 Meta 是否确实能够访问该链接。 ### 3 个原因 按实际发生的顺序排列。 - 大小：文件超过其类型的上限。图片 5 MB，视频和音频 16 MB，文档 100 MB。 - 格式：API 不接受某种编码格式或容器格式，使用编辑软件导出的视频经常出现这种情况。 - 可访问性：发送链接而不是已上传的 id，而 URL 需要登录、位于防火墙后，或发生重定向。 - 过期：上传后很久才使用已上传的 media id。 ### 上传优于发送链接 发送链接时，Meta 会在发送时抓取文件，这增加了一种您无法从自己的网络看见的失败原因。一个在浏览器中正常加载的 URL，可能因为地理位置、防火墙规则，或浏览器已保存的身份验证 Cookie，而无法从 Meta 的基础设施访问。 先上传文件，再发送返回的 media id，可以完全排除这一类失败。这只多出一个请求，却能让发送结果更确定，对于批量发送的内容尤其值得。 - 以为浏览器中可用的 URL 对 Meta 也可用。您的会话和网络环境与 Meta 的不同。 - 导出视频时没有检查编码格式。编辑软件的默认设置经常不受支持。 - 上传后很久才重复使用 media id。media id 会过期。 **大小限制是多少？** 图片 5 MB，视频和音频 16 MB，文档 100 MB。 **应该上传文件还是发送 URL？** 上传文件。这样可以排除可访问性导致的失败。 **URL 对我有效，为什么对 Meta 无效？** Meta 的网络环境与您的不同。地理位置、防火墙和身份验证都可能不同。 **这与 131052 相同吗？** 不同。131052 表示下载客户发送给您的媒体失败。 --- ## WhatsApp 错误 131016：服务暂时不可用 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131016 错误 131016 表示 Meta 一侧的服务暂时不可用。这是少数真正具有暂时性的平​​台错误之一，因此正确做法是指数退避重试，而不是展开调查。 ### 为什么这个错误不同 此平台上的大多数错误都是确定性的：请求格式错误、消息模板不存在，或时间窗口已关闭。重试这些请求只会浪费一次请求额度，还可能触发速率限制。 这个错误例外。它并不说明您的请求或号码有问题，只表示 Meta 运行的服务暂时无法响应。同一个请求通常在一分钟后就会成功，这正是退避机制的用途。 ### 如何正确重试 请克制重试，因为大量并发重试会让服务中断恶化。 - 指数退避：等待 1 秒，然后 2 秒、4 秒，再到 8 秒。 - 设置尝试次数上限，通常为 5 次；之后将消息放入队列，稍后处理。 - 加入抖动，避免一批工作进程同时重试。 - 确保幂等性，避免消息在错误传到您之前已经发送成功，随后又被发送两次。 - 在紧密循环中立即重试。这会给已经承受压力的服务增加负载。 - 把它当成连接问题。您的号码没有问题。 - 不设上限地重试。有些中断持续时间长于任何重试策略应等待的时间。 **应该重试吗？** 是，但请使用指数退避。这是重试确实有效的错误之一。 **我的号码受到影响吗？** 不会。这是平台端故障。 **这类错误会持续多久？** 通常从几秒到几分钟。最多重试 5 次的退避策略足以覆盖大多数情况。 **如何判断它是否是真正的服务中断？** 看它是否持续存在。持续监控无需猜测即可回答这个问题。 --- ## WhatsApp 错误 131000：出现问题 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131000 错误 131000 表示消息因 Meta 未分类的原因发送失败。这是未分类错误，因此实际做法是先进行 1 次退避重试；如果问题持续，请附上响应中的 trace id 后提交支持工单。 ### 它实际涵盖什么 Meta 的发送流程在某个环节失败，但没有将失败对应到具体代码的情况。这包括真正的暂时性故障、内部问题，以及较新 API 版本中可能已有专属代码、但当时尚未对应代码的情况。 由于这个分类范围很广，没有一种响应方式适用于所有情况。偶发 1 次通常只是噪声。如果同一个收件人反复出现该错误，就值得提交工单。 ### 应该如何处理 按以下顺序处理，某一步成功后即可停止。 - 使用短暂退避重试 1 次。其中一部分错误属于暂时性故障。 - 记录完整响应，包括支持人员会要求提供的 trace id。 - 检查是 1 个收件人还是所有收件人都失败。只有 1 个收件人失败，可能与该号码有关；全部失败，则可能与平台有关。 - 如果多次重试后仍然持续，请提交工单，并附上 trace id 和时间戳。 - 无限重试。如果 2 次尝试都失败，通常就不是暂时性故障。 - 丢弃 trace id。它是让支持工单能够实际处理的唯一关键信息。 - 认定这表示您的号码已损坏。通常并不是这样。 **我应该重试吗？** 重试 1 次，并使用退避等待。超过 1 次后，通常就不是暂时性故障。 **什么是 trace id？** 它是错误响应中的标识符，可让 Meta 支持人员找到具体请求。 **这表示我的号码断开了吗？** 通常不是。请检查其他消息是否发送成功。 **什么时候应该提交工单？** 如果多次重试后仍然重复出现，请附上 trace id 和时间戳。 --- ## WhatsApp 错误 131021：发送方和接收方是同一号码 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131021 错误 131021 表示发送方和接收方是同一个号码。WhatsApp 不允许企业号码向自己发送消息，原因几乎总是测试消息发往了已连接号码，而不是另一个电话号码。 ### 为什么会发生 因为任何人在连接号码后，第一件事通常就是发送测试消息，而眼前唯一的号码正是刚连接的号码。这是很自然的做法，但平台会拒绝该消息。 没有任何设置可以更改这一点。WhatsApp 消费者应用支持将消息发送给自己，作为给自己留言的功能，但 API 不支持此功能。 ### 如何正确测试 使用第二个号码，并仔细确认您要测试的发送方向。 - 使用个人手机作为测试接收方。除已连接号码外，任何 WhatsApp 号码都可以使用。 - 如要自由测试发送功能，请先让测试号码向企业号码发送消息，这会开启 24 小时服务窗口。 - 如要在该窗口外测试，请发送已批准的消息模板，这是窗口外唯一获准发送的内容。 - 除非确有需要，否则不要为了测试而注册第二个企业号码：普通个人号码就足够了。 - 向已连接号码发送测试消息。平台会按设计拒绝该消息。 - 以为通过 API 可以使用给自己留言功能。实际上不可以。 - 在客户尚未先发消息的情况下测试自由格式消息，结果会改为失败并返回 131047。 **可以向自己的号码发消息吗？** 不可以。WhatsApp 不允许通过 API 这样做。 **有相关设置可以更改吗？** 没有。这是平台规则。 **应该使用什么号码测试？** 任何其他 WhatsApp 号码都可以，包括个人手机号码。 **为什么我的测试后来返回 131047？** 因为自由格式消息要求客户在过去 24 小时内向您发过消息。 --- ## WhatsApp 错误 131045：号码未注册 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131045 错误 131045 表示该号码尚未注册 Cloud API 消息发送。将号码添加到 WhatsApp Business 账户，以及注册该号码以发送消息，是两个独立步骤。此错误表示第二步尚未完成。 ### 为何有两个步骤 因为 WhatsApp Business 账户可以包含尚未发送消息的号码。添加号码用于确认所有权；注册号码则会启用 Cloud API 消息发送，并设置两步 PIN。 手动设置时，这是两个独立的 API 请求。您可能完成第一步后忘记第二步。此时号码会显示在账户中，在控制台看起来正常，但每次发送都会因这个错误而失败。 ### 如何解决 取决于号码是如何添加的。 - 手动设置时，使用该号码的 phone number id 和两步 PIN 调用 register 端点。 - 通过提供商进行 Coexistence 入门时，注册会在流程中完成，因此此错误通常表示流程尚未完成。 - 如果号码最近从其他账户迁移而来，必须在新账户中重新注册。 - 如果注册本身失败，通常原因是 PIN，对应错误 133005。 - 以为控制台中显示的号码已经可以发送消息。显示与已注册是两回事。 - 中途放弃入门流程。最后几个步骤才会完成注册。 - 将此错误与 133006 混淆，后者涉及验证而不是注册。 **什么是注册？** 为 Cloud API 消息发送启用号码，这与将号码添加到账户是两个独立步骤。 **需要自行完成吗？** 手动设置时需要。通过 Coexistence 流程时，系统会代您处理。 **需要重复注册吗？** 只有将号码迁移到其他账户后才需要。 **如果注册失败怎么办？** 通常是两步 PIN 的问题，会返回错误 133005。 --- ## WhatsApp 错误 133005：两步验证 PIN 不正确 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133005 错误 133005 表示注册时提供的两步验证 PIN 不正确。该 PIN 为 6 位数字，在号码首次注册时设置，多次输错会锁定后续尝试，因此恢复路径比重试更重要。 ### PIN 从何而来 该 PIN 在号码首次注册用于 Cloud API 消息发送时设置，之后任何一次再注册都需要它，包括将号码迁移到另一个账户时。 问题就出在这段时间差。PIN 在设置时只用一次，此后一年都用不上，很少有人会记下来，而当初设置它的人往往已经离职或调岗。于是错误恰好出现在号码迁移或重新注册的时刻，而这本来就是一个压力很大的时刻。 ### 如果没有人知道 PIN 有一条路可走，它比猜测慢，但确实有效。 - 不要再猜。多次失败会返回 133008，并在一段时间内锁定尝试。 - 在 WhatsApp Manager 中，于该号码的两步验证设置下更改 PIN；没有可用于停用它的 API 端点。 - 管理员也可以通过 API 向该号码的 phone number ID 发送 POST 请求来设置新 PIN，然后用它重新注册。 - 恢复之后，请把新 PIN 存放在下一个人能找到的地方。 ### 如何避免下次再发生 请把 PIN 当作基础设施来管理，而不是个人信息。它应与账户凭据放在同一个地方，由企业而不是碰巧负责设置的那个人持有，并且在此人离职后依然可用。 不这样做的代价不在于错误本身，错误本身微不足道。真正的代价是，在您需要迁移或重新注册一个正常运行的号码时，却无法操作。 - 反复猜测。这会触发 133008 并导致锁定。 - 把 PIN 只交给某一个人保管，而不是由企业保管。 - 以为设置完成后就再也用不到。迁移时需要它。 **这个 PIN 是在哪里设置的？** 在号码首次注册用于 Cloud API 消息发送时设置。 **如果我不知道 PIN 怎么办？** 在 WhatsApp Manager 中，于该号码的两步验证设置下更改它，或通过 API 设置一个新的 PIN。 **如果我一直猜会怎样？** 尝试会被锁定，您将收到错误 133008。 **什么时候需要这个 PIN？** 注册时需要，之后任何重新注册或迁移时也需要。 --- ## WhatsApp 错误 133008：PIN 猜测次数过多 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133008 错误 133008 表示两步验证 PIN 输入错误次数过多，后续尝试将在一段期间内被阻止。此错误通常出现在反复出现 133005 错误后，所以 PIN 输错后请停止操作，不要继续尝试。 ### 触发条件 一小段错误 PIN 尝试很容易发生，因为输错 PIN 后，人往往觉得再试一次值得。其实不值得。第一次出现 133005，就是提醒您先正确找回 PIN，不要再次猜测。 锁定后，无论您在此期间是否找到正确 PIN，号码都无法完成注册，必须等到锁定期间结束。 ### 锁定期间该怎么做 请等待，不要强行操作。 - 停止尝试。继续输入可能延长锁定期间，无法缩短等待。 - 在等待期间找回或重置 PIN：使用账户级访问令牌停用两步验证，或联系 Meta 支持。 - 确认您注册的是正确的 phone number id。针对错误号码的 PIN 失败，看起来完全相同。 - 安排在锁定期间结束后重试，不要反复查询。 - 锁定期间继续尝试。这没有帮助，还可能延长锁定。 - 等待期间没有先正确重置 PIN。 - 认定号码已被封禁。PIN 锁定是暂时状态，不涉及政策。 **锁定持续多久？** 由 Meta 确定的一段期间。期间内继续尝试可能延长锁定，无法缩短。 **我的号码被封禁了吗？** 不是。这是验证锁定，不涉及政策执行。 **锁定期间可以重置 PIN 吗？** 可以，等待期间最适合用来完成这项操作。 **发生原因？** 反复输入错误 PIN，每次都返回 133005。 --- ## WhatsApp 错误 133006：号码未验证 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133006 错误 133006 表示电话号码必须先完成验证，才能注册消息功能。验证通过 SMS 或语音通话发送的代码，证明您能控制该号码；它与添加号码和注册号码都是不同步骤。 ### 验证与注册的区别 验证证明企业能够控制该号码。注册则为 Cloud API 消息功能启用该号码。两者按此顺序进行，而此错误表示第一步尚未完成。 实际要求是，必须有人能通过 SMS 或自动语音通话，在该号码上收到代码。无人能接听的号码无法完成验证。在大多数情况下，真正的阻碍是这一点，而不是 API 请求。 ### 哪些情况会阻碍验证 几乎总是实体条件，而不是技术问题。 - 没有人持有手机或 SIM 卡，这在号码由前任持有人留下时很常见。 - 号码是无法接收 SMS 的座机，此时应使用语音验证。 - 虚拟号码的服务提供商会过滤或延迟代码。 - 号码已在其他 WhatsApp 账户上注册，必须先解决这一问题。 - 在验证前尝试注册。顺序很重要。 - 在座机上选择 SMS。语音验证正是为没有 SMS 的号码提供的。 - 假设虚拟号码一定能可靠收到代码。许多虚拟号码无法做到。 **如何验证？** 使用发送到该号码本身的 SMS 或自动语音通话代码。 **座机怎么办？** 使用语音验证，适用于无法接收 SMS 的号码。 **这和注册是同一回事吗？** 不是。验证证明控制权，注册则启用消息功能。 **可以跳过吗？** 不可以。完成验证前，注册会持续返回此错误。 --- ## WhatsApp 错误 131050：用户已选择不接收消息 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131050 错误 131050 表示收件人选择不接收您的业务消息。这不是故障，也没有技术上的绕过方法：对方已经作出选择，正确做法是记录这一选择并停止发送。 ### 为什么不存在绕过方法 这是因为该机制旨在保护人们，避免受到不接受拒绝的业务骚扰。如果平台允许绕过这一机制，对双方而言都没有继续使用的价值。 Meta 也会关注之后发生的情况。继续尝试向已选择不接收消息的人发送消息，会影响质量评分所依据的信号。质量评分下降后，整个号码的消息发送容量都会受到影响，而不只是这些收件人的容量。 ### 应该怎么做 正确记录一次，然后让系统的其他部分遵守这一选择。 - 将这一选择记录在联系人资料中，避免系统自动再次尝试。 - 在每个营销活动和自动化流程中屏蔽该号码，而不只是触发错误的那一个。 - 不要使用第二个业务号码联系对方。对方仍是同一个人，作出的也是同一个选择。 - 如果对方之后先发消息给您，服务窗口会重新开启，您可以回复。这是对方的决定，不是您的决定。 - 反复重试。该屏蔽是刻意设计的，除非对方自行更改，否则会一直有效。 - 只在失败的营销活动中屏蔽，导致另一个活动第二天再次尝试。 - 使用不同号码联系同一个人。这仍是在忽略对方的同一个选择。 **我可以再次给对方发消息吗？** 只有对方先给您发消息，服务窗口才会重新开启。 **有办法绕过吗？** 没有。尝试绕过会损害您的质量评分。 **这会影响我的整个号码吗？** 这一选择只针对该收件人，但反复尝试会整体影响您的质量评分。 **我应该把对方从名单中删除吗？** 应在所有地方屏蔽对方，而不只是失败的营销活动。 --- ## WhatsApp 错误 130497：不允许向收件人所在国家发送消息 https://easycoexistence.com/zh-hans/docs/whatsapp-error-130497 错误 130497 表示您的账户不允许向收件人所在国家发送消息。这是地区限制，与收件人本身无关，通常反映账户限制，而不是请求出错。 ### 国家或地区限制的原因 原因有几种，而且并非全部是永久性的。 - 新账户或未经验证的账户，在完成企业验证后限制可能解除。 - Meta 对整个 Cloud API 平台实施的国家或地区限制。 - 审核或执行措施期间设置的账户级控制。 - 号码使用了错误的国家代码，因此对您原本不打算联系的国家产生此错误。 ### 先排除格式问题 这是唯一能自行修复的原因，而且比其他原因更常见。 如果发送的电话号码保留了开头的 0，或省略国家代码而自动套用默认值，系统就会将其解析为与预期不同的国家。随后，消息会因该国家受限而发送失败。检查号码是否采用国际格式、仅含数字，并使用正确的国家代码，只需几秒，也能排除最可能的原因。 - 以为问题出在收件人。限制针对您的账户和该国家或地区。 - 反复重试。每次尝试之间限制不会改变。 - 跳过格式检查，而这是唯一由您控制的原因。 **是收件人屏蔽我了吗？** 不是。这是针对您账户的国家或地区限制。 **可以解除吗？** 部分限制是暂时的，完成企业验证后会解除。其他限制适用于整个 Cloud API 平台。 **可能是格式错误吗？** 可能，所以值得先排除。错误的国家代码会解析到错误的国家。 **重试有帮助吗？** 没有。每次尝试之间限制不会改变。 --- ## WhatsApp 错误 132007：模板政策违规 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132007 错误 132007 表示消息模板违反 WhatsApp 的商业消息政策。消息无法按当前形式发送，您需要重写并重新提交模板，而不是修改请求中的任何内容。 ### 政策实际禁止什么 比多数人第一次撰写模板时所假定的范围更窄。 - 对方没有要求，却读起来像未经请求的促销内容。 - 受禁止的类别，包括某些金融、健康和受监管产品。 - 误述发送者身份，或暗示不存在的关联关系。 - 误导性的紧迫感，或任何旨在施压要求回复的内容。 ### 为什么类别和措辞同样重要 提交为实用类别、读起来却像营销内容，即使内容本身没有明显问题，也属于政策问题。Meta 对模板进行分类，是因为两者对用户同意的预期不同，而将促销消息放在实用类别下发送会违背这一点。 实际做法是诚实地按照类别撰写模板。承认自己属于营销内容的营销模板可以获批。伪装成送货通知的营销模板则不会获批，只修改措辞而不改变类别，通常也无法挽救它。 - 重试发送。问题在模板，而不是请求。 - 只做表面修改后重新提交。如果类别错误，措辞无法挽救它。 - 以为获批后永久有效。模板之后仍可能因 132016 被停用。 **可以重试发送吗？** 不可以。必须重写模板并重新提交。 **为什么措辞看起来没问题却被拒绝？** 通常是类别问题。以实用类别提交的营销消息，无论措辞如何，仍属于政策问题。 **重新提交需要多久？** 审核通常很快，但没有保证的时间。 **这和 132016 是同一个问题吗？** 不是。132016 表示模板获批后被永久停用。 --- ## WhatsApp 错误 132012：消息模板参数格式不匹配 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132012 错误 132012 表示发送的参数值与消息模板定义的格式不符。包含 3 个变量的消息模板必须按顺序提供准确的 3 个正确类型参数，任何偏差都会触发此错误，而不是部分发送。 ### 哪些内容必须匹配 全部都必须匹配，而且系统不会提示。不存在部分匹配。 - 数量：正文中有 3 个占位符，就必须提供 3 个正文参数，不能多也不能少。 - 顺序：参数按位置匹配，因此交换两个参数会让值出现在错误位置；如果类型不同，则会触发此错误。 - 类型：货币或日期参数有规定的对象格式，不能作为纯文本发送。 - 组件：标题、正文和按钮参数分别属于不同列表，不能合并成一个列表。 ### 导致生产环境故障的编辑 编辑消息模板的人，往往不是调用 API 的人。有人为了让消息更清楚而添加变量，消息模板重新获批后，所有来自未变更集成的发送都会开始失败。 与其事后发现，不如提前防范。订阅消息模板状态 Webhook 后，编辑会作为事件送达；将消息模板的变量数量视为集成约定，并在变更时审核，就能避免一次措辞改进变成服务中断。 - 为保险起见发送额外参数。参数过多和过少一样错误。 - 把按位置匹配的参数当成命名参数。它们只能按位置匹配。 - 编辑消息模板，却不检查发送参数的代码。 **我应该发送多少个参数？** 严格按照消息模板定义的数量，并按顺序发送。 **可以发送额外参数吗？** 不可以。参数过多和过少都会以同样方式失败。 **为什么突然开始出现这个错误？** 通常是因为消息模板被编辑，变量数量发生了变化。 **参数有名称吗？** 没有。参数按位置匹配，因此顺序很重要。 --- ## WhatsApp 错误 132016：消息模板已永久停用 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132016 错误 132016 表示消息模板已永久停用，无法再次使用。这通常是质量持续下降的结果：收件人屏蔽或举报了使用该模板发送的消息，模板质量评分下降，Meta 最终撤下了它。 ### 消息模板如何走到这一步 通常不是一步造成的。已获批准但不受收件人欢迎的消息模板会不断累积屏蔽和举报，质量评分从绿色降为黄色，再降为红色，随后进入暂停状态。反复暂停最终会导致永久停用。 如果您持续监听，这个过程完全可以观察到。模板质量 Webhook 会报告每次变化，模板变为黄色时就是警报，您仍有时间采取行动。忽略这个信号，正常可用的消息模板就会变成无法使用的模板。 ### 应该怎么处理 按以下顺序做两件事。 - 停止使用该模板发送消息，并改用其他模板，因为它永远无法再次使用。 - 在编写替代模板前，先了解收件人不喜欢它的原因，否则替代模板可能重蹈覆辙。 - 同时检查受众和措辞。即使模板本身不错，发送给不期待这些消息的人，仍会收到屏蔽反馈。 - 订阅模板质量 Webhook，这样下一次质量下降在黄色阶段就能被发现，而不是等到停用后才知道。 - 用新名称重新创建同一个模板。失败的是内容本身。 - 忽略黄色质量评分。黄色是警告，红色是后果。 - 把问题归咎于措辞，而受众才是真正的问题。 **可以重新启用吗？** 不可以。永久停用就是永久停用。 **可以用新名称重新创建吗？** 可以，但导致质量下降的是内容，因此新模板很可能重蹈覆辙。 **这与 132015 有什么不同？** 132015 表示暂停，之后可以恢复。132016 则不能恢复。 **我可以提前发现吗？** 可以。模板质量 Webhook 会在问题发展到这一步前报告质量下降。 --- ## WhatsApp 错误 131056：向同一收件人发送的消息过多 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131056 错误 131056 表示您的业务号码在短时间内向同一收件人发送了过多消息。这是针对每个号码对的速率限制，与账户整体吞吐量分开，通常表示某项自动化流程在重复执行。 ### 为什么按号码对限制 因为它要防止的不是一般性的消息量，而是某个人被大量消息淹没。账户整体吞吐量可能仍在限制以内，但如果在 1 分钟内向同一收件人发送 30 条消息，对方仍会把它视为垃圾消息，与账户总量无关。 因此，限制针对号码对，而不是账户。这也解释了为什么消息量很低、从未接近整体速率限制的号码，也可能出现此错误。 ### 通常是什么原因 几乎总是由自动化流程引起，而不是人为输入。 - 重试循环把投递失败当成发送失败，因而再次发送。 - Webhook 处理程序发送回复，并因同一事件被多次调用而重复发送。 - 聊天机器人在很短时间内将一条回复拆成多条短消息。 - 开发期间，测试脚本反复向同一号码发送消息。 ### 如何避免 在对话层级限流，而不只是账户层级限流。在发送前限制每位收件人每分钟可接收的消息数，几乎不会增加成本，却能防止此错误及其带来的客户体验问题。 消息去重同样重要。Webhook 事件可能被投递多次。如果处理程序发送回复前不检查自己是否已处理该 message id，负载升高时就会产生这种情况。 - 重试，导致向已经被大量消息淹没的收件人再发送一条消息。 - 只在账户层级限流。此限制按收件人计算。 - 处理 Webhook 事件时，没有按 message id 去重。 **这是我的账户速率限制吗？** 不是。账户速率限制的代码是 130429。此限制按收件人计算。 **为什么消息量低也会出现？** 因为限制针对号码对，而不是账户总量。 **如何停止此错误？** 按对话限流，并按 message id 对 Webhook 事件去重。 **我应该重试吗？** 不应该。重试会向同一收件人再发送一条消息。 --- ## WhatsApp 错误 80007：WhatsApp Business 账户速率限制 https://easycoexistence.com/zh-hans/docs/whatsapp-error-80007 错误 80007 表示 WhatsApp Business 账户已触及速率限制。它影响管理请求和读取请求，而不是消息吞吐量，因此通常原因是轮询：某项程序检查状态的频率远高于数据变化的频率。 ### 它统计什么 针对账户发出的请求，而不是发送给客户的消息。 - 读取号码、号码的质量评级和吞吐量等级。 - 列出和读取消息模板。 - 订阅和 Webhook 配置请求。 - 按计划执行的任何状态检查，数量通常就是由此产生。 ### 轮询是值得修复的原因 对少量号码每 30 秒轮询一次状态，相当于每天针对数据发出数千次请求，而这些数据每月只变化几次。最终会触及此限制，而且一旦触及，轮询会在某些重要变化刚发生时停止工作。 Webhook 可改变这种方式。Meta 会在质量评级、账户信息或模板状态发生变化时推送更新，完全不消耗请求，而且比任何轮询都更快到达。正确的架构是用 Webhook 处理变化，把轮询保留为低频核对步骤，而不是主要机制。 - 以很短的间隔轮询状态，在很少变化的数据上消耗速率限制。 - 通过增加重试来应对，反而会更快消耗速率限制。 - 将它与 130429 混淆，后者与发送消息有关。 **这是关于发送消息的吗？** 不是。发送消息的限制代码是 130429。此代码针对管理请求和读取请求。 **是什么原因造成的？** 通常是以很短的间隔轮询状态。 **我应该改用什么方式？** 订阅 Webhook，并将轮询保留给低频核对。 **它会自动解除吗？** 会，时间窗口结束后会解除，但如果轮询方式不变，限制还会再次出现。 --- ## 面向代理机构和咨询公司的 WhatsApp Coexistence https://easycoexistence.com/zh-hans/whatsapp-coexistence-for-agencies 代理机构面对每个客户时，都会遇到同一个问题：这个号码是员工一直在接听的号码，而迁移号码会让他们失去 WhatsApp Business 应用。Coexistence 消除了这个问题，因此无需改变工作方式，也能连接客户号码。 ### 为什么客户号码会阻碍大多数集成？ 因为号码不是您可以随意更改的，而且围绕它的一切都已经在使用中。 客户的号码印在车辆、发票和网站上，也承载着多年的过往对话。有人整天用手机接听，甚至知道常客的名字。只要方案涉及迁移这个号码，WhatsApp Business 应用就会停止在该号码上运行，而那个人必须改用您构建的系统。大多数客户都会拒绝，这样做也是正确的。 这就是许多代理机构最终使用非官方网关的原因。那些网关能让手机继续工作，而这正是客户唯一在意的事。封禁风险一直隐藏着，直到风险真正发生。Coexistence 是同一承诺的官方版本。 ### 客户入驻实际上是怎样进行的？ 客户只需在自己的手机上完成一件事，大约需要 2 分钟。 您向客户发送连接链接。客户打开链接，Meta 自己的弹窗会运行，然后选择其 Business Portfolio 和号码，再用 WhatsApp Business 应用扫描代码。整个操作就是这样。无需安装任何东西，也无需交出凭据，扫描完成后应用会立即继续工作。 号码会留在客户的 Business Portfolio 中，而不是归在您名下，这一点有两个原因。客户询问谁拥有连接时，答案很清楚；即使客户更换代理机构，合作关系也能延续。事后再解释会更难，而这件事可以提前明确说明。 ### 管理 20 个客户时会是什么情况？ 一个账户、20 个号码、每个号码一项固定费用，以及一份一目了然的列表。 没有会让您需要升级的层级，也没有在某个数量门槛后改变的方案。新增第 21 个客户，与新增第 1 个客户的操作相同。每个号码都会报告自己的质量评分、消息层级和连接状态，因此某个客户的号码质量下降时，您可以在客户联系您之前发现。 在这个规模下，大部分价值都来自这种可见性。连接可能会静默失败，而 WhatsApp Business 应用几乎能在所有故障期间继续工作，客户也无从得知。没有监控时，第一个信号往往是客户询问为什么自动化停止了，而这样的对话一开始就很被动。 ### 代理机构可以由代理执行入驻，而不是让客户亲自操作吗？ 大部分可以，而无法代办的部分，客户本来就必须亲自完成。 通过 MCP 连接器，助手可以调用 get_connect_link 生成客户打开的链接，然后调用 set_webhook_destination，将该号码指向您用于处理消息的系统，最后检查号码的连接状态，确认一切已上线。整个流程无需任何人打开控制台。 助手无法扫描代码。Meta 的入驻流程在浏览器中运行，需要持有该号码的手机，这是有意设置的保护措施，而不是功能缺口。只有客户本人可以授权自己的号码，这样的安排才是合适的。 - 先承诺客户员工不会察觉，之后却迁移号码。迁移会让他们失去应用，他们会立即发现。 - 把客户号码连接到您自己的 Business Portfolio 中。每个号码都应留在客户自己的 Business Portfolio 中，这样连接才属于客户。 - 在规模扩大后仍把监控当作可选项。20 个客户出现 20 种静默故障，是支持负担，不是边缘情况。 **每个客户都需要在您这里拥有自己的账户吗？** 不需要。一个账户可以管理您负责的所有号码，每个号码分别计费，连接器会列出全部号码。对于您服务的企业，没有使用限制。 **连接由谁拥有，是我还是客户？** 号码会留在客户的 Business Portfolio 中。您负责管理连接，而与 Meta 的基础关系属于客户。这是客户询问时最准确的答案。 **如果客户离开，会发生什么？** 号码会断开连接，而客户的 WhatsApp Business 应用会完全照常继续使用。号码不会因为曾经连接过而被永久更改。 **谁向 Meta 支付消息费用？** 客户通过其 WhatsApp Business 账户中的付款方式自行支付。相关费用不会经过我们，因此没有任何一方需要加价。 --- ## 成为 Meta Tech Provider 意味着什么，以及为什么重要 https://easycoexistence.com/zh-hans/meta-tech-provider Meta Tech Provider 在经过验证的 Business Manager 上运行自己的 Meta 应用，并通过该应用连接其他企业的 WhatsApp 号码。EasyCoexistence 就是其中之一，因此号码会直接连接到您自己的 Business Portfolio，而不是归在经销商账户下。 ### Tech Provider 实际上做什么？ 它运行其他企业用来连接 WhatsApp 号码的应用。 企业开始接入时，Meta 的 Embedded Signup 会打开，并要求企业授权某个应用。该应用属于 Tech Provider，获授权后便可代表企业操作号码：读取其状态、发送消息、管理模板，并设置 Webhook 的投递位置。提供商提供的所有功能都建立在这种关系之上。 这一状态让连接具备合法性。Meta 会向拥有自己应用且应用部署在经过验证的 Business Manager 上的公司授予该状态，前提是通过 App Review。这也是提供商与持有他人凭据的脚本之间的区别。 ### 为什么应用由谁拥有很重要？ 因为这决定了您客户的号码最终关联到谁的账户。 建立在他人提供商账户上的工具，会继承该账户的限制。人们在通用自动化平台上遇到的单一连接上限，就来自这里：平台持有一段提供商关系，所有使用者共同分享它。 使用我们自己的应用时，连接会直接建立在客户的 Business Portfolio 与 Meta 之间。号码仍归客户所有，没有经销商代为持有，添加下一个号码的操作也与添加第一个相同。对代理机构来说，这不是技术细节，而是客户询问谁控制其号码时的答案。 ### 这一状态有什么要求？ 经过验证的 Business Manager、通过 App Review 的应用，以及记录完整流程的演示视频。 企业验证会将应用关联到真实的法律实体，Meta 会将提交的文件与登记资料核对。App Review 会检查应用请求哪些权限以及原因；对于 WhatsApp，还包括记录视频，展示完整的接入流程确实能够运行。这些都不收费，但都需要时间，而时间无法压缩。 如果您考虑自行构建，这一点值得了解。连接您自己拥有的单个号码不需要这些条件。为客户连接号码则全部需要，等待时间按周计算，而不是按天计算工作量。 ### 这会给连接号码的企业带来什么变化？ 有 3 件事，而且界面上都看不出来。 号码会连接在企业自己的 Business Portfolio 中，因此与 Meta 的关系归企业所有。Meta 会直接向企业的 WhatsApp Business Account 收取对话费用，这也是中间没有人可以加价的原因。此外，单个账户可以持有的号码数量没有上限，因为不存在需要分摊的共享提供商关系。 不会改变的是接入流程本身。Embedded Signup 是 Meta 自己的流程，弹窗属于 Meta，代码扫描则在 WhatsApp Business 应用中完成。Tech Provider 不会取代这些步骤，而是让企业能够使用这些步骤。 - 以为每个提供商都有自己的 Tech Provider 状态。许多提供商建立在他人的状态之上，连接上限也由此产生。 - 计划在截止日期前取得该状态。App Review 的时间不是公司能够控制的。 - 把它当成徽章。它是一种账户关系，并决定客户的号码归哪个 Business Portfolio 所有。 **这是否意味着 Meta 为 EasyCoexistence 背书？** 不，这也不是任何提供商应该暗示的意思。Tech Provider 是一种技术状态，允许企业通过获批准的应用连接其他企业的号码。它不代表 Meta 认可建立在其上的产品。 **我可以自己成为 Tech Provider 吗？** 可以。只要拥有经过验证的 Business Manager 并愿意完成 App Review，任何公司都可以申请。成本在于等待时间，而不是费用。 **我的号码归哪个 Business Portfolio 所有？** 归您所有。连接建立在您的 Business Portfolio 与 Meta 之间，并由我们的应用获授权代表您操作号码。号码不会转到我们的账户下。 **我可以连接的号码数量有限制吗？** 没有。其他地方出现的限制，源于许多用户共享同一段提供商关系，而这里不是这种运作方式。 --- ## WhatsApp Coexistence 的费用：各提供商逐一比较 https://easycoexistence.com/zh-hans/whatsapp-coexistence-pricing-compared 各提供商的计价单位有三种：按号码、按席位或按消息。因此表面价格无法直接比较，只有在给定号码数量下才能看出真实成本。本页按 1 个、10 个和 50 个号码逐一计算。 ### 为什么表面价格无法比较？ 因为它们收费的对象不同，而计价单位决定了每种方案适合哪类业务。 按号码计价取决于您持有多少个 WhatsApp 号码。这是代理商真正能控制的单位，EasyCoexistence、360dialog 和 Dualhook 都采用这种方式。 按席位和按联系人计价取决于有多少人回复消息，以及您与多少客户沟通。WATI 和 respond.io 采用这种方式，当您购买的核心是客服团队时，这是合适的单位。 按消息计价只看消息量，这是 Twilio 的模式：没有平台费，也没有按号码收取的费用，但在 Meta 收费之外，每条消息还要另外收费。 因此，唯一诚实的比较方式是在给定的连接数量下进行，下表正是这样做的。 ### 以平台计价的提供商在相同数量下费用如何？ 它们无法被如实地放在同一列比较，因为其费用完全不随号码数量变化，变化的是席位和联系人数量。 WATI 公布的套餐为 3 至 10 个用户，每月活跃联系人 500 至 2,500 个。respond.io 公布的价格是 5 个用户、1,000 个联系人 US$ 79，最高升至 US$ 279。YCloud 公布了一个免费档，然后是 US$ 39、US$ 89 和 US$ 399，用户和渠道可作为附加项购买，每月分别为 US$ 10 和 US$ 5。 对于只有一个号码的客服团队，这些方案很有竞争力，并且包含收件箱，而单纯的连接不包含。对于拥有 50 个客户号码的代理商，成本体现在附加项上，并且按渠道而非按对话计算。 决定选择的问题是：是否会有人登录您所付费的收件箱。 ### Twilio 两者都不收费，情况如何？ Twilio 公布的费用是每条消息每个方向 US$ 0.005，另加 Meta 自己的模板费用，后者原价转收，不加价。其公布的价格中没有月度平台费，也没有按号码收取的费用。 因此，对于几乎不发送消息的号码，这是最便宜的持有方式；对于繁忙的号码，则是最昂贵的运营方式。50 个闲置号码不产生费用；50 个进行真实对话的号码则要永远按消息付费。 还需要知道的是，Twilio 的定价页没有提到 Coexistence。如果让 WhatsApp Business 应用在该号码上继续可用对您很重要，在比较其他方面之前，应先向他们确认这个问题。 ### 代理商究竟应该选哪一种？ 选择计价单位与您业务增长点相匹配的那一种。 如果增长的是客户号码，那么带批量折扣的按号码计价是唯一不会因您成功而惩罚您的形式。EasyCoexistence 在最多 5 个号码时每个 US$ 9，随号码增加降至每个 US$ 1，因此在 50 个客户时，每个号码的费用比第一个更低，而不是更高。 如果增长的是在同一收件箱中回复的客服人员，按席位计价的平台才是合适的选择，本页不会反驳这一点。WATI 和 respond.io 做到了这一点，而且运作良好。 如果增长的是少数几个号码上的消息量，值得按您的实际发送量，将 Twilio 的按消息模式与其他方案进行测算。 对于本产品所针对的情形，即代理商或开发者持有并不属于自己的号码，带批量定价的按号码计价是唯一与业务同向扩展的方式：号码越多，每个号码的费率越低。 - 直接比较表面价格。它们的计价单位有三种，数字最小的往往并非正确的选择。 - 以为其中任何一家会在 Meta 的消息费用上加价。本页中的提供商都不会，Meta 会直接向您收费。 - 把未记载的功能当作不存在。如果某个定价页没有提到 Coexistence，请直接询问提供商，不要只相信本表。 **这些价格是最新的吗？** 这些价格来自各提供商自己的定价页，截至 2026 年 9 月，并已在上方数据中附上链接。价格会变动，决定之前请核对原始来源。 **为什么 EasyCoexistence 的每号码价格会越来越低？** 因为监控一个连接的成本不会随连接数量成比例增长。代理商持有 50 个号码，工作量并不是 50 倍，所以价格也不是 50 倍。 **这些提供商会在 Meta 的收费上加价吗？** 本页中的提供商都不会。Meta 会向您自己的 WhatsApp Business 账户所绑定的付款方式收取消息费用，这也是中间方无法对其打折的原因。 **哪些提供商支持 Coexistence？** YCloud 和 8x8 有相关文档，Dualhook 和 EasyCoexistence 则是围绕它构建的。其他几家的定价页没有提到它，这并不能说明支持与否，值得直接询问。 --- ## WhatsApp Coexistence 术语表 https://easycoexistence.com/zh-hans/whatsapp-coexistence-glossary WhatsApp Coexistence 相关术语容易混淆。实际使用中，很多混淆源于两个人用同一个词指不同事物。以下是本网站采用的定义，每项都链接到详细说明页面。 ### 为什么这些术语会造成这么多困扰？ 因为其中几个术语分别指向不同层级的事物，但看起来像处于同一层级。 Business Portfolio 包含 WhatsApp Business Account，后者包含电话号码，每个号码都有一个电话号码 ID。在对话中，这四者都被称为账户，因此“检查账户是否正常”可能指 4 种不同的检查。本平台的两个 24 小时窗口也有同样问题：它们衡量的是互不相关的事情，却经常被混为一谈。 另一部分原因是，Meta 和各家服务商对同一事物使用不同词汇，而服务商之间也没有统一说法。本页在有对应词汇时采用 Meta 的原有用语，并明确说明哪些术语是我们自己的说法。 ### 实际使用中，哪些区别真正重要？ 有 3 个，而且每个都曾让人多花 1 天时间。 客户服务窗口和同步窗口都是 24 小时，但两者完全无关。前者决定自由文本是否能够送达，从客户上次发送消息时起算。后者决定聊天记录是否仍可跨平台拉取，从入门流程完成时起算。 已关联设备不是 API。它是登录在其他位置的消费者 WhatsApp 客户端。非官方工具会自动操作这种客户端，也正是因此可能导致号码被封禁。 Webhook 目标也不是号码上的设置。它是应用订阅账户时的覆盖设置，所以连接移除后会消失，重新连接时必须再次设置。 **Coexistence 是不同于 Cloud API 的另一种 API 吗？** 不是。Coexistence 是将号码接入 Cloud API 的一种方式，同时保留 WhatsApp Business 应用在该号码上的运行状态。端点、消息格式和规则都完全相同。 **Business Portfolio 和 WABA 有什么区别？** Business Portfolio 是 Meta Business Manager 中的公司级容器。WhatsApp Business Account 位于其中，并保存电话号码。一个 Business Portfolio 可以包含多个 WABA。 **BSP 和 Tech Provider 是同一回事吗？** 两者有重叠，但指的是不同事物。Tech Provider 是 Meta 授予的状态，允许公司通过自己的应用连接其他企业的号码。BSP 通常指销售消息平台的公司，但该公司不一定拥有这种状态。 **MCP 与 WhatsApp 有什么关系？** 两者本质上没有关系。MCP 是一种让 AI 助手访问工具的协议，而 WhatsApp MCP 服务器会将一个号码作为这类工具提供。它不能接收消息，只能在收到请求时执行操作。 --- ## WhatsApp Webhook 字段，以及各自的去向 https://easycoexistence.com/zh-hans/docs/webhook-fields WhatsApp Business 账户以带名称的字段发送事件。2 项承载对话内容，并发送到您的端点；另 6 项承载运行状态，也是监控的基础。了解两类字段的区别，才能决定架构。 ### 各字段承载什么？ messages 承载客户发送到 WhatsApp Business 的所有内容：文字、媒体引用、回复和反应。smb_message_echoes 承载团队从 WhatsApp Business 应用发送的内容。它只存在于 Coexistence 连接中，让软件看见人工回复。 account_update 承载连接状态：应用从账户卸载后触发的 PARTNER_REMOVED、ACCOUNT_OFFBOARDED、ACCOUNT_RECONNECTED，以及限制或违规事件。phone_number_quality_update 承载质量评级和吞吐量变化。account_alerts 承载 Meta 针对账户发出的警报，account_review_update 承载审核结果。 business_capability_update 承载消息上限和功能变化，phone_number_name_update 承载显示名称的批准或拒绝。 ### 为什么分流会影响架构？ 原因是它决定对话内容是否会到达服务商。 override 会让 2 项消息字段直接从 Meta 发送到您的端点。另 6 项运行字段继续发送到服务商，因此可以在无人持有消息的情况下提供控制台和警报功能。 这也是为什么“不存储消息”的说法可以是结构层面的事实，而不只是政策。如果消息字段被发送到别处，代码中就没有可用于存储它们的路径。在我们的情况下，未配置 override 的账户回退到默认 callback，处理程序会丢弃这些事件，不持久化。 ### 处理程序需要接收哪些字段？ 如果已配置 override，就只有 2 项消息字段；值得让处理程序忽略其他字段，而不是因其而失败。 Meta 会随时间增加字段，负载结构也可能在未提前获知的情况下增加键。处理程序按字段名称分支，并忽略无法识别的内容，就能继续运行；假定固定结构的处理程序在遇到首个陌生事件时抛出错误。 也值得明确处理 smb_message_echoes，而不是把它当作噪声。没有它，软件无法知道人工已经回复，客户可能针对相同问题收到 2 条回复。 - 把事件当作通用负载。每项事件都标明字段名称，处理程序需要按名称分支。 - 忽略 smb_message_echoes。没有它，软件可能在人工已经回复后继续回复。 - 遇到无法识别的字段就失败，而不是跳过。Meta 可直接添加字段，无需征求同意。 **我能只接收部分字段吗？** 配置 override 后，消息路径将发送给您。运行字段的分流固定，因为监控建立在这部分字段上。 **smb_message_echoes 是否存在于普通 Cloud API 连接中？** 不在。它的存在是因为 Coexistence 连接允许人工从应用发送，软件也从 API 发送。 **没有配置目的地时，消息事件怎么处理？** 它们到达我们的默认 callback 后，直接丢弃，不作持久化。 **字段名称属于 Meta，还是属于您？** 属于 Meta。这里没有我们自行创造的名称，所以值得一次记住。 --- ## 验证 WhatsApp Webhook 端点 https://easycoexistence.com/zh-hans/docs/webhook-verification 在发送任何事件前，Meta 会向您的端点发送一个包含 hub.mode、hub.verify_token 和 hub.challenge 的 GET 请求。您的端点必须比较令牌，并将 challenge 作为原始正文返回。其他任何响应都会导致发送无法开始。 ### Meta 具体会发送什么？ Meta 会向您的 URL 发送一个带有 3 个查询参数的 GET 请求。hub.mode 会设为 subscribe。hub.verify_token 是您设置目标地址时配置的令牌。hub.challenge 是 Meta 为本次尝试生成的值。 您的端点应将 hub.verify_token 与您选择的令牌进行比较。如果匹配，则以 200 响应，并将 hub.challenge 作为完整的响应正文返回。不能包装在 JSON 中，不能在两侧加引号，也不能带有某些框架默认添加的尾随换行符。 如果令牌不匹配，请返回 403。这就是完整协议，设计上非常简单。 ### 答错为何会静默失败？ 因为验证失败不是您系统中的错误，而是 Meta 系统中缺少该目标地址。 如果没有正确原样返回 challenge，Meta 就不会开始向该目标地址发送内容。您的服务器会对验证请求返回 200，日志也会显示请求已到达，但任何控制台都不会报告问题。唯一症状是消息始终收不到，因此多数人会将其诊断为 Coexistence 问题，而不是握手问题。 所以，在发出请求前进行验证很有价值。我们会在发出 Graph 请求前检查 URL 是否为 HTTPS，以及是否提供了验证令牌，让格式错误的目标地址立即失败，而不是看起来像已连接。 ### 还有什么会阻止验证？ 有 3 件事与代码无关。 端点前面有身份验证。网关、基本身份验证层或 IP 允许列表都会拒绝 Meta 的请求，而 Meta 没有可提供的凭据。验证路由必须无需凭据即可访问。 重定向。Meta 会调用您提供的 URL，301 重定向到规范主机的方式无法完成握手。请提供最终 URL。 还有会序列化响应的框架。如果处理程序返回的字符串被框架统一包装成 JSON，正文就会在 challenge 两侧加上引号，因此无法匹配。 - 返回 JSON。正文必须是原始 challenge 值，周围不能有任何内容。 - 将端点置于身份验证之后。Meta 没有凭据，因此请求会被拒绝。 - 向 Meta 提供会重定向的 URL。请使用最终 URL。 **应使用什么令牌？** 使用您选择的任何字符串。这样，您的端点就能将 Meta 的请求与其他得知该 URL 的人的请求区分开。 **验证多久进行一次？** 设置时进行一次，之后每次设置目标地址时也会进行。正常工作的端点不会在每个事件到达时重新验证。 **我可以自行测试吗？** 可以。使用 3 个参数调用您自己的端点，并检查正文是否完全返回 challenge 值。 **如果验证时我的服务器宕机了怎么办？** 握手会失败，目标地址不会启用。再次保存即可重新运行验证。 --- ## MCP 工具参考 https://easycoexistence.com/zh-hans/docs/mcp-tools-reference 该连接器可处理账户中的每个号码，共提供 16 个工具。list_numbers 排在首位，因为其他工具都需要使用它返回的 connection_id。付款逾期时有 6 个工具会受限：4 个会影响外部系统的工具、返回访问令牌的 get_api_credentials，以及 create_connect_link。其余 10 个，即读取连接状态和模板的工具以及 Partner API 设置工具，仍可使用。 ### 每个工具有什么作用？ 读取：list_numbers 返回已连接号码、状态、质量评级和消息层级，也是所有其他调用的起点。get_number_health 会同时返回实时 Meta 快照、近期监控时间线、Webhook 事件和轮询检查结果。get_api_credentials 返回 Graph API 基础 URL、WABA id、phone number id，以及账户自己的访问令牌（如有）。 发送：send_message 会在 24 小时窗口内发送自由文本，窗口内回复免费。send_template 会发送已批准的模板，用于向尚未发来消息的人开启对话。list_templates、create_template 和 get_template_status 覆盖消息模板的完整生命周期。 连接：set_webhook_destination 会将收到的消息和应用回显路由到您的系统，传入 null 即可重置。get_connect_link 返回连接新号码所需的控制台链接和步骤。get_docs 以 markdown 格式返回产品文档。 Partner API 面向让自己的客户连接号码的软件或代理商：get_partner_setup 显示付款状态、API 密钥、事件 URL 和下一步。create_api_key 生成 Partner API 密钥并只显示一次，未经明确确认不会替换现有密钥。revoke_api_key 撤销该密钥，同样需要确认。set_partner_events_url 设置状态事件的发送地址，并只返回一次签名密钥。create_connect_link 为一位客户创建托管连接链接，有效期 1 小时，与 POST /api/v1/connect-sessions 相同。 ### 为什么 connection_id 很重要？ 因为它把一条指令关联到特定号码，而助手无法自行猜出这个值。 所有针对号码执行操作的工具都需要 connection_id，而它只能来自 list_numbers。实际使用时，助手收到发送消息的请求，会先调用 list_numbers，所以一个会话中的首次请求通常比后续请求慢。 这也让拥有多个号码的账户从设计上保持明确。系统没有默认号码，也不会隐式选择号码，因此没有说明目标号码的指令会被询问，而不会被猜测。 ### 付款逾期时会发生什么？ 有 6 个工具会受限：会影响外部系统的 send_message、send_template、create_template 和 set_webhook_destination；get_api_credentials，因为它返回账户的访问令牌，受限账户可借此直接通过 Graph API 发送；以及用于连接新号码的 create_connect_link。其他读取功能仍可用，Partner API 设置工具也一样：get_partner_setup、create_api_key、revoke_api_key 和 set_partner_events_url。 这是有意的设计，并非遗漏。如果账户无法查看受限原因，也无法检查号码是否正常，就只能提交支持请求。这些读取功能也是连接状态监控的基础，因此在最需要监控时关闭它们，反而会让监控停止。 实际结果是，付款逾期的账户仍能回答有关自身状态的问题，也仍会受到监控。停止的是所有触达客户的操作。 - 以为连接器会接收消息。MCP 使用请求和响应；收到的消息需要通过 Webhook 传入。 - 将 connection_id 写死。它来自 list_numbers，不应手动记录。 - 以为付款逾期的账户会完全离线。读取功能和监控会按设计继续运行，但凭据除外，因为其中包含用于发送的访问令牌。 **我需要选择要调用的工具吗？** 不需要。您用自然语言提出请求，助手会自行选择工具，这正是工具说明的用途。 **它能读取我的对话吗？** 不能。收到的消息会路由到您指定的 Webhook 目标。连接器读取的是账户和号码状态。 **get_docs 有用吗？** 比听起来更有用。它会把我们的文档以 markdown 格式交给助手，因此关于 Coexistence 规则的答案来自我们的文档，而不是助手凭记忆回答。 **一个连接器可以覆盖多个客户吗？** 可以。一个账户可以存放您需要的任意数量的号码，list_numbers 会返回全部号码。 --- ## 连接号码：逐步说明 https://easycoexistence.com/zh-hans/docs/connecting-a-number 连接流程使用 Meta 自有的 Embedded Signup：选择 Business Portfolio、WhatsApp Business Account 和号码，然后在 WhatsApp Business 应用中扫描代码。整个过程约需 2 分钟，应用会一直正常运行。 ### 流程中会发生什么？ Meta 的弹窗会按顺序询问三项内容。 首先是 Business Portfolio，也就是 Business Manager 中的公司层级容器。然后是其中的 WhatsApp Business Account。最后是手机号码，该号码必须已经在 WhatsApp Business 应用中注册，因为 Coexistence 连接的是应用正在使用的号码，而不是创建新号码。 之后流程会转到手机。Meta 显示代码，持有该号码的人在设备上打开 WhatsApp Business 应用并扫描代码。这是唯一离开浏览器的步骤，也是不能由其他人代替企业完成的步骤。 ### 设置过程中会决定哪些无法更改的事项？ 是否共享现有聊天记录。这项选择只会询问一次，并对该连接永久生效。 选择是，会把最近的聊天记录同步到 API，让软件开始运行时已有上下文，而不是毫无背景。选择否，API 只能看到连接完成后的新消息。两种选择都合理，大多数集成只关心新对话，但如果要更改决定，就必须先断开连接，再重新连接。 这项同步也有时间限制。必须在设置完成后的 24 小时内启动，而且只能运行一次。错过任何一项都会产生陌生的错误，而不是警告，所以最好在当天决定是否共享聊天记录，不要等到集成工作时才处理。 ### 开始前应准备什么？ 需要准备三项内容，提前准备好可以避免流程进行到一半被迫中止。 拥有该号码的 Business Portfolio 访问权限，这通常由企业负责人持有，而不是负责集成的人。持有该号码的手机，手机需要解锁并安装 WhatsApp Business 应用。最好也准备好 Webhook 目标端点，因为在设置流程结束时填写，比之后再回想起来更妥当。 如果流程完成前被关闭，号码可能已附加到账户，却尚未注册，从而在首次发送消息时产生错误。重新从头运行流程即可修复。 - 手机不在身边就开始。扫描无法稍后改用另一部设备完成。 - 号码出现后就关闭弹窗。后面还有步骤，提前停止会让号码保持未注册状态。 - 等集成完成后才决定是否共享聊天记录。该选择会在设置完成 24 小时后失效。 **我可以连接不属于我的号码吗？** 只有号码所属企业可以授权。您向对方发送链接，由对方在自己的手机上完成流程。 **设置过程中应用会停止运行吗？** 不会。应用会一直运行，包括扫描代码期间。 **如果号码在个人版 WhatsApp 应用中怎么办？** 必须先转移到 WhatsApp Business 应用。Coexistence 连接的是 Business 应用号码。 **我可以重新运行流程吗？** 可以。断开后重新连接即可重跑流程，也会重新获得接受聊天记录共享的选择机会。 --- ## 24 小时客户服务窗口 https://easycoexistence.com/zh-hans/docs/customer-service-window 客户向您的号码发送消息后，客户服务窗口便会开启，并持续 24 小时。在窗口内，您可以发送自由文本，而且回复免费。窗口关闭后，只有 Meta 已批准的消息模板才能送达。 ### 计时究竟何时开始？ 客户发送消息时开始，而且每次客户再次发送消息，计时都会重新开始。 这是最容易弄反的细节。窗口不是从您上次发送消息时、对话开始时，或工单开启时计算，而是从客户最近一次发来的消息计算。这意味着，活跃的对话实际上不会关闭，而单向对话会在 1 天后关闭。 这也意味着窗口按联系人计算，而不是按号码计算。同一个号码上，一位客户可能处于窗口内，而另一位客户同时处于窗口外。 ### 窗口内外分别可以发送什么？ 窗口内可以发送任何内容：普通文本、媒体，以及您想发送的消息模板。窗口外只能发送 Meta 已批准的消息模板。 这就是消息模板存在的原因。对于尚未发来消息的人，消息模板是开始或重新开始对话的合规方式。由于收件人没有主动发起消息，模板会事先经过审核。 使用 Coexistence 号码时，还有一个额外影响。WhatsApp Business 应用无法发送消息模板，因此窗口外的消息必须通过 API 发送。团队成员可以从手机自由回复正在进行的对话，但无法重新开启已经冷却的对话。这也是连接号码的实际原因之一。 ### 为什么集成通常要到生产环境才发现这个问题？ 因为测试总是在窗口内进行。 构建集成的人会先向自己发送消息，然后在几秒后回复。这仍在 24 小时内，因此普通文本可以正常发送，所有测试都会通过。第一个失败的真实场景，通常是客户在昨天发送过消息，而这时窗口已经关闭。 可靠的做法是在发送前加入分支：检查该联系人上次发送消息距今多久，然后选择普通文本路径或消息模板路径。从一开始就这样做，几乎不会增加成本。事后补上，则意味着要找出代码库中的每个发送位置。 - 从您自己上次发送消息的时间开始计算。实际开启窗口的是客户的消息。 - 把窗口当成按号码计算。它是按联系人计算的，因此同一个号码上的两个对话可能处于不同状态。 - 只在消息发送后立即测试，因为这时总是在窗口内。 **窗口可以延长吗？** 不可以。窗口由 Meta 固定，任何提供商都无法延长。 **发送消息模板后，窗口会重新开启吗？** 客户回复会重新开启窗口。单独发送消息模板不会开启普通文本窗口。 **回复真的免费吗？** Meta 不会对客户服务窗口内发送的消息收费。它收取的是在窗口外开启的对话费用。 **我读到的另一个 24 小时窗口是什么？** 那是同步窗口，从完成入门设置时开始计算，用于管理聊天记录，而不是消息发送。两者没有关系。 --- ## WhatsApp 消息模板 https://easycoexistence.com/zh-hans/docs/message-templates 模板是预先提交给 Meta 审核的消息。获批后，您可以随时发送，包括发送给从未发过消息的人。它是唯一能在 24 小时客户服务窗口之外发送消息的方式。 ### 3 个类别分别有什么作用？ 它们告诉 Meta 这是什么类型的消息，而类别会同时影响审核和计费。 Utility 用于与客户操作相关的交易消息，例如订单更新、预订确认和配送通知。Marketing 用于推广内容，发送这类消息需要在 WhatsApp Business Account 中设置付款方式。Authentication 用于一次性代码，并有更严格的格式要求。 选错类别是常见的拒绝原因。Utility 模板中出现推广用语会被发现，而且发现得很一致，因此不值得尝试。 ### 变量如何运作？ 占位符按编号依次填入，并按组件分别计算。 正文 Hello {{1}}, your order {{2}} has shipped 定义了 2 个变量，因此发送正文时必须准确提供 2 个值。Header 和 button 参数分别计算，不会合并成一个列表，因此即使发送时提供的总数正确，仍可能被拒绝。 创建模板时，Meta 也要求提供示例值，让审核人员了解真实消息的样子。此外还有位置规则：变量位于消息最开头或最末尾，或相对于周围文字而言变量过多，都会被拒绝。 ### 为什么手机应用不能在 Coexistence 号码上发送这些模板？ 因为模板是平台功能，而不是应用功能，手机应用并不识别模板。 这是您早期需要了解的一点。通过 Coexistence 连接的企业，可以继续让团队使用手机回复，团队也能实时回复任何消息。但他们无法通过应用重新开启已经冷却的对话，因为这需要模板，而模板只能通过 API 使用。 因此，任何计划发送的消息、交易消息，或发给今天尚未发过消息的人的消息，按定义都必须通过 API 完成。对许多企业来说，这正是建立连接要解决的空缺。 - 在同一次操作中创建模板并发送。Meta 会先审核，通常需要几分钟，但有时会花一天。 - 合并计算 Header 和正文变量。它们按组件分别计算。 - 在 Utility 模板中使用 Marketing 用语。这是稳定且常见的拒绝原因。 **审核需要多长时间？** 通常几分钟，有时最长需要一天。没有任何服务商可以加快审核。 **模板是否按语言区分？** 是。名称和语言共同标识一个模板，因此同一名称的另一种语言版本是不同的模板。 **我可以编辑已获批的模板吗？** 可以，但编辑会改变变量契约，导致写死旧数量的发送方无法正常工作。 **我需要设置付款方式吗？** 发送 Marketing 消息时需要，并且要在您自己的 WhatsApp Business Account 中设置。Meta 要求这样做，没有任何服务商可以代您添加付款方式。 --- ## account_update Webhook 及所有断开原因 https://easycoexistence.com/zh-hans/docs/webhook-account-update account_update 用于报告连接状态变化。其 event 字段说明发生了什么；如果是移除，disconnection_info.reason 会说明原因。这个原因决定号码能否恢复，还是已经永久失效。 ### account_update 会携带哪些事件？ 应用从 WhatsApp Business 账户卸载时，会发送 PARTNER_REMOVED。这是权威的断开信号，值得据此构建逻辑，而不是根据某一字段变为 false 来推断断开。 号码完全退出时，会发送 ACCOUNT_OFFBOARDED。先前被移除的连接恢复时，会发送 ACCOUNT_RECONNECTED。强制执行相关事件包括 ACCOUNT_RESTRICTION 和 ACCOUNT_VIOLATION，也包括名称含有 DISABLED 或 BAN 的事件。 验证和审批结果也会在这里传递，event 名称会含有 VERIFIED 或 APPROVED。处理程序应根据 event 名称进行分支处理；无法识别的事件应视为信息，而不是因此失败，因为 Meta 可能随时添加事件。 ### 断开原因有哪些？ 共有 6 种，含义差异很大。 PRIMARY_INACTIVITY 是大约 14 天的规则：主要设备上的 WhatsApp Business 应用未被打开。可以恢复，而且是最常见的情况。 COMPANION_INACTIVITY 表示配套设备处于同类非活动状态，时限更长，约为 30 天。 BUSINESS_DOWNGRADE 表示号码切回消费者使用的 WhatsApp 应用。由于 Coexistence 需要 WhatsApp Business 应用，这会结束 Coexistence。 CHANGE_NUMBER 表示电话号码本身发生变化。USER_RE_REGISTERED 表示号码在新设备上重新注册。ACCOUNT_DISCONNECTED 表示客户主动断开连接，或连接因强制执行而被断开。 断开时还会同时传递 disconnection_info.initiated_by，用于说明操作是由人员还是系统发起。 ### 为什么原因比事件更重要？ 因为单独看到 PARTNER_REMOVED，并不能告诉您应该采取什么行动。 如果号码因 PRIMARY_INACTIVITY 被移除，它还会回来：企业打开应用并重新连接后，一切都会恢复。若把这种情况当成客户离开，就会向仍然是客户的人发送取消邮件。 因 BUSINESS_DOWNGRADE 或 ACCOUNT_DISCONNECTED 被移除，是另一种情况。若把它当成暂时断开，连接就可能永远停留在待处理状态。 如果移除事件完全没有原因，initiated_by 就是备用信号：人员执行的移除表示有意操作，而无法解释的系统移除则不能这样判断。与其之后通过支持对话处理，不如在代码中区分这两种情况。 - 把每一次 PARTNER_REMOVED 都当成同一种情况。原因可以区分 14 天的暂时沉寂与已经离开的客户。 - 根据字段变为 false 推断断开，而不是根据这一事件判断。这会产生误报。 - 遇到无法识别的 event 名称就失败。Meta 会添加事件，处理程序应跳过无法识别的事件。 **PARTNER_REMOVED 是永久的吗？** 通常不是。大多数事件会带有 PRIMARY_INACTIVITY，表示应用一段时间未打开；重新连接后，一切都会恢复。 **重新连接会恢复我的 Webhook 目标吗？** 不会，这正是容易忽略的地方。目标是应用订阅上的 override，应用卸载时它也会被卸载，因此必须重新应用。 **COMPANION_INACTIVITY 是什么？** 表示配套设备处于非活动状态，而不是主要设备；时限更长，约为 30 天。 **没有原因时，我还能收到这一事件吗？** 可以。这种情况下，disconnection_info.initiated_by 是唯一能判断操作是否出于意图的信号。 --- ## phone_number_quality_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-phone-number-quality-update phone_number_quality_update 会报告号码的吞吐量和消息发送限额变化。截至 2026 年，尽管名称如此，它并不携带绿色、黄色或红色质量评级。评级必须直接从电话号码读取。 ### 这个 Webhook 实际包含什么？ 它包含吞吐量和消息发送限额信息，以事件值和携带当前限额的字段传递。 实际内容是号码容量发生了变化：号码移至不同的消息发送层级，或吞吐量级别经过调整。记录这些变化很有用，因为它们会改变集成可执行的操作，而且层级下调通常是较早出现的信号。 尽管字段名称如此，其中并不包含质量评级。根据较早文档编写的处理程序会在此处查找 GREEN、YELLOW 或 RED，却什么也找不到，随后误以为质量从未变化。 ### 那么颜色评级从哪里读取？ 按计划直接读取电话号码。 quality_rating 字段位于 Graph API 的电话号码对象中，必须轮询，不能等待推送。这就是为什么要正确监控连接，除了 Webhook 接收器，还需要轮询程序：两者传递的内容不同，单独使用任何一个都不够。 这也是大多数集成无法发现质量下降的原因。系统不会推送这个变化，手机上的 WhatsApp Business 应用也不会显示任何迹象。等到它产生错误 131048 时，受影响的发送已经失败。 - 在此负载中查找 GREEN、YELLOW 或 RED。截至 2026 年，这些内容并不在其中。 - 只依靠 Webhook 构建监控。质量评级必须轮询。 - 忽略层级下调。它通常是问题最早可见的信号。 **为什么字段名称与质量有关？** 它在变化发生前就已存在。名称保留了下来，但内容已经改变，因此容易令人误解。 **应该多久轮询一次评级？** 频率应足以在下降演变为限额前发现问题。我们按计划轮询，而不是按需轮询。 **应用会显示评级吗？** 不会。手机上的 WhatsApp Business 应用不会显示任何相关信息。 **131048 有关吗？** 有关。低评级导致限额后，号码就会开始返回这个错误。 --- ## smb_message_echoes Webhook https://easycoexistence.com/zh-hans/docs/webhook-smb-message-echoes smb_message_echoes 会传送团队通过 WhatsApp Business 应用发出的消息。它只存在于 Coexistence 号码，因为只有这类号码同时允许人员通过手机发送，以及软件通过 API 发送。 ### 为什么会有这个字段？ 因为 Coexistence 会造成 API 原本没有设计来处理的情况：同一个号码有 2 个发送方。 在普通 Cloud API 号码上，软件是唯一的发送方，因此没有需要报告的内容。在 Coexistence 号码上，团队仍会通过手机回复。如果没有办法看到这些回复，软件就会对每段对话的近一半内容一无所知。 这个回显事件解决了问题。当有人在 WhatsApp Business 应用中输入回复时，该回复会作为一个事件到达您的端点。它的结构与收到的消息相同，但会标记为企业发出的消息。 ### 忽略它会造成什么问题？ 客户会收到 2 次回复，看起来很不专业。 通常的情况是，客户在早上 8 点提出问题，人员在 1 分钟内通过手机处理，而没有看到该回复的自动化流程在 3 分钟后又回答同一个问题。从客户角度看，这就像同一家企业不知道自己已经说过什么。 处理它并不复杂。像记录收到的消息一样，把回显事件记录到对话中，并在发送前检查最近的活动。这个问题之所以容易在测试中隐藏，是因为测试对话没有人员参与回复。 - 把回显事件当作噪音而丢弃。它是唯一能表明人员已经回复的信号。 - 以为每个号码都有这个字段。它只适用于 Coexistence。 - 测试时没有人员参与，而这正是问题不会出现的唯一情况。 **回显事件包含媒体吗？** 它会报告已发送的内容，包括媒体引用，结构与收到的消息相同。 **普通 Cloud API 号码上会有这个字段吗？** 不会。没有 Coexistence，就没有人员通过应用发送消息，因此也没有需要回显的内容。 **可以关闭它吗？** 它随消息路径提供。将该路径路由到您的端点就会包含它，而在代码中忽略它是一个需要承担后果的选择。 **需要付费吗？** 不需要。这是一个 Webhook 事件，不是发送消息。 --- ## messages Webhook https://easycoexistence.com/zh-hans/docs/webhook-messages messages 是承载客户发往您号码的所有内容的字段，包括文字、媒体、回复、反应和互动响应。对于路由 Coexistence 号码，消息从 Meta 直接发送到您的端点，完全不会经过服务商。 ### 负载包含哪些内容 单次交付可包含一条或多条消息，每条包含发件人、id 和 type。type 决定还会出现哪些其他键。 - 发件人的电话号码，以及其所发往号码的 phone_number_id。 - wamid 消息 id，去重机制以此为基础。 - unix 时间戳。 - type：text、image、audio、video、document、sticker、location、contacts、reaction、button 或 interactive。 - 对于媒体类型，负载包含用于获取媒体的 media id，而不是媒体字节本身。 ### 为什么路由号码上的消息永远不会到达本服务 override 会将此字段和 smb_message_echoes 一起移至您指定的目标。 Meta 允许应用覆盖 WhatsApp Business Account 交付其 Webhook 的位置。本服务将 override 指向您的 URL，使消息路径完全离开本服务基础设施。本服务端不会产生副本、队列或保留内容，因为消息从未到达这里。 未指定目标时，这些事件会回退到本服务的默认回调，处理程序会丢弃它们，不作持久化。存储声明和实际代码路径并不是一回事：对话内容没有路径可去。 ### 如何正确确认 在执行工作前返回 200，不要等工作完成后才返回。 Meta 将缓慢响应视为失败并重试，因此内联处理的处理程序可能多次看到同一消息。立即响应，将负载放入队列或后台任务，让工作在请求之外完成。 在无服务器环境中，必须如此。函数返回后继续工作，响应完成瞬间可能被冻结，因此确认和处理必须真正分开。 ### 如何去重 始终基于 wamid 去重，因为重试是常态，不是例外。 同一消息可能因您一侧没有问题的原因到达两次：响应缓慢、网络超时，或部署在交付期间上线。保存已见 id 并跳过重复项只需几行代码，结果是客户只收到一次回复，而不是两次。 在 Coexistence 号码上，去重更加重要，因为 smb_message_echoes 也沿同一路径到达。将每个事件视为新事件的处理程序，可能在人工回复之上再次回复。 - 在返回 200 前处理消息。Meta 会因响应缓慢而重试，导致您处理同一消息两次。 - 跳过去重。重试是设计的一部分，不是边缘情况。 - 期待负载中包含媒体字节。负载只包含用于获取媒体的 media id。 **EasyCoexistence 能看到我的客户消息吗？** 不会。override 将此字段交付到您的端点。任何到达本服务默认回调的内容都会被丢弃，不会持久化。 **单次请求中可以到达多条消息吗？** 可以。单次交付可包含多条消息，因此处理程序需要遍历，而不是只读取第一条。 **如何获取媒体？** 负载包含 media id。使用号码的访问令牌，通过它获取 URL，然后下载。 **smb_message_echoes 是什么？** 配套字段，承载团队从 WhatsApp Business 应用发出的内容。它只存在于 Coexistence 号码。 --- ## phone_number_name_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-phone-number-name-update phone_number_name_update 记录显示名称提交的结果。其 decision 字段说明 Meta 是否批准或拒绝该名称，而这一事件是唯一报告该结果的地方：WhatsApp Business 应用中不会显示任何相关信息。 ### 它报告什么 显示名称提交的结果，以事件中的决定形式记录。名称是客户在对话上方看到的内容，修改名称后需要经过 Meta 审核。 值得订阅此事件的原因是，没有其他地方会说明结果。WhatsApp Business 应用不会显示任何信息，而几周前提交过修改的企业，除非有人接收此事件，否则无法知道修改是否通过。 将它记录在时间线上，可以把“我们的名称是否修改成功”从支持对话变成有日期的事实。 ### 名称为什么会被拒绝 主要原因是名称与账户通过验证的企业不对应。 - 与法定实体、注册商号或网站品牌一致的名称通常会通过。 - 通用描述，或与已验证企业无关的名称，通常不会通过。 - 任何看起来像关键词而不是名称的内容，通常都会被稳定识别。 ### 缺少名称会阻止什么 某些发送操作会被阻止，这也是大多数人发现名称从未获批的方式。 没有获批显示名称的号码，在需要显示名称的操作中会返回错误 131037。对触发该错误的人来说，这看起来像代码故障，因为号码的其他功能都正常，而问题通常可以追溯到试用连接：名称步骤被跳过后，再也没有处理。 提交名称是正确设置号码的一部分，并非装饰性步骤。号码连接当天就完成这项操作，通常更稳妥。 - 以为没有消息就代表已批准。决定只会在这里到达，其他地方不会显示。 - 提交关键词而不是名称。Meta 会将其与已验证企业进行核对。 - 试用期间跳过显示名称，之后在需要名称的发送操作中遇到 131037。 **审核需要多长时间？** Meta 没有公布固定期限，任何服务提供商都无法加快审核。 **之后可以更改名称吗？** 可以，每次更改都需要再次审核，并在这里产生另一个事件。 **客户也会看到我的号码吗？** 客户会看到获批的显示名称，这正是设置名称的意义。 **什么是错误 131037？** 号码没有获批显示名称，却尝试执行需要该名称的操作时返回的错误。 --- ## message_template_status_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-message-template-status-update message_template_status_update 报告模板审核状态的变化：已批准、已拒绝、已暂停或已停用。集成可以提交模板，然后等待结果，而不必按固定间隔轮询 Meta，也不必猜测查询频率。 ### 它包含哪些状态 模板会经历一小组状态，每次变化都会在这里送达。 - 已批准：从此可以发送该模板。 - 已拒绝：无法发送，事件会附带原因。 - 已暂停：质量下降到一定程度，Meta 暂时将其暂停。 - 已停用：多次暂停后永久停止，需要新建模板。 ### 为何无需轮询 因为另一种做法是反复查询，并猜测查询频率。 没有此事件时，创建模板的集成必须按固定间隔轮询 get_template_status，直到结果变化。查询太频繁会浪费资源，太少则可能让已批准的模板等上 1 小时才被发现。 有了它，流程就是提交并等待。Meta 通常会在几分钟内推送结果，集成只需响应一次。对替客户创建模板的代理机构来说，这就是队列能自行清空，还是必须有人盯着的区别。 ### 每种结果该怎么处理 已批准最简单：标记为可发送。其他 3 种状态才是它的价值所在。 已拒绝会附带原因，最好原样显示，而不是概括说明，因为原因通常具体到可以直接处理，改写后反而会丢失细节。 已暂停表示内容引发了不良反馈，暂停解除后再次发送同样内容仍会得到相同结果。这是在提示您编辑内容，而不是等待。 已停用对该模板来说是最终状态。唯一的解决办法是用不同内容新建模板。把它当成临时状态，只会让发送流程一直中断。 - 该事件已经报告批准结果，却仍然轮询。 - 概括拒绝原因，而不是直接显示。具体细节才便于处理。 - 等待已停用的模板恢复。该状态是永久的，需要新建模板。 **批准通常需要多久？** 通常只需几分钟，有时最长 1 天。任何服务商都无法加快这个过程。 **已暂停的模板和已停用的模板相同吗？** 不相同。暂停会在一段时间后解除，停用则是永久状态，且通常发生在多次暂停之后。 **拒绝结果会说明原因吗？** 会，而且原因通常具体到可以直接处理，所以值得原样传递。 **一个模板暂停时，我还能发送其他模板吗？** 可以。该状态只影响这个模板，不影响号码。 --- ## message_template_quality_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-message-template-quality-update message_template_quality_update 会报告收件人对某个消息模板的反应发生变化。它会在质量问题导致暂停前到达，因此您有时间采取行动，而不是等发送失败后才解释原因。 ### 它衡量什么 它衡量人们如何回应使用某个消息模板发送的消息，而不是衡量整个号码。屏蔽和举报的权重最高，完全没有互动也会产生影响。 这种按模板划分的范围正是它有用的原因。一个号码整体状态良好，但某个模板可能在悄悄影响自己的受众，而这个事件能将两者区分开来。没有它，您收到的第一个信号可能是该模板发送失败，而号码上的其他功能仍正常运作。 ### 为什么尽早采取行动是重点 因为从这一步开始，每一种状态都会更糟，也更难恢复。 质量下降到一定程度后，模板会被暂停，每次尝试都会返回错误 132015。只有经过一段 Meta 没有公布时长的时间后，发送才会恢复。反复暂停会永久停用模板，届时必须以新名称重新创建模板。 当模板仍能发送时收到质量信号，是唯一可以零成本编辑的时机。模板暂停后，编辑仍然是正确做法，但发送路径已经中断，只是没人知道中断了多久。 ### 通常是什么原因导致 先是内容，其次是受众，而后者最容易被忽略。 - 在声明为实用类的模板中加入推广用语，收件人对此没有预期。 - 消息没有清楚说明是哪个企业在发消息。 - 向名单发送消息，而不是发送给近期有互动的人。 - 向从未要求接收消息的受众大量发送同一个模板。 - 把它当作提示信息。它是模板仍能运作时到达的最后一个信号。 - 把它理解为号码出现问题。它的范围限于单个模板。 - 只编辑措辞，却保留相同受众。发送对象和消息内容一样，会产生相同信号。 **这会影响我的其他模板吗？** 不会。该信号的范围限于单个模板，同一个号码上的其他模板不受影响。 **我可以在应用中看到这个吗？** 不可以。手机上的 WhatsApp Business 应用不会显示任何消息模板质量信息。 **如果我忽略它，会发生什么？** 质量继续下降会暂停模板，反复暂停则会永久停用模板。 **只编辑措辞就够了吗？** 通常够，但不一定。模板发送给谁，和模板写了什么一样，会产生相同信号。 --- ## history Webhook https://easycoexistence.com/zh-hans/docs/webhook-history history 负责将 Coexistence 号码现有对话一次性传输至 API。它会在完成入驻且接受共享历史记录后送达，也是集成确认传输确实发生的唯一信号。 ### 它会传送什么 它会传送号码在 WhatsApp Business 应用中已有的一对一消息记录，让软件接入企业使用多年的号码时不会从空白开始。 群组对话不会随之传送，因为 Coexistence 号码上的群组对话完全不包含在 API 中。应用本身的工具也不会传送：标签、快捷回复、问候语和离开消息没有对应的 API 功能，仍保留在设备上。 此字段仅存在于 Coexistence 号码。以普通方式完成入驻的号码没有既有应用历史记录可传送，因此没有内容可交付。 ### 为什么只触发一次 因为这项传输属于入驻流程，而不是持续提供的功能。 企业所有者会在 Embedded Signup 中被询问是否共享现有对话。选择是，才会允许同步运行；之后没有设置可以重新开启，也没有端点可以重复执行。第二次尝试会返回 2593107，而不是等待一段时间后就会清除的速率限制。 此外还有截止时间。同步必须在入驻后 24 小时内开始，之后尝试会返回 2593108。错过任一条件，都必须断开号码并重新完成整个流程。 ### 处理程序应如何处理它 将它视为一次送达且可能很大的批次，而不是消息路径上的额外流量。 - 快速确认并异步处理，与其他送达一样。 - 按 message id 去重：入驻前后，history 与实时消息可能会重叠。 - 要预期它可能不存在。所有者拒绝历史记录的号码不会在此发送内容，集成必须在两种情况下都能运行。 - 不要让入驻流程等待它完成。传输完成前，连接已经可以使用。 - 构建必须依赖历史记录的集成。许多号码连接时并没有历史记录。 - 在 2593107 后重试同步。它是一次性事件，因此重试会返回相同错误。 - 等到集成工作开始后才决定是否传输历史记录，而那通常已经超过 24 小时期限。 **会传送多少历史记录？** 一段近期一对一对话记录，范围由 Meta 决定，而不是由服务提供商决定。 **群组聊天会传过来吗？** 不会。Coexistence 号码上的群组对话完全不包含在 API 中。 **之后可以再次请求吗？** 不可以。每次入驻只运行一次，再次运行必须先断开并重新连接号码。 **如果所有者拒绝传输历史记录，会怎样？** 此字段不会送达任何内容，API 只能看到号码连接后产生的消息。 --- ## smb_app_state_sync Webhook https://easycoexistence.com/zh-hans/docs/webhook-smb-app-state-sync smb_app_state_sync 携带 WhatsApp Business 应用本身的状态，主要是 Coexistence 号码连接时进行的联系人同步。它与携带对话的 history 分开，并且只存在于 Coexistence 号码上。 ### 它携带什么 应用侧状态，实际指的是企业原本保存在手机上的联系人。 每个拥有 WhatsApp 号码的联系人都可以同步到平台。这样，软件就能识别多年来一直保存在企业手机中的客户，而不会把对方当成新号码。这与对话本身不同，对话会到达 history 字段。两者分开，是因为一个是目录，另一个是对话记录。 与 history 一样，此字段只存在于 Coexistence 上。从未使用过该应用的号码没有应用状态可供同步。 ### 它不携带什么 应用自己的工作工具，这些内容在平台侧没有对应表示。 - 标签保存在设备上，软件无法读取。 - 快捷回复、问候语和离开消息。 - 目录、订单和状态。 - 频道，以及语音或视频通话记录。 ### 这对集成为何重要 因为它决定您的系统从第一天起是否知道是谁在发消息。 没有联系人同步时，每条入站消息都会以没有姓名的电话号码到达，将其匹配到客户记录就成了您的问题。有了同步，企业自己的联系人列表就可用，大部分匹配工作也已完成。 同时为两种情况做好规划是值得的，因为企业可能拒绝同步或错过时间窗口。如果集成假设联系人一定存在，打开它的人就会看到一整面原始号码。 - 假设联系人一定会存在。企业可能拒绝同步或错过时间窗口。 - 期待此负载中包含标签或快捷回复。它们保留在设备上。 - 把它与 history 混淆。history 携带的是对话，而不是联系人列表。 **这是与 history 同步相同的东西吗？** 不是。此字段携带应用状态，主要是联系人。history 携带对话。 **它会运行多次吗？** 初始同步是接入流程中的一次性步骤，与 history 一样有 24 小时时间窗口。 **我会获得标签吗？** 不会。标签是应用功能，没有对应的 API。 **普通 Cloud API 号码上也存在此字段吗？** 不会。普通 Cloud API 号码没有 WhatsApp Business 应用状态可供同步。 --- ## template_category_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-template-category-update template_category_update 表示 Meta 已重新分类某个模板，将其从 utility、marketing 或 authentication 之一移至另一类。这很重要，因为分类决定 Meta 对每次对话的收费，所以重新分类会在无人编辑任何内容的情况下改变您的成本。 ### 为什么分类会自行更改 因为 Meta 会审核模板的实际内容，而不只看您申报的分类。 申报为 utility、但包含优惠内容的模板，是用较低价格的标签包装促销内容。有时它会在审核时被发现并拒绝。有时它会先获批准，待内容投入使用后才被重新分类，而本事件报告的就是后一种情况。 这不是由您这边触发的。模板没有改变，代码没有改变，而如果没有这个事件，您最先发现的可能是一张与预估不符的账单。 ### 它会改变什么 从那时起，该模板开启的每次对话的价格都会改变。 - Meta 对 utility、marketing 和 authentication 对话采用不同定价。 - 营销消息发送还要求 WhatsApp Business 账户设有付款方式。 - 如果账户没有付款方式，模板被重新分类为 marketing 后会开始返回 131042。 - 模板本身仍可正常使用，改变的是费用和所需条件。 ### 如何避免被重新分类 如实申报，比刻意优化分类更省钱。 utility 模板描述客户已经做过的事情，例如订单、预订或配送。如果没有客户采取的某项行动，消息就不会存在，那么它属于 utility。如果消息存在是因为您想销售某种产品或服务，那么它属于 marketing。按实际情况申报，成本低于在您无法选择的时间被重新分类。 反复提交分类错误的模板，也会引起对账户本身的注意。这比为营销消息支付 marketing 费率更不利。 - 为少付费用而将促销内容申报为 utility，之后会在更不合适的时间被重新分类。 - 忽略此事件，它会在您无法控制任何内容改变的情况下影响计费。 - 以为批准就是最终结果，模板获批准后仍可能被重新分类。 **模板会停止使用吗？** 不会。它仍会继续发送，改变的是对话价格，以及营销消息所需的付款方式。 **我可以申诉重新分类吗？** Meta 通过自己的渠道处理分类争议，任何服务商都无法更改分类。 **哪个分类最便宜？** Meta 会按市场采用不同定价。最便宜的正确分类，是最如实描述消息内容的分类。 **什么是 131063？** 表示账户上的营销模板已被停用，这与没有付款方式是两种不同情况。 --- ## Meta Business Portfolio 及其包含的内容 https://easycoexistence.com/zh-hans/docs/meta-business-portfolio Business Portfolio 是 Meta Business Manager 中的公司级容器。它保存 WhatsApp Business 账户，而这些账户保存电话号码。客户连接号码时，号码会留在客户的 Business Portfolio 中，不会移到提供商的 Portfolio。 ### 这些层级如何衔接？ 共有 3 个层级，把它们都称为账户，是大多数混乱的起点。 Business Portfolio 位于顶层，代表 Meta Business Manager 中的公司。它保存各种资产，包括广告账户、主页和 WhatsApp Business 账户。WhatsApp Business 账户内有电话号码，每一号码都有自己的 phone number id、质量评级和消息层级。 所以，“检查账户是否正常”这句话，根据说话者的不同，可能指 4 种检查。出现问题时，准确说明您指的是哪一层，能节省大部分诊断时间。 ### 为什么号码由哪一 Portfolio 保存很重要？ 因为这决定谁真正控制该连接。 通过 Tech Provider 自有应用进行入驻时，号码会连接到客户的 Portfolio，并授权提供商的应用代表客户操作。客户和 Meta 的关系归客户所有，对话费用会从客户的付款方式扣除，客户也可以撤销访问权限。 如果工具建立在其他人的提供商账户上，号码的关联方式会不同。通用自动化平台上的限制，往往来自这种共享关系。对代理机构来说，这正是每一位认真经营的客户最终都会提出的问题。 - 混用 Portfolio 和 WABA。前者保存后者，两者出问题时的表现不同。 - 把客户号码连接到自己的 Portfolio 下。这样连接归您所有，而不是客户所有。 - 以为业务验证属于号码。实际上它属于 Portfolio 层级。 **Portfolio 是否等同于 WhatsApp Business 账户？** 不是。Portfolio 是公司的容器，WABA 位于其中并保存电话号码。 **一个 Portfolio 可以保存多个 WABA 吗？** 可以。客户为不同品牌设置独立账户时，代理机构经常会看到这种情况。 **谁可以授予 Portfolio 的访问权限？** 该 Portfolio 的管理员通常可以授予权限。管理员通常是企业所有者，而不是负责集成的人。 **连接会移动我的号码吗？** 不会。号码会留在您的 Portfolio 中，并授权提供商的应用代表您操作。 --- ## WhatsApp Business 账户，以及为什么覆盖设置属于账户 https://easycoexistence.com/zh-hans/docs/whatsapp-business-account WhatsApp Business 账户包含号码和模板。它的重要性超出表面，因为 Webhook 路由按账户应用，而不是按号码应用，所以移除连接时，路由也会一并移除。 ### WABA 实际包含什么？ 号码和模板，这种组合的重要性比初看更高。 模板属于账户，而不是号码，因此同一 WABA 上的每个号码都共享同一个模板库。创建一个订单更新模板后，所有号码都可以发送。Meta 对账户模板数量设定上限，对于在同一账户管理多个品牌的代理机构来说，这可能成为限制。 每个号码都有自己的 phone_number_id、显示名称、质量评级和消息层级。这些信息按号码区分，因此一个号码的状态可能下降，而同一账户中的另一个号码仍然正常。 ### 为什么 Webhook 覆盖设置属于这一层？ 因为它修改的是应用订阅账户的关系，而不是应用订阅某个号码的关系。 设置目标后，实际发生的是：系统将 override_callback_uri 应用于我们的应用与该 WABA 之间的订阅。账户中的每个号码都会将自己的消息路径事件发送到那里。不存在按号码分别路由的设置，这常让管理同一客户多个号码的人感到意外。 真正需要规划的是后果。当连接因 14 天不活跃规则或其他原因被移除时，应用会从账户卸载，覆盖设置也会随之卸载。重新连接后，发送和监控会恢复。除非有其他机制重新设置覆盖，否则消息不会再发送到您自己的服务器。 - 期待按号码配置 Webhook 路由。覆盖设置按账户应用。 - 以为重新连接会恢复目标地址。覆盖设置会随应用卸载，必须重新应用。 - 忘记模板是共享的。账户中的每个号码都能看到同一个模板库。 **同一 WABA 上的两个号码可以路由到不同端点吗？** 不可以。覆盖设置应用于账户，因此所有号码都会将消息发送到同一个目标。 **模板可以在账户之间转移吗？** 不可以。模板属于创建它的账户。 **移除号码后，覆盖设置会怎样？** 如果应用从账户卸载，覆盖设置也会随之移除。重新连接会恢复发送，但不会恢复目标地址。 **模板有数量限制吗？** Meta 按账户限制模板数量，超过上限会返回专用错误。 --- ## WhatsApp 号码的两步验证 https://easycoexistence.com/zh-hans/docs/two-step-verification 两步验证是设置在 WhatsApp Business 电话号码上的 PIN。某些操作需要输入它。由于它通常在注册时设置一次，此后不再使用，最常见的问题就是企业内没人记得这个 PIN。 ### 什么时候才真正需要 PIN？ 在号码注册和重新注册期间，以及 Meta 保护的某些账户操作中需要。 这意味着大多数企业会在注册时设置它，此后再也不会看到它，这正是它后来变成问题的原因。设置 PIN 的人离开了原岗位，PIN 从未记录在任何地方，而 18 个月后又在某项操作已经出问题的关键时刻被需要。 相关错误足够具体，可以据此诊断。PIN 不正确时返回 133005。尝试次数过多时返回 133008，并会在一段时间内锁定后续尝试，具体时间会在响应中说明。提交尝试过于频繁时返回 133009，这是速率限制，而不是答案错误。 ### PIN 丢失后该怎么办？ 在 WhatsApp Manager 的号码设置中重置，但您必须能够访问拥有该号码的账户。 这是企业所有者的操作，而不是服务提供商的操作。任何 API 都无法读取或重置 PIN，任何服务提供商也不会持有它。这样设计是有原因的：如果服务提供商可以找回某项凭据，它就不能算作第二重验证因素。 实际做法是，把 PIN 记录在企业自己可以找回的地方，而不是只交给代理机构。若 PIN 只存放在代理机构的密码管理器中，换一次客户关系后，企业仍会遇到完全相同的问题。 - PIN 错误后快速重试。这样会返回 133009，并延迟下一次有效尝试。 - 只在代理机构一方保存 PIN。企业必须能够自行找回它。 - 以为服务提供商可以恢复 PIN。没有人持有它，这正是它存在的意义。 **您可以重置我的 PIN 吗？** 不能。PIN 设置在 Meta 自己的号码设置中，任何服务提供商都无法读取或更改它。 **锁定会持续多久？** Meta 会在 133008 的错误响应中说明等待时间，而不是使用固定时长。 **PIN 是按号码还是按账户设置的？** 按电话号码设置。 **这和企业验证是同一回事吗？** 不是。验证针对 Business Portfolio 层级的法律实体，而 PIN 设置在号码上。 --- ## account_review_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-account-review-update account_review_update 携带 Meta 对企业账户审核的结果。其 decision 字段说明审核决定；拒绝应视为连接状态下降，而不是普通信息，因为之后发送通常会继续受影响。 ### 审核什么时候发生？ 当 Meta 检查企业账户时，审核可能发生在提交验证资料、提出申诉，或消息行为触发自动标记之后。 服务提供商无法触发审核，也看不到审核过程本身。收到的是带有 decision 的事件，也就是审核结果。批准通常不需要处理。拒绝才值得采取行动，因为它往往先于限制发生，而不是代表事情已经结束。 审核不会在 WhatsApp Business 应用中显示，因此企业可能正在审核中、被拒绝，仍能通过手机回复客户，却完全不知道发生过任何变化。 ### 为什么应将拒绝视为连接状态下降，而不是普通消息？ 因为它通常是多个事件中的第一个，而不是最后一个。 审核被拒绝，表示 Meta 检查过账户，但认为账户不符合要求。之后通常会出现限制，导致发送完全停止，并以带有 enforcement 事件的 account_update 到达。在拒绝发生时将连接标记为状态下降，可以让负责监控的人更早开始与客户沟通。 如果将其记录为普通信息，通常要等到发送开始失败才会有人采取行动。那时企业已经无法联系客户，讨论也会从危机开始，而不是从预警开始。 - 记录拒绝却不改变状态。它是领先指标，不是脚注。 - 期待在此事件中看到原因。它携带决定，详情位于 Business Manager。 - 假设企业会自行注意到。审核不会在手机上显示。 **服务提供商能看到审核失败的原因吗？** 不能。执行通知及其原因位于企业账户的 Business Manager 中。 **拒绝总会导致限制吗？** 不一定，但发生的可能性足够高，因此默认将其视为预警是正确做法。 **谁可以提出申诉？** 拥有企业账户管理员访问权限的人员。服务提供商不能代表他们提出申诉。 **这与模板审核相同吗？** 不相同。模板审核结果会单独到达，而且针对的是单个模板，而不是账户。 --- ## business_capability_update Webhook https://easycoexistence.com/zh-hans/docs/webhook-business-capability-update business_capability_update 报告账户可执行操作的变化，最实用的是消息限制。它携带当前限制值，也就是您每天可以主动发起对话的不同客户数。该限制会向上或向下调整。 ### 消息限制实际限制的是什么？ 您在滚动一天内可以主动发起对话的不同客户数。不是您可以发送的消息数量，也不是发送速度。 这一区别最容易造成问题。吞吐量是按秒计算的速率，超过后会返回 130429。消息层级是新对话的每日数量，超过它是另一种情况。某个号码可能远未达到层级，却仍受到速率限制，也可能反过来。 在客户服务窗口开放期间发送回复不会消耗层级，因为这些回复没有发起对话。真正消耗层级的是联系尚未发过消息的人。 ### 为什么层级会下调？ 因为层级取决于质量，而质量取决于收件人的反应。 如果收件人封锁或举报某个号码发送的消息，该号码的评级会下降，层级也可能随之调整。因此，下调是一个有用的早期信号：它通常会在任何功能停止前到达，让您还有时间改变发送的内容和对象。 上调会更慢，需要持续获得良好反馈。无论上调还是下调，Meta 都不会在企业能看到的地方发布通知，所以记录此事件，而不是只在失败后处理，值得投入这点小小的工作。 - 把层级与吞吐量混为一谈。前者是每日对话数，后者是每秒消息数。 - 把回复计入层级。开放窗口内的消息不会发起对话。 - 忽略层级下调。它会在任何功能出问题前到达，这正是它的价值。 **如何提高我的层级？** 它会根据一段时间内的质量自动变化，而不是通过申请提高。向希望接收消息的人发送合适的内容，才是有效方式。 **发送消息模板一定会消耗层级吗？** 会发起对话的消息模板会消耗层级。在开放窗口内发送的消息模板不会。 **messaging_limit_update 有什么不同？** Meta 会用这两个名称表示相关变化。我们的处理程序将它们视为相同事件，因为有用内容相同。 **这适用于 Coexistence 号码吗？** 适用。Coexistence 固定的是吞吐量，而不是消息层级。 --- ## account_alerts Webhook https://easycoexistence.com/zh-hans/docs/webhook-account-alerts account_alerts 是 Meta 用于提示业务账户相关事项的通用通道。与其他事件不同，它不携带需要应用的状态，因此它提示您查看，而不是让系统自动采取行动。 ### 此通道会收到什么？ 凡是 Meta 认为值得标记的账户事项，都可能出现在这里。内容范围本来就没有固定边界，而且一直在扩展。 由于内容不是固定集合，按特定警报类型编写的处理程序会漏掉新类型。持久可靠的做法是记录警报，将其关联到账户，并呈现给人工查看，而不是把每种警报映射为自动响应。 这是唯一一个诚实的处理方式是留意，而不是作出判断的运营事件。我们的处理程序会记录警报已到达，但不会尝试从中推断状态。 ### 它应如何纳入监控？ 把它作为时间线上的标记，放在那些确实携带状态的事件旁边。 价值在于事件顺序。一个警报先到达，随后出现审核被拒和限制，这个顺序讲述的故事，不是其中任何一个事件单独能够说明的。把它们记录在同一条时间线上，才能看清这一点，也才能让您与客户的对话从猜测变成具体日期和事件。 它不应触发任何操作。警报不是断开连接，不是质量下降，也不是限制。把它当作其中任何一种情况，都会产生误报，让人们开始忽略真正的警报。 - 按特定警报类型切换处理逻辑。集合会扩展，围绕今天的列表编写的处理程序会逐渐失效。 - 根据警报触发自动化。它不携带状态，因此任何推断都只是猜测。 - 因为它不可直接操作就丢弃。它的价值在于与其他事件形成的顺序。 **为什么它不会改变我的连接状态？** 因为它没有说明发生了什么变化。根据它推断状态会产生误报。 **在哪里可以查看详情？** 在业务账户的 Business Manager 中。此事件提示您到那里查看。 **它很少出现吗？** 它不是日常事件，因此出现时更值得呈现出来。 **这是否意味着出现了问题？** 不一定。这表示 Meta 提出了某个事项，值得人工查看，而不是自动响应。 --- ## WhatsApp Business 号码的显示名称 https://easycoexistence.com/zh-hans/docs/display-names 显示名称是客户与您的号码对话时，在对话上方看到的名称。更改名称需要 Meta 审核，结果会通过 phone_number_name_update Webhook 到达。遭拒通常是因为名称与企业不匹配。 ### Meta 检查什么？ 主要检查名称是否对应账户验证的企业。 与法律实体、注册商号相符的名称，或客户能从网站认出的品牌名称，通常较容易通过。通用描述、与已验证企业无关的名称，或看起来像关键词而不是名称的内容，通常难以通过。 没有获批显示名称的号码，可执行的操作会受到限制，在某些发送请求中还会返回专用错误。有人在试用期间快速连接号码，却没有完成名称设置，之后发现某类发送失败、其他发送正常，通常就是这种情况。 ### 结果如何到达？ 结果会通过 phone_number_name_update Webhook 到达，其中包含 decision 字段。 这是连接订阅的 6 个运营字段之一，也是判断已提交名称是否完成处理的唯一信号。WhatsApp Business 应用不会显示该结果。企业提交名称更改数周后，如果没有人接收该事件，就无法知道结果。 将结果记录在连接时间线上，就能把“我们的名称更改成功了吗”变成一个有日期可查的答案，而不是靠猜测。这类问题否则很容易变成支持请求。 - 提交关键词而不是名称。Meta 会将其与已验证企业核对，而不是与搜索量核对。 - 以为没有消息就代表已批准。结果会作为 Webhook 到达，其他地方不会显示。 - 试用期间跳过显示名称设置，之后在需要显示名称的发送请求中遇到 131037。 **审核需要多长时间？** Meta 没有公布固定期限，任何服务提供商都无法加快审核。 **之后可以更改吗？** 可以，每次更改都要再次审核。 **什么是错误 131037？** 当号码没有获批显示名称，却尝试执行需要显示名称的操作时返回的错误。 **客户也能看到我的号码吗？** 显示名称获批后，客户会看到该名称，这正是设置显示名称的作用。 --- ## 模板类别：实用、营销和身份验证 https://easycoexistence.com/zh-hans/docs/template-categories 每份模板创建时都必须声明类别。Utility 适用于与客户操作相关的交易消息；Marketing 适用于促销消息，并要求账户设有付款方式；Authentication 适用于一次性验证码，并须遵守更严格的格式规则。 ### 每个类别适用于什么？ Utility 属于交易类消息，与客户采取的操作有关，例如订单确认、配送更新、预订提醒或预约变更。判断标准是：客户是否会因为自己采取过某项操作而预期收到这则消息。 Marketing 包括所有促销内容，例如优惠、新产品、重新激活消息或新闻通讯。发送这类消息时，WhatsApp Business Account 必须设有付款方式。因此，账户过去只回复客户，从未发送营销消息时，第一次营销发送通常会失败。 Authentication 用于一次性验证码和验证。它的格式限制最严格，对验证码前后可以放置的内容有明确限制。它独立成类，是因为客户对这类消息的接收预期不同。 ### 为什么不能把所有消息都声明为 Utility？ 因为 Meta 会重新分类，而被重新分类的成本高于如实声明。 Utility 模板中的促销内容通常会被识别。模板可能在审核时被拒，也可能先获批准，之后才被重新归类。届时，原本按 Utility 计费的发送会在无人修改的情况下改按 Marketing 计费。这不是节省，而是账单上的意外费用。 反复提交分类错误的模板，也会引起对账户本身的关注。更省钱的做法，是按消息的实际性质声明类别。这样审核也更快，因为审核人员检查的正是模板所声明的内容。 - 把优惠放进 Utility 模板。这通常会被识别，也可能在批准后被重新分类。 - 账户没有付款方式却尝试发送营销消息。Meta 要求账户设有付款方式，任何服务商都无法替您添加。 - 把 Authentication 用于验证码以外的内容。格式限制很严格，因此无法通过审核。 **谁支付营销消息的费用？** Meta 会从您自己的 WhatsApp Business Account 付款方式中扣费，不会通过我们收取。 **模板可以更改类别吗？** 如果内容与原先声明的类别不符，Meta 可以在批准后重新分类。 **Utility 是免费的吗？** Utility 对话由 Meta 定价，与客户服务窗口内的免费回复并不相同。 **什么是错误 131063？** 这表示账户上的营销模板已被停用，与账户没有付款方式是两回事。 --- ## 号码停止工作：如何找出原因 https://easycoexistence.com/zh-hans/docs/troubleshooting-a-connection 已连接号码停止工作时，原因几乎从来不是代码。请按发生频率依次排查：访问令牌过期、重新连接后丢失 Webhook 覆盖设置、14 天不活跃导致断开连接、质量下降，最后是账户限制。 ### 为什么手机上看不出任何问题？ 因为 WhatsApp Business 应用和 API 是同一个号码上的两个独立界面，几乎所有故障只会影响其中一个。 访问令牌过期，但应用不受影响。Webhook 覆盖设置被卸载，但应用不受影响。质量下降，但应用不受影响。每种情况下，企业仍能回复客户，看到正常行为，也没有理由报告问题。 这正是应该进行监控，而不是依赖有人查看控制台的原因。故障确实存在，却没有明显提示，而最接近该号码的人反而最不容易注意到。 ### 应该按什么顺序检查？ 先检查访问令牌，因为这是最常见、修复成本最低的问题。过期或失效的凭据会让每次请求以相同方式失败，看起来就像号码已被移除。针对同一账户保留第二个凭据，才能区分这两种情况。 然后检查 Webhook 覆盖设置。如果发生过重新连接，目标设置会随应用一起被卸载，因此发送和监控仍然有效，但消息不会显示任何提示地无法送达您的服务器。 然后检查断开连接：account_update 事件会带有 PARTNER_REMOVED 和原因；其中 PRIMARY_INACTIVITY 表示应用大约 14 天未被打开，重新连接即可修复。 接着检查质量。质量是通过轮询获取，而不是主动推送。最后检查限制，这是提供商无法解除的账户级强制措施。 ### 几乎从来不是什么原因？ 如果代码昨天还正常运行，而且没有部署，那么通常不是您的代码。 Cloud API 很稳定，请求格式不会在您毫不知情的情况下改变。当运行数月的集成突然停止时，最可能的原因是凭据、路由变化或账户级事件，这些都可能在无人修改代码库的情况下发生。 唯一值得特别提到的例外，是有人编辑了模板。改变模板中的变量数量，会悄悄改变每个发送方所使用的约定，看起来像代码故障，但其实是其他人在 WhatsApp Manager 中修改了内容。 - 先重新连接号码。如果是访问令牌过期，这会让企业负责人进行完全不必要的操作。 - 认定是代码出错。API 稳定且没有部署，问题通常在其他地方。 - 检查手机上的症状。几乎所有这些故障发生时，应用仍可正常工作。 **号码在手机上能用，但什么都发不出去。我该从哪里开始？** 先检查访问令牌。这是最常见的原因，也最像号码已被移除。 **我重新连接了，但消息仍未送达服务器。** Webhook 覆盖设置随应用一起被卸载了。必须重新应用，我们会自动处理。 **如何知道是不是 14 天规则导致的？** 断开连接会在 account_update 事件中带有原因 PRIMARY_INACTIVITY。 **编辑模板会导致消息发送失败吗？** 会，而且这是最像代码故障的原因。改变变量数量会改变每个发送方使用的约定。 --- ## Meta 对哪些 WhatsApp 消息收费 https://easycoexistence.com/zh-hans/docs/free-and-paid-conversations Meta 按已送达的消息收费，而不是按对话收费。自 2026 年 10 月 1 日起，每个商业电话号码每月有 1,000 条免费服务消息，即在 24 小时客户服务窗口内发送的回复，从第 1,001 条起 Meta 开始收费。消息模板按送达计费，实用类模板也不例外。这些费用会计入您自己的 WhatsApp Business 账户所绑定的付款方式。 ### 究竟哪些是免费的？ 每个商业电话号码每月最多 1,000 条服务消息。服务消息是指任何非模板消息，只能在客户服务窗口开启期间发送，也就是客户最后一次给您发消息后的 24 小时内。每月从第 1,001 条起，Meta 对每条消息收费，未用完的额度不会结转。 这对集成设计的影响比乍看之下更大。只回复主动来信者的支持流程，在超过该额度之前一直免费，之后按条付费。主动联系客户的流程，则要为每条送达的消息模板付费，自 2026 年 10 月 1 日起，在窗口开启期间发送的实用类模板也包括在内。 因此，集成的成本取决于送达的消息数量及其类别，而不是对话数量。两个发送量相同的系统，Meta 收取的费用可能相差极大。 ### Meta 向谁收费？ 向您自己的 WhatsApp Business 账户所绑定的付款方式收费，该付款方式在 WhatsApp Manager 中设置。 这是企业与 Meta 之间的直接关系。费用不会经过 Tech Provider，这也是提供商无法加价、捆绑或转售这些费用的原因。任何声称提供 WhatsApp 消息折扣费率的服务，要么是安排不同的转售商，要么说的并不是 Meta 的收费。 实际的后果是：没有付款方式的账户，在每月免费额度用完之前仍可回复，但一旦发送消息模板或超出额度的回复就会失败。在弄清这种划分之前，这种故障会让人困惑。 - 以为回复永远免费。自 2026 年 10 月 1 日起，Meta 对每个号码每月超过 1,000 条的服务消息收费，窗口内的实用类模板同样收费。 - 以为提供商的发票包含 Meta 的费用。这些费用由 Meta 直接单独收取。 - 在账户没有付款方式的情况下搭建工作流。消息模板将无法发送，月度免费额度用完后回复也会停止。 **所有回复都免费吗？** 只有每个商业电话号码每月的前 1,000 条服务消息免费。之后 Meta 对每条消息收费，而在 24 小时窗口之外，您需要使用消息模板，并按送达计费。 **类别会影响价格吗？** 会。Meta 对营销、实用类、身份验证和服务消息的定价各不相同，费率还取决于收件人所在的国家或地区。 **提供商能给我更优惠的费率吗？** Meta 的费用无法优惠，因为这些费用根本不经过提供商。 **付款方式失效会怎样？** 需要扣费的发送会停止，并返回错误 131042。接收消息不受影响。 --- ## MCP 还是 Webhook：您真正需要哪一个 https://easycoexistence.com/zh-hans/docs/mcp-or-webhook MCP 是请求与响应：有人提出要求时，助手才会调用工具。Webhook 则相反，Meta 传送事件后，由您的系统决定如何处理。任何需要自动响应的流程，都不能只靠 MCP 构建。 ### 为什么 MCP 不能自动回复客户？ 因为这个协议没有被唤醒的机制。 MCP 服务器会公开工具，供客户端调用。调用由助手发起，而助手本身是在回应某个人。这里没有传入方向：客户发送 WhatsApp 消息时，无法触达助手并让它采取行动。每个产品中的每个 MCP 服务器都是如此，并不是我们的限制。 因此，每位买家最终都会问：AI 能否在夜间回复客户？这个问题需要 Webhook，而不是 MCP。Meta 会将消息传送到您运行的系统，再由该系统决定如何处理，其中当然可以包括调用模型。 ### 每种方式真正适合什么？ MCP 适合处理人正在做的工作。哪个号码的连接状态异常？把确认消息发给这位客户。为订单更新创建模板。将这位客户的号码指向我的服务器。这些操作都始于某人的要求，通过助手完成通常比打开控制台更快。 Webhook 适合处理无人值守时也必须发生的事情：非工作时间后的首次回复、转给合适的人、记录到 CRM、触发工作流程。 实用之处在于，MCP 可以设置 Webhook。get_connect_link 会生成客户端打开的链接，set_webhook_destination 会将对方的号码指向您的系统，因此代理可以完成这条它无法自行提供的路径所需的引导设置。 ### 哪些工具使用哪种方式？ 助手使用 MCP：Claude、ChatGPT、Cursor、Claude Code。自动化平台大多不是这样，而这个区别往往出乎人们的预期。 Make 和 Zapier 都运行自己的 MCP 服务器，将各自的操作公开给助手。两者都不是 MCP 客户端，因此都无法调用我们的 MCP。对它们来说，集成方式是 Webhook 和 HTTP 请求。 n8n 是例外。它的 MCP Client Tool 可以连接到远程服务器，并支持 OAuth2，因此 n8n 工作流程中的代理节点可以直接调用我们的工具。即使如此，工作流程仍然从 Webhook 开始，因为只有 Webhook 会作出响应。 - 购买 MCP 并期待自动回复。它只会在收到要求时行动，凌晨 3 点没有人要求它行动。 - 以为拥有 MCP 服务器的平台就能使用 MCP。Make 和 Zapier 只负责公开，不负责调用。 - 让两条路径做同一件事。它们分别负责同一系统的不同部分。 **助手可以监控我的 WhatsApp 吗？** 不能。没有任何机制可以将事件推送到 MCP 服务器。监控需要使用 Webhook，然后 Webhook 可以调用模型。 **我需要两者吗？** 大多数实际系统都会使用两者：MCP 处理人执行的工作，Webhook 处理无人参与时发生的一切。 **Zapier 可以使用您的 MCP 服务器吗？** 不能。Zapier 是 MCP 服务器而不是客户端，因此无法调用我们的 MCP。 **n8n 可以吗？** 可以，通过支持 OAuth2 的 MCP Client Tool。三者中，n8n 是唯一可以这样做的自动化平台。 --- ## 连接后 WhatsApp Business 应用有哪些变化 https://easycoexistence.com/zh-hans/docs/what-changes-in-the-app 手机端几乎没有变化。聊天、历史记录、联系人和设备都不变，团队照常回复。变化在于 API 连接到同一个号码，双方都能看到对方发送的内容，而群组不会纳入 API。 ### 哪些内容完全不变？ 应用、号码、对话，以及负责回复的人。 WhatsApp Business 应用打开方式不变，联系人列表不变，过去的每段对话也都还在。没有人需要在新地方登录，没有人需要安装任何东西，也不需要培训。企业在星期二下午连接号码后，星期三早上与过去每个星期三早上完全一样。 这正是重点。以前被要求迁移过的企业，可能觉得这个承诺好得难以置信，所以有必要把细节说清楚。 ### 真正会改变什么？ 只有 3 件事，而且只有 1 件能在手机上看到。 API 发送的消息会出现在应用的对话中，因此使用手机的人能看到完整情况，而不是只看到一半。这是唯一可见的变化，而且是改善，不是干扰。 在应用中输入的消息会对软件可见，并以 smb_message_echoes 事件到达。手机端没有人会察觉，但这能避免自动化流程在人工已经回复后再次回复。 群组聊天不会纳入 API。团队仍可像以前一样在应用中使用群组，只是任何服务提供商的软件都无法查看或发送群组消息。 ### 企业需要继续做什么？ 打开应用，而这本来就是他们要做的事。 如果主设备大约 14 天没有活动，Meta 会断开 Coexistence 连接。对于持续回复客户的企业，这种情况不会发生。对于有季节性停顿的号码，或代理商替客户持有、某个月业务较少的号码，这就需要注意。 断开连接后可以恢复，因此这是麻烦，不是损失。真正需要规划的是后续影响：Webhook 目标端点会随着连接一起被卸载，所以重新连接后可以恢复发送，但如果不重新应用，发送到您自己服务器的投递就不会自动恢复。 - 向团队承诺他们不会察觉变化，结果却执行了迁移而不是连接。迁移会移除应用。 - 围绕群组聊天构建任何功能。所有服务提供商的 API 都不支持群组聊天。 - 以为不活跃的号码会一直保持连接。应用 14 天没有打开，连接就会结束。 **团队需要学习任何新东西吗？** 不需要。他们继续像现在一样使用 WhatsApp Business 应用。 **我会失去旧对话吗？** 不会。对话仍保留在应用中，注册时还可以选择将大约 6 个月的历史记录分享给 API。 **我们还可以使用群组吗？** 在应用中可以，和以前完全一样。通过 API 则不可以，任何服务提供商都不支持。 **如果两周没人打开应用，会发生什么？** Meta 会断开 API 一侧的连接。重新连接即可恢复，应用本身始终不受影响。 --- ## Coexistence 参考 https://easycoexistence.com/zh-hans/docs/coexistence Coexistence 让 WhatsApp Business 应用和 Cloud API 同时使用同一号码。本页说明它是什么、消息如何传递、无法执行哪些操作，以及如何撤销。支持它的理由请参阅指南。 ### 它是什么 Meta 官方提供的模式，让 WhatsApp Business 应用和 Cloud API 同时使用同一电话号码。这不是另一个 API，而是同一个 Cloud API，只是采用特定流程完成注册，让应用之后继续使用该号码。 ### 团队为何使用它 几乎每次连接都基于以下 4 个理由。 - 保留已经印在车辆、收据和网站上的号码。 - 加入 API 发送、Webhook 和模板，无需让任何人改用新工具。 - 让对话留在自己的共享收件箱之外。 - 让代理机构持有许多客户号码，每个号码都放在客户自己的 Business Portfolio 中。 ### 通信如何运作 两个界面都能看到同一串对话。API 发送的内容会显示在应用中。团队在应用中输入的内容会作为 smb_message_echoes 事件传给软件，这样自动化流程就不会在人类回复后再次发送消息。 ### 定价方式 Meta 按对话而不是按消息收费，费用记入您自己的 WhatsApp Business Account 所使用的付款方式。24 小时客户服务时段内的回复免费。在时段外开启对话需要使用模板，并会产生费用。 ### 已连接设备 Coexistence 不是已连接设备，也不会使用已连接设备。已连接设备是指在其他位置登录的消费者客户端，非官方工具会自动化使用它，而 WhatsApp 的条款禁止这种做法。本功能完全不采用该机制。 ### 功能限制 这些限制由 Meta 固定，所有服务商都一样。 - API 无法使用群组聊天。 - 模板不能从手机应用发送，只能通过 API 发送。 - 发送吞吐量是固定的，不会随质量和级别扩展。 - 是否分享聊天记录只在注册期间决定一次。 ### 资格要求 号码必须先满足以下所有条件，才能连接。 - 已经在 WhatsApp Business 应用中启用，而不是在消费者应用中启用。 - 位于您有权访问的 Business Portfolio 中。 - 尚未连接到其他服务商的应用。 ### 运营注意事项 连接后有些事项确实如此，却很容易被忽略。 - 必须定期打开应用，否则 Meta 会断开 API 一侧的连接。 - 断开连接会连同应用一起卸载 Webhook 覆盖设置。 - 质量评级采用轮询而不是推送，因此评级下降时不会有任何通知。 - 没有第二个凭据时，被撤销的令牌看起来与已移除的号码完全一样。 ### 账户选择注意事项 在 Embedded Signup 期间，Business Portfolio 和 WhatsApp Business Account 是分开选择的步骤。选错账户会把号码连接到您原本不想使用的位置，之后要移动号码，就必须先断开连接，再重新完成整个流程。 ### 单向决定 分享现有聊天记录的选项只会询问一次，之后无法重新选择。同步也必须在注册后的 24 小时内开始，而且只能运行一次。错过时限时，两者都会产生陌生的错误，而不是提前发出警告。 ### 断开连接或回滚 您可以随时从控制台或通过连接器断开号码。WhatsApp Business 应用会完全照常运行，其中的对话和记录都保持不变；号码本身也不会因为曾经连接而被永久修改。 - 把 Coexistence 当成另一个 API。实际上，它是采用不同注册流程的 Cloud API。 - 围绕群组聊天来构建功能。所有服务商都不支持群组聊天。 - 以为重新连接会恢复 Webhook 目标地址。实际上不会。 **这是同一个 Cloud API 吗？** 是。Coexistence 是注册到 Cloud API 的一种方式，同时让 WhatsApp Business 应用继续使用该号码。 **可以撤销吗？** 可以。断开连接后，应用和其中的对话都会保持原样。 **我的团队需要培训吗？** 不需要。他们继续像现在一样使用 WhatsApp Business 应用。 **为什么应用不能发送模板？** 模板属于平台功能，而不是应用功能。24 小时窗口之外的内容必须通过 API 发送。 --- ## 哪些内容会同步到 API，哪些不会 https://easycoexistence.com/zh-hans/docs/what-syncs-and-what-does-not 联系人和一对一消息历史记录会同步到 API，之后消息会双向镜像。群组不会同步，WhatsApp Business 应用自己的工具也不会同步，包括目录、订单、状态、标签、快速回复、问候消息和离开消息。 ### 哪些内容会同步 有 2 类内容，而且对于使用现有号码多年的企业来说，这 2 类最重要。 - 联系人：每个有 WhatsApp 号码的联系人都可以同步到平台。 - 一对一消息历史记录，因此 API 不会看不到它出现前已经发生的对话。 - 从那之后，消息会双向镜像：API 发送的内容会出现在应用中，团队在应用中输入的内容也会传到您的系统。 ### 哪些内容不会同步 不会同步的内容比很多人预期的更多。在向客户承诺任何事项前，值得先读完这份清单。这些都不是服务提供商的限制，而是平台的工作方式。 - 群聊不会同步，任何服务提供商都无法通过 API 访问群聊。 - 商务工具：目录、订单和状态。 - 消息工具：问候消息、离开消息、快速回复和标签。 - 频道、语音和视频通话，以及企业资料详情。 ### 为什么应用自己的工具不会同步 因为这些是应用的功能，不是平台的功能，而 API 没有对应功能。 快速回复和标签保存在设备上。离开消息是应用在无人查看时发送的内容。这些都不是 API 概念，因此没有可同步到 API 的对应内容。 实际结果是，如果企业依靠标签来整理工作，就必须继续在应用中使用标签，而软件无法查看这些标签。如果您正在构建的系统需要这种整理方式，就必须在您的系统中重新建立，而不能直接读取。 ### 您可能错过的时间窗口 必须在入驻后 24 小时内开始同步。错过后，必须先断开该号码，再重新连接并完成入驻，才有新的机会。 这与控制消息发送的 24 小时客户服务窗口不同，但两者经常被混淆。前者从客户最后一条消息开始计算，用来判断自由文本能否送达。这里的 24 小时从入驻开始计算，用来判断历史记录是否仍可同步。 这也是为什么应在号码连接当天决定是否同步历史记录，而不是等到集成工作开始时再决定，因为那通常已经是另一个星期。 - 向客户承诺标签和快速回复会出现在您的系统中。它们会留在应用中。 - 围绕群聊构建任何功能。任何服务提供商都无法同步群聊。 - 等集成完成后才同步历史记录。时间窗口从入驻起只有 24 小时。 **我的旧对话会出现在 API 中吗？** 如果您在入驻时接受同步，一对一历史记录会同步。群组对话不会同步。 **软件可以查看我的标签吗？** 不可以。标签是应用功能，API 没有对应功能，因此标签会留在设备上。 **团队会失去快速回复吗？** 不会。快速回复会继续在应用中照常使用，软件只是无法查看它们。 **如果我错过 24 小时同步窗口怎么办？** 必须断开并重新连接该号码，重新执行入驻流程，并开启新的时间窗口。 --- ## Coexistence 后哪些 WhatsApp 功能会停止运作 https://easycoexistence.com/zh-hans/docs/features-disabled-by-coexistence 号码通过 Coexistence 连接后，有 4 项功能会停止运作：消失消息、仅看一次消息及实时位置都会在单人聊天中关闭，广播列表则会完全停用。现有列表不会被删除，而会变成只读。 ### 这 4 项功能 每项功能都会在平台层面关闭，而不是隐藏。原因在于 API 能读取聊天内容，而这些功能各自都依赖特定的隐私承诺。 - 消失消息：所有单人聊天均关闭。 - 仅看一次消息：所有单人聊天均停用。 - 实时位置消息：所有单人聊天均停用。 - 广播列表：停用，现有列表会变成只读，不会被移除。 ### 为何偏偏是这 4 项 原因是每项功能都承诺某种结果，而 API 的运作方式与该承诺相冲突。 消失消息承诺内容不会持续保留。仅看一次消息承诺内容只能查看一次。两项承诺都建立在没有其他系统保留副本的前提上，而已连接号码按定义会把消息传送至另一个系统。 实时位置是连续串流，不是消息，因此没有 API 表示方式。广播列表是在应用内一次发送给多人，而平台提供的对应方式是消息模板，须经批准后通过 API 发送。 所以这并非随意限制，而是平台不再承诺无法维持的结果。 ### 连接客户号码前要了解什么 先询问企业是否使用这些功能，因为事后才发现会让沟通变得困难。 广播列表最容易影响实际经营中的企业。若商店每周通过广播列表向 200 名客户发送消息，这套流程会停止。替代方案是已批准的营销消息模板，账户须有付款方式，并通过 Meta 审核。 消失消息影响的是另一类用户，通常是曾经开启后便忘记的人。除配送和外勤服务外，实时位置几乎不会被提起。 - 连接前未告知企业其号码依赖广播列表。替代方案是消息模板，并涉及批准和计费。 - 以为现有广播列表会被删除。它们会变成只读。 - 期待号码保持连接期间这些功能恢复。它们不会恢复。 **可以重新开启消失消息吗？** 号码保持连接期间不可以。断开连接后，应用会恢复正常运作。 **现有广播列表会被删除吗？** 不会。它们会变成只读，内容仍会保留，但无法继续发送消息。 **群组聊天会受影响吗？** 相关停用说明针对单人聊天。使用 Coexistence 的号码，其群组功能完全在 API 范围之外。 **什么可以替代广播列表？** 使用已批准的营销消息模板，通过 API 发送。此方式需要您自己的 WhatsApp Business Account 设有付款方式。 --- ## 哪些号码符合 Coexistence 的条件 https://easycoexistence.com/zh-hans/docs/number-eligibility 号码必须已在 WhatsApp Business 应用中使用，版本为 2.24.17 或更高，位于您可以管理的 Business Portfolio 中，并且尚未连接到其他服务提供商。地区不再是条件。其他情况都会在注册流程中被拒绝。 ### 号码本身必须符合什么条件 共有 4 个条件，全部由 Meta 在注册流程中检查，而不是由服务提供商检查。 - 已在 WhatsApp Business 应用中注册并使用，而不是在消费者版 WhatsApp 应用中使用。 - 主要设备上的应用版本为 2.24.17 或更高。 - 位于您拥有管理员权限的 Meta Business Portfolio 中。 - 尚未连接到其他服务提供商的应用。 ### Coexistence 在哪里可用 凡是 WhatsApp Business 应用可以运行的地方都可用。Meta 当前面向 Business 应用用户的注册文档说明完全没有地区限制；始于地区性推出的发布工作已在 2026 年完成，南非和尼日利亚是最后加入的市场之一。 需要明确说明这一点，因为推出期间发布的地区列表仍在流传，其中一些仍把已经支持数月的国家列为不支持。企业看到这些列表后，可能会误以为自己无法使用该功能。 Meta 没有发布带日期的国家列表，因此可靠的测试方法是直接走注册流程。如果号码正在 WhatsApp Business 应用中使用，而 Embedded Signup 没有因地区问题拒绝它，该号码就可以使用 Coexistence。 ### 注册流程中会出现什么问题 大多数问题都来自 3 种失败情况，而且每种表现都不同。 消费者版 WhatsApp 应用中的号码根本不会获得 Coexistence 选项。必须先将号码转移到 WhatsApp Business 应用，这是企业在手机上完成的迁移。 应用版本过旧时，流程可能启动，却无法完成扫描。更新应用后重试即可解决。 如果流程中途关闭，号码会保持连接到账户，却没有完成注册。控制台看起来像已连接，但首次发送时会返回错误 133010。重新从头运行流程即可完成注册。 - 在仍使用消费者版 WhatsApp 应用的号码上开始注册。必须先转移到 WhatsApp Business 应用。 - 相信推出期间的地区可用性列表。其中一些已经过时，仍把受支持的国家列为不支持。 - 号码出现后就关闭 Meta 的弹窗。后续步骤才会完成注册。 **我可以使用固定电话号码或虚拟号码吗？** 号码必须已在 WhatsApp Business 应用中注册，也就是说必须能够接收注册消息。 **我需要什么应用版本？** 设备上使用 2.24.17 或更高版本，并且该设备持有此号码。 **Coexistence 在我的国家可用吗？** 几乎可以确定。Meta 当前的注册文档说明没有地区限制，地区性推出也已在 2026 年完成。直接运行注册流程是最可靠的测试方法。 **号码出现在控制台中，却无法发送消息。** 注册流程可能没有完成。这会返回错误 133010，重新运行流程即可修复。 --- ## EasyCoexistence 与 360dialog https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-360dialog 360dialog 和 EasyCoexistence 都按已连接号码收费：Meta 的消息费用直接向您收取，双方都不加价。差异在于收费金额、价格层级数量，以及费用实际包含的内容。 ### 每一号码需要支付多少 双方都按号码收费，也都不加价收取 Meta 的消息费用，所以关键在于金额和费用所包含的内容。 - 360dialog:: 截至 2026 年 9 月，3 个 WhatsApp API 层级分别是每一号码每月 €49、€99 和 €500。注册时需要选择计划，之后还需要跨过相应门槛。 - EasyCoexistence:: 公开价格表从每一已连接号码每月 US$ 9 起，随号码增加降至 US$ 1。整份价格表没有任何功能限制：代理商接入第 20 个号码时，它能做的事情和第 1 个号码一样，而且费用更低；也不需要讨论升级，因为没有可升级的层级。 ### 增加客户后会怎样 这是每一号码的金额不再只是四舍五入误差的情况。 - 360dialog:: 按他们的入门层级计算，20 个号码每月是 €980，还未计入任何 Meta 费用。模式本身合理，倍数就是这个金额。 - EasyCoexistence:: 20 个号码每月是 US$ 140。每个号码都在客户自己的 Business Portfolio 中单独连接、单独列账，而且无论数量多少都不会触及新的层级。 ### 消息内容会流向哪里 这件事值得先确认，因为之后无法更改。 - 360dialog:: 他们的价格页面没有说明消息路径。这不能证明任何一方，您首先需要向他们提出这个问题。 - EasyCoexistence:: Meta 会通过您指定的 URL 发送消息事件，并通过我们应用订阅您账户的 override 传递。没有指定目的地的账户，其事件会回到我们的 callback，由处理程序丢弃且不保存。 ### Coexistence 本身 连接后，WhatsApp Business 应用是否仍能继续使用该号码。 - 360dialog:: 他们的价格页面没有提到这一点。请直接向他们询问，不要只相信比较页面，包括本页面：没有文档说明的功能，不代表缺少该功能。 - EasyCoexistence:: 这就是我们的完整产品。号码通过 Meta 自己的 Coexistence 流程连接，应用照常运行，每个界面都能看到另一个界面发送的内容。 ### 什么时候需要完整的 BSP 关系 这是一个实际存在的情况。 - 360dialog:: 当您购买的是供应商关系，而不是连接时。对方是运营历史悠久的成熟 BSP，具备区域覆盖和支持体系，小型产品无法匹配这些条件。他们提供最高层级，是因为大型发送方需要小型发送方不需要的功能。 - EasyCoexistence:: 一款专注的产品：提供电子邮件支持和连接时间线，显示发生了什么及发生时间。对于自行构建界面的用户，这正是所需内容，但它不是账户管理关系。 ### 应该选择哪一个 如果您需要指定的客户经理，以及由人员负责的升级处理路径，那就是 BSP 关系，而他们提供这种关系。 如果您持有客户号码并围绕这些号码构建软件，算术结果很清楚。同样的收费模式，价格只有五分之一，同时监控连接并将消息发送到您自己的系统，这才是能随代理商规模扩展的产品。 - 只比较每月金额。费用所包含的内容，差异比数字本身更大。 - 以为任何一方都会加价收取 Meta 的费用。双方都不会加价，这些费用由 Meta 直接向您收取。 - 把没有文档说明的功能当成缺少该功能。请向他们询问，不要只相信比较页面，包括本页面。 **价格是最新的吗？** 这些是 360dialog 价格页面截至 2026 年 9 月公布的价格，页面链接已列在上方。价格可能变化，决定前请查看来源。 **任何一方会加价收取 Meta 的费用吗？** 不会。双方都会直接转交这些费用，Meta 会直接向您自己的 WhatsApp Business Account 收费。 **360dialog 支持 Coexistence 吗？** 他们的价格页面没有提到这一点。这不能证明任何一方，值得向他们询问。 **哪一个更适合代理商？** 这是两种不同产品：360dialog 按客户提供平台，EasyCoexistence 按客户提供连接。EasyCoexistence 更便宜，客户数量增加后，价格差异会更明显。 --- ## EasyCoexistence 与 WATI https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-wati 这是两种不同的产品，而不是同一产品的竞争版本。WATI 提供团队共享收件箱，按用户数和每月活跃联系人收费。EasyCoexistence 提供连接本身，按号码收费，完全不提供收件箱。 ### 每月账单实际支付的是什么 两种产品按不同单位收费。对于持有多个号码的人来说，这个差异每月都会累积。 - WATI:: 按用户数和每月活跃联系人收费。截至 2026 年 9 月，公开方案包含 3 至 10 个用户和 500 至 2,500 个联系人，因此每增加一名客服或联系一位客户，账单都会上升。 - EasyCoexistence:: 每个已连接号码收取一项固定费用，不限制用户数或联系人数。代理机构的第 20 个客户费用不会高于第 1 个客户，繁忙月份与清闲月份也相同。 ### 客户的对话最终会在哪里 这是之后无法挽回的差异，也取决于每种产品本身的性质。 - WATI:: 在对方的平台上。共享收件箱必须储存消息内容，才能在任何人打开时显示这些内容，而对方的定价页面将此列为每个方案的核心功能。 - EasyCoexistence:: 不会留在我们这边。Meta 会将消息事件直接发送到您指定的 URL，任何到达我们的备用 callback 的内容都会被丢弃，不会持久化。这是由代码强制执行的，不是政策声明。 ### 您的团队是否需要改变工作方式 这是企业主在同意任何方案前都会问的问题。 - WATI:: 客服人员登录对方的收件箱。对话会在那里分配、标记和回复，这意味着团队要离开手机，改用新的工具。 - EasyCoexistence:: 没有人需要改变。WhatsApp Business 应用通过 Coexistence 继续使用同一个号码，保留相同的聊天和历史记录，而软件负责处理您构建的功能。 ### 超出产品能力后会发生什么 两种产品都有上限，只是上限所在的位置不同。 - WATI:: 增加用户数和活跃联系人数，每一步都要付费升级。平台本身就是产品，因此扩展意味着购买更多平台功能。 - EasyCoexistence:: 没有等级，也没有所谓超出上限。您构建的是界面，因此扩展的是您自己的系统，直接使用 Meta 文档所述的 API，中间没有我们的产品。 ### 什么时候您需要收件箱 只有一种情况。明确这一点，才能让本页面的其他内容有用。 - WATI:: 一个由 8 人组成的支持团队，需要在对方平台内分配对话，使用每月 4,999 印度卢比起、包含 3 个用户和 500 个每月活跃联系人的方案，之后每增加一名用户都要另行收费。 - EasyCoexistence:: 这是另一种工作需求。这里没有收件箱，也没有客服视图，因为界面正是您或客户已经拥有的部分。 ### 应该选择哪一个 如果每天都会有客服人员登录，而对话本身就是工作内容，请购买收件箱。WATI 构建了这样的产品，而且功能正如其所述。 其他大多数读者都属于另一种情况：您付费购买了收件箱，却不会使用它。持有客户号码的代理机构，购买的是没人打开的席位。自行构建界面的开发者，则是在自己的产品与 Meta 的 API 之间加入竞争产品。小型企业则被要求离开一部本来就能正常工作的手机。 EasyCoexistence 提供底层连接，按号码收取固定费用，让对话进入您的系统，同时让团队继续使用他们已经熟悉的应用。 - 直接比较每月价格。一个包含收件箱和用户，另一个不包含。 - 团队需要收件箱时，却选择连接。他们会不满意，而且理由充分。 - 您自行构建界面时，却选择收件箱。最后会得到两个界面。 **超过 500 个联系人后会怎样？** 使用对方的入门方案时，您需要升级到更高等级。使用我们时不会发生任何变化：任何价格都不限制联系人数，因此拥有 10,000 名客户的月份与拥有 10 名客户的月份费用相同。 **哪一个更便宜？** 与对方的入门方案相比，6 个号码以内是我们更便宜。该方案每月 4,999 印度卢比，约 US$ 53，包含 3 个用户和 500 个每月活跃联系人。我们的价格是每个已连接号码 US$ 9，6 个号码起每个 US$ 7，因此 6 个号码每月为 US$ 42。超过这个数量，答案取决于对方的额外用户费用和联系人档位费用，这些费用随团队和客户数量增加，而我们的价格只随号码数量增加。 **WATI 支持 Coexistence 吗？** 对方的定价页面没有说明这一点。请直接询问对方，不要仅依赖本页面。 **你们有移动应用吗？** 没有。团队使用 WhatsApp Business 应用，这正是 Coexistence 的意义。 --- ## EasyCoexistence 与 respond.io 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-respond-io respond.io 是多渠道平台，提供团队收件箱、工作流、AI 代理和广播，起价为每月 US$ 79，并设有用户和联系人上限。EasyCoexistence 是底层连接，按号码收费，不包含这些功能。 ### 运行成本是多少 根据不同计费单位收费，价格截至 2026 年 9 月已公布。 - respond.io:: 每月 US$ 79 起，包含 5 名用户和每月 1,000 名活跃联系人，最高为 US$ 279。费用取决于回答消息的人数，以及您触达的客户数量。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，随号码增加降至 US$ 1，不限制用户或联系人数量。费用取决于您持有的号码数量，也就是代理机构实际控制的号码数量。 ### 对话内容存在哪里 这是销售收件箱而不是连接所带来的结果。 - respond.io:: 在他们的平台上，因为团队收件箱需要平台来显示历史记录。他们的定价页面没有说明保留期限，如果这点对您重要，值得进一步询问。 - EasyCoexistence:: 我们这边不会保存。Webhook override 会把 Meta 的消息事件直接发送到您的端点，任何到达我们后备端点的内容都会被丢弃，不会持久化。 ### 您与 Meta 之间有什么 对于开发软件的人来说，这是决定性问题。 - respond.io:: 他们的平台。您需要基于他们的抽象层、速率限制、Webhook 格式和发布计划进行集成，而您构建的内容能否迁移，只取决于他们允许到什么程度。 - EasyCoexistence:: 什么都没有。API 属于 Meta，由 Meta 提供文档，Webhook 会发送到您的端点。您无需基于我们的任何东西进行开发，这也让您可以离开。 ### 谁在监控连接 定价页面很少提到这一点，而这正是本产品存在的原因。 - respond.io:: 他们的定价页面没有涉及这点，因此不应擅自断言。如果您持有客户号码，请具体询问连接静默中断时会发生什么。 - EasyCoexistence:: 按计划轮询质量评级、消息层级和吞吐量。按名称处理 Meta 的账户事件。保留 2 个凭据，避免把已撤销的令牌误判为号码丢失。重新连接后，会再次应用被移除的 Webhook override。 ### 什么时候应选择平台 值得说明，因为这两种产品回答的是不同问题。 - respond.io:: 当您需要平台时，他们公布的方案包括团队和自定义收件箱、工作流、广播、AI 代理、报告；更高层级还包括 SSO 和多个工作区。它是多渠道产品，而不只是 WhatsApp。 - EasyCoexistence:: 这是有意限定的不同范围：1 个号码、1 个连接、16 个 MCP 工具和 1 个 Webhook，界面由您自行决定。 ### 应该选择哪一个 这是不同层级，而不是同一产品的竞争版本。如果您这边没有人开发界面，又想要一个供代理工作的现成空间，您要找的是平台。 如果由您负责开发，平台就会作为竞争产品嵌入您的技术栈。您要为用户根本看不到的收件箱按席位付费，为您的产品已经处理的对话按联系人付费，并且要基于一个抽象层集成，而不是基于 Meta 记录并保持稳定的 API。 EasyCoexistence 位于底层：每个号码收取固定费用，将 Webhook 指向您的系统，并监控连接，避免静默故障变成客户流失。 - 把 US$ 9 和 US$ 79 进行比较，好像它们购买的是同一种东西。事实并非如此。 - 需要的是产品，却选择了连接。您将花几个月重新构建收件箱。 - 假设任何服务商都会监控连接。请具体询问，因为定价页面很少提到这一点。 **哪个适合我？** 它们属于不同层级。respond.io 是供您使用的平台；这是其底层连接，适合自行开发界面的团队。 **我可以从他们那里转到您这里吗？** 号码归您所有，可以通过 Coexistence 连接。您需要放弃的是他们的收件箱和工作流。 **你们提供工作流或 AI 代理吗？** 不提供。MCP 连接器让助理使用号码，Webhook 让您自己的系统作出响应。两者都不是工作流构建器。 **这些价格是最新的吗？** 价格截至 2026 年 9 月按已公布内容列出，并已在上方链接。决定前请检查来源。 --- ## EasyCoexistence 与 Dualhook 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-dualhook 两者都是采用相同核心架构的 Coexistence 提供商：WhatsApp Business 应用继续运行，消息 Webhook 从 Meta 直接发送到您的服务器，而不是经过提供商。两者相似之处更多，但差异仍值得了解。 ### 两款产品是什么 这是网站上最接近的对比，因为两者的定位几乎相同。 - Dualhook:: 两者都是 Coexistence 提供商，核心承诺相同：让 WhatsApp Business 应用继续运行，并将消息 Webhook 从 Meta 直接发送到您的服务器，而不是储存消息。对方文档将此称为 Webhook Override。 - EasyCoexistence:: 使用 Meta 采用的相同机制和名称。我们在应用订阅 WhatsApp Business Account 时设置 override_callback_uri，将消息路径字段移至您的端点，同时保留运营字段。 ### 消息发送到哪里 两者都会直接路由。差异在于未被路由的事件会怎样处理。 - Dualhook:: 直接从 Meta 路由，不储存消息。对方网站明确说明这一点，我们采用的也是相同架构。 - EasyCoexistence:: 路由方式相同。我们额外处理备用路径：未设置 override 的账户会将事件发送到我们的默认回调，处理程序会丢弃这些事件而不持久化。这个承诺由代码执行，而不是只写在政策中。 ### 14 天不活跃规则 如果主要设备约 14 天没有活动，Meta 会断开 Coexistence 连接。两款产品的处理方式不同。 - Dualhook:: 对方文档说明会在第 13 天发出预警，并提供倒数提示和提醒邮件。这只能提醒您计时正在进行，不能说明连接实际断开的原因。 - EasyCoexistence:: 我们监控断开事件，并读取 Meta 的原因字段，区分 PRIMARY_INACTIVITY、BUSINESS_DOWNGRADE、CHANGE_NUMBER 及其他原因。原因能区分两周没有活动和客户实际离开的情况。 ### 重连会破坏什么 这是不活跃规则中代价最高的后果，也是您应向任何提供商询问的问题。 - Dualhook:: 对方文档没有说明重连后 Webhook Override 会怎样。这不代表对方没有处理，只是您应直接向对方询问。 - EasyCoexistence:: 移除会从账户中卸载应用，override 也会随之移除。因此，重连虽然会恢复发送和监控，但发送到您服务器的投递可能会无声停止。我们会在每次重连时重新应用它，因为真实号码曾经干净重连后停止投递。 ### 每个号码的费用 两者都按每个已连接号码收取固定月费，而不是按用户或消息收费，也不会加价转收 Meta 的对话费用。 - Dualhook:: 对方自己的对比页面说明，固定月费从每月 US$ 12 起，截至 2026 年 9 月如此公布。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，随号码增加最低降至 US$ 1，不限制用户或联系人数量。对代理机构而言，新增每个客户号码都会累积这项差额。 ### MCP 连接器 对于特定受众，这是我们的优势所在。 - Dualhook:: 对方文档没有描述 MCP 服务器。其产品通过 API 和控制台使用。 - EasyCoexistence:: 通过带 OAuth 的远程 MCP 服务器提供 16 个工具，让 Claude、ChatGPT、Cursor 和 Claude Code 可以列出号码、检查连接状态、发送消息和模板，并设置 Webhook 目标。对于使用助手为客户开户的代理机构，这就是差异所在。 - 把未记录的功能当成不存在。请向对方询问；本页面只说明其文档未提及之处，不作猜测。 - 只按价格选择。相比 Meta 收取的对话费用，两者的服务费都不高。 - 假设任何提供商都会在重连后重新应用 Webhook Override。无论选择谁，都应具体询问。 **这两款产品真的采用相同架构吗？** 在消息路径上，是的。两者都使用 Meta 的功能，覆盖 WhatsApp Business Account 发送 Webhook 的位置，让对话内容发送到您的服务器，而不是经过提供商。 **两种方式如何处理 14 天规则？** 对方会在第 13 天提醒计时正在进行。我们读取 Meta 自有的断开原因，区分两周没有活动和客户实际离开的情况，并在之后重新应用 Webhook Override，避免投递无声停止。 **EasyCoexistence 有哪些不同？** 我们提供对方文档未描述的 MCP 连接器和 16 个工具，并会在重连移除 Webhook Override 后自动重新应用。 **这个页面公平吗？** 这里的每个数字都来自对方公开发布的页面，并注明了日期。请在决定前阅读这些页面：单方面撰写的比较是证据，不是结论。 --- ## WhatsApp Business 应用和 API 可以使用同一号码吗？ https://easycoexistence.com/zh-hans/whatsapp-business-app-and-api-same-number 可以。Meta 将其称为 Coexistence，这是官方功能，不是临时替代方案。员工继续在手机上的 WhatsApp Business 应用中回复，Cloud API 同时运行在同一号码上，双方都能看到相同的对话。 ### 一个号码如何同时用于两边？ 因为 Meta 专门为此建立了一个模式。过去，企业必须在两者之间作出取舍：将号码迁移到 API 后，WhatsApp Business 应用就无法继续使用。因此，员工需要在手机上回复消息的企业，只能在熟悉客户的员工和想加入的自动化之间选择。 Coexistence 消除了这个选择。号码会作为 API 号码向 Meta 注册，同时 WhatsApp Business 应用仍保持连接。客户发来的消息会同时到达手机上的应用和您的 API Webhook，您从任一方发送的回复也会显示在对话中。这不是模拟，也不是临时绕过方案，而是应用和 API 以两种获授权的方式访问同一个号码。 ### 手机上实际会有什么变化？ 变化比很多人预想的少，但在连接前了解这些差异很重要。 员工可以照常使用：相同的应用、聊天、联系人和号码。Meta 会在任何 Coexistence 号码上停用 4 项功能：消失消息、阅后即焚媒体、实时位置和广播列表。群组聊天仍可在应用中使用，但不属于 API 范围，因此自动化无法看到这些聊天。 号码首次连接时还会进行同步，将近期对话历史复制过去，让 API 端不会在没有背景资料的情况下开始工作。同步涵盖近期消息，而不是该号码的完整历史；更早的内容仍留在一直保存它的手机上。 ### 如果我们改变想法，会不会影响现有功能？ 不会。这个答案值得直接说明，因为这正是许多人不敢尝试的原因。 对话一直保存在手机上，也始终会留在那里。将号码与 API 断开后，WhatsApp Business 应用会和以前完全一样继续运行，聊天记录也保持完整，因为从一开始就没有把任何内容迁移到别处。API 是在应用旁边添加的，而不是取代应用。 号码也会一直留在企业自己的 Meta Business Portfolio 中。服务商以 Tech Provider 身份连接号码，这属于权限而不是所有权。因此，移除服务商后，号码仍会留在原处，不会被服务商带走。 ### 要让它正常运行，需要什么？ 需要 3 项条件，其中 2 项您已经具备。 号码必须正在使用 WhatsApp Business 应用，而不是消费者版 WhatsApp 应用，并且不能已经在其他地方注册 Cloud API。除此之外，您需要 Meta Tech Provider 来完成接入，因为无法直接从 Meta 控制台自行开通 Coexistence：连接必须通过服务商获批准的应用完成。 这正是我们的作用所在。Meta 自己的 Embedded Signup 会选择 Business Portfolio、账户和号码，您只需在 WhatsApp Business 应用中扫描代码进行确认，几分钟内即可完成连接。应用在整个过程中都会继续运行，包括建立连接期间。 - 以为必须二选一。Coexistence 正是为了让您不必作出这个选择。 - 期待通过 API 使用群组聊天。群组聊天会留在应用中，在任何地方都不属于 API 范围。 - 等待 Meta 控制台出现选项。Coexistence 接入需要通过 Tech Provider 完成。 **这是官方功能吗？** 是。Coexistence 是 Meta 自己的功能，也是 Meta 使用的名称。它不是桥接方案、关联设备或临时替代方案。 **员工会察觉有什么不同吗？** 只有 4 项功能会停用：消失消息、阅后即焚、实时位置和广播列表。其他功能都和以前一样。 **我的聊天记录会丢失吗？** 不会。聊天记录保存在手机上，也会继续留在那里。号码连接时，近期历史记录也会复制到 API 端。 **可以撤销吗？** 可以。断开号码后，应用会和以前完全一样继续运行，对话也保持完整。 --- ## 如何在不丢失聊天记录的情况下将 WhatsApp 连接到 API https://easycoexistence.com/zh-hans/connect-whatsapp-without-losing-chats 聊天记录保存在手机上，连接 API 不会移动它们。Coexistence 会在 WhatsApp Business 应用旁边加入 Cloud API，而不是取代应用，因此对话仍留在原处，应用也能继续运行。 ### 为什么过去连接 API 会导致聊天记录丢失？ 因为过去的流程是迁移，而不是添加。将号码注册到 Cloud API 后，号码会从 WhatsApp Business 应用中移出，而所有对话都保存在应用里。号码会以没有历史记录、也没有应用的 API 端点重新出现，因此许多企业尝试过一次 API 后就放弃了。 这种取舍确实存在，也是小型企业不使用官方 API 的最大原因。它还把用户推向非官方网关。这些网关通过假装是已连接设备来维持应用运行，却会让号码面临被封禁的风险。 ### Coexistence 有什么不同？ 它会加入 API，而不会移除应用。Meta 会将号码注册为 API 号码，同时 WhatsApp Business 应用仍保持连接，因此同一号码可以同时运行两者。 对话不会被移动。它们保存在手机上的应用内，和之前完全一样，无论之后 API 连接发生什么变化，都仍会留在那里。号码首次连接时，Meta 会将最近的对话历史同步到 API 端，让自动化流程不必从零开始，但这只是向前复制，而不是迁移。设备上的内容不会被移走。 之后，客户消息会同时出现在两个地方：手机上的应用和您的 Webhook。员工可以在应用中回复，您的系统也可以在需要时回复，两者都会显示在同一段对话中。 ### 哪些内容会同步，哪些不会？ 最近的消息历史会在连接完成后的一段时间窗口内同步。这样，自动化流程或客服人员可以了解正在进行的对话背景，而不是在完全没有上下文的情况下回复陌生客户。 不会同步的是更早的所有内容、连接前的媒体文件，以及群组对话。这些内容并没有丢失，仍保存在手机上的应用内，员工可以像之前一样查看。它们只是不会复制到 API 端，因为同步是为自动化提供起点，而不是建立存档。 如果您需要在其他地方保存完整历史记录，请从应用中导出。这是与连接号码分开的工作，不要将两者混为一谈。 ### 如果之后断开连接，会发生什么？ 应用会继续运行，聊天记录也仍然在那里，因为它们从未离开手机。 断开连接会移除号码的 API 端。WhatsApp Business 应用会继续运行，所有对话保持完整，企业无需恢复任何内容，就能回到最初的状态。这是开始前值得了解的安全保障：这种决定可以撤销，而过去的迁移流程无法做到这一点。 号码始终保留在您自己的 Meta Business Portfolio 中。服务提供商以 Tech Provider 身份连接号码，这是一项由您授予、也可以撤回的权限，因此离开服务提供商并不意味着要从对方那里取回号码。 - 因为担心而先导出所有内容。聊天记录不会消失。 - 期待 API 端显示完整历史记录。同步提供的是最近的上下文，不是存档。 - 使用非官方网关来维持应用运行。Coexistence 无需冒被封禁的风险即可做到这一点。 **我会丢失聊天记录吗？** 不会。聊天记录保存在手机上，也会继续留在那里。连接会在应用旁边加入 API，而不是取代应用。 **旧的历史记录会出现在我的系统中吗？** 连接后，最近的历史记录会同步。较早的消息和媒体文件仍保存在手机上。 **员工还能继续使用应用吗？** 可以，和之前完全一样。这正是 Coexistence 的作用。 **如果我断开连接，会发生什么？** 应用会继续运行，所有对话保持完整，因为没有任何内容被移动。 --- ## 获取 WhatsApp Business API 的最便宜方式 https://easycoexistence.com/zh-hans/cheapest-whatsapp-business-api API 本身免费。您需要支付的是 Meta 的对话费用，以及提供商的接入费用。无论您选择哪家，Meta 收取的部分都一样，因此唯一值得优化的是提供商费用，而最便宜的方式是按号码收取固定费用，不加收消息费用。 ### 您实际支付的是什么费用？ 这是两项不同的费用。混淆它们，正是这一领域的价格比较经常出错的原因。 第一项是 Meta 的对话定价。Meta 按类别收取对话费用，费率因国家而异；24 小时窗口内的服务对话，与由企业发起的对话，收费方式也不同。无论您通过谁购买，这项费用都会存在，因为它属于 Meta，而且通常是金额较大的一项。 第二项是提供商收取的接入费用。这完全取决于提供商的商业决策，也是您通过选择不同提供商真正可以改变的账单部分。如果比较提供商时不把这两项费用分开，比较出来的只是噪音。 ### 钱从哪里漏掉了？ 从加价里漏掉，而且因为每条消息的金额很小，所以很容易被忽略。 几家提供商会在 Meta 的费用之上，再收取单条消息费用。Twilio 公布的入站和出站消息费用都是 US$ 0.005。Gupshup 公布的是 US$ 0.001。其他提供商会给出已经包含 Meta 费用的综合费率，这意味着加价确实存在，但根本无法与 Meta 公布的费率核对。 十分之一美分，乘起来就不再微不足道。每月发送 100,000 条消息时，Gupshup 公布的费率是 US$ 100，Twilio 的费率是 US$ 500，而且这还不包括 Meta 收取的费用。在根据功能做选择前，这些数字值得先放进电子表格比较。 ### 最便宜的收费方式是什么？ 按每个已连接号码收取固定费用，Meta 的账单直接发给您，不作任何改动。 这种方式有两个替代方案没有的优点。号码连接后，费用就不会继续增加，因此业务增长不会带来更高费用。Meta 的发票也便于核对，因为没有人把自己的费用合并进去，您可以根据 Meta 自己公布的费率检查支付给 Meta 的金额。 我们的价格为每个已连接号码每月 US$ 9 起，随号码增加降至 US$ 1，不收取消息费用。按 Twilio 公布的费率计算，每月超过大约 1,800 条消息后，这种方式就更便宜，之后差距还会扩大。按席位收费的平台则是另一种计算方式：它们按人数而不是消息收费，因此临界点取决于团队人数。 ### 最便宜的选项就是正确的选项吗？ 不一定，诚实面对它不适用的情况也很重要。 如果您想要一个团队每天都在其中工作的产品，把共享收件箱、营销活动工具和分析功能集中在一起，那么按席位收费的平台确实提供了实际产品，这笔费用也对应这些功能。少付钱给我们，然后自行搭建这些功能，并不算节省。 如果您已经有现成系统，最便宜的选项就很合适。拥有 CRM、帮助台、自动化工具或 AI 代理的企业，不需要第二个地方来阅读消息；它需要的是让 WhatsApp 连接到第一个系统。对于这项工作，按号码付费且不收取消息费用，就是在继续使用官方 API 的前提下所能支付的最低费用。 - 比较提供商时，没有把 Meta 的对话费用与提供商费用分开。 - 把综合单条消息费率理解为没有加价。实际上，这表示费用没有分项列出。 - 当您真正需要的是平台出售的收件箱时，却只选择了费用最低的选项。 **WhatsApp Business API 是免费的吗？** 接入是免费的。Meta 会收取对话费用，提供商则会在此基础上收取接入费用。Meta 收取的部分在任何地方都一样。 **哪家提供商最便宜？** 最便宜的方式是按号码收取固定费用，不加价。我们的价格每个号码 US$ 9 起，随号码增加降至 US$ 1。 **提供商更便宜，是否意味着 API 更差？** 不是。每种情况下，Cloud API 都属于 Meta。提供商改变的是 API 前面的服务，以及他们收取的费用。 **什么时候值得选择更贵的提供商？** 当您需要他们出售的产品时，例如团队每天都在其中工作的共享收件箱。 --- ## 消息模板组件：标头、正文、页脚和按钮 https://easycoexistence.com/zh-hans/docs/template-components 消息模板由最多 4 个组件组成：标头、正文、页脚和按钮。只有标头和正文支持变量，而且每个组件都有各自的限制，决定消息在 Meta 审核前可以表达什么。 ### 标头 可选，共有 4 种类型：文本、图片、视频或文档。文本标头最多 60 个字符，并支持单个变量。媒体标头会携带发送时提供的文件，可用于附加收据或票据。 - 文本标头：60 个字符，最多 1 个变量。 - 媒体标头：图片、视频或文档，每次发送时提供。 - 每个模板只能有 1 个标头。 - 某些类别可使用位置标头。 ### 正文 这是必需部分，最多 1024 个字符，也是唯一支持多个变量的组件。变量按位置排列，并写成带编号的占位符，因此您发送的第 1 个参数会填入第 1 个占位符。 如果正文几乎全是变量而固定文本很少，Meta 会拒绝该正文，因为模板本身几乎没有内容，无法与任意内容的开放输入框区分。请围绕占位符写出完整句子。 ### 页脚 可选，最多 60 个字符，始终是完全不含变量的固定文本。它的显示尺寸比正文更小、颜色更灰，适合放置长期提示，但不适合放置消息必须依赖的内容。 营销模板常用页脚放置退出订阅说明，这也有助于提高收件人对模板的接受度。 ### 按钮 总数最多 10 个，共有 3 种类型，按钮组合会很大程度影响审核结果。 - 快速回复：点按后向您发送固定文本回复。 - 行动号召：打开 URL 或拨打电话号码。 - URL 按钮支持 1 个变量，并将其附加到固定的基础 URL 后。 - 复制代码：向收件人提供可复制的代码，用于身份验证。 ### 为什么审核前的结构很重要 Meta 会整体审核消息模板，大多数拒绝源于结构，而不是措辞。 正文几乎全是变量、URL 按钮指向与业务无关的位置，或将营销消息提交到实用工具类别，都会因结构问题被拒绝。先确定正确结构，措辞审核就会更直接。如果模板因政策被拒绝，系统会返回错误代码 132007，而不是指出真正原因的错误信息。 - 正文主要由占位符组成。Meta 会拒绝固定文本过少的模板。 - 期待在页脚使用变量。页脚是没有例外的固定文本。 - 将营销消息提交到实用工具类别。错误的类别不是靠措辞可以挽救的。 **哪些部分支持变量？** 标头最多支持 1 个，正文支持多个。页脚不支持变量，URL 按钮支持 1 个附加值。 **正文可以有多长？** 最多 1024 个字符，远长于其他组件。 **最多允许多少个按钮？** 总数最多 10 个，各类型还有自己的限制。 **为什么我的模板被拒绝？** 通常是结构而非措辞问题：固定文字太少，或类别错误。这会返回错误代码 132007。 --- ## 消息模板状态生命周期 https://easycoexistence.com/zh-hans/docs/template-status-lifecycle 消息模板会依次经历多个状态，而获批只是中间阶段，并不是终点。获批的消息模板可能因质量问题暂停使用，之后自动恢复，再次暂停，最终永久停用，全程无需人工操作。 ### 状态 消息模板通常会依次经历这些状态。 - PENDING：已提交，等待审核。 - APPROVED：可用于发送。 - REJECTED：审核时被拒绝，通常涉及结构或类别。 - PAUSED：质量下降后暂时无法使用。 - DISABLED：永久无法使用，生命周期结束。 ### 消息模板为何会暂停 这不是由您的操作引起的。收件人会屏蔽或举报使用该消息模板发送的消息，消息模板自身的质量评分也会从绿色降至黄色，再降至红色，Meta 随后暂停它以阻止情况继续恶化。 暂停是暂时的，会自动解除。关键在于之后的变化：反复暂停会升级，而持续回到红色的消息模板最终会被永久停用，不会再次只是暂停。 ### 两个 Webhook 要查看完整周期，两个 Webhook 都不可缺少。只订阅其中一个会留下盲点。 - message_template_status_update：获批、拒绝、暂停和停用。 - message_template_quality_update：质量评分在绿色、黄色和红色之间变化。 - 质量 Webhook 是早期警报，状态 Webhook 是后续结果。 - 默认不会启用任何一个，因此两个都必须订阅。 ### 为什么黄色是采取行动的时机 等到消息模板暂停时，使用它发送已经失败，营销活动也已经中断。黄色状态下它仍在运行，而且下降趋势已经可见。 针对黄色状态采取行动，不只是检查文案，也要检查受众。向未预期收到消息的人发送一份写得很好的消息模板，同样会快速收到屏蔽反馈；只重写文案而保留名单并不会改变结果。 ### 编辑会带来什么影响 获批的消息模板可以编辑，但编辑后会重新进入审核流程。这很有用，不过生产环境中常见一个后果：如果编辑改变了变量数量，所有未更新的集成在发送时都会开始返回错误 132012。 应将消息模板的变量数量视为集成契约的一部分，而不是营销团队单独负责的文案内容。 - 把获批当成永久有效。获批的消息模板仍可能暂停，最终也可能停用。 - 只订阅状态而不订阅质量。quality 字段是早期警报。 - 编辑消息模板的变量，却不检查负责发送的代码。 **获批的消息模板会一直保持获批吗？** 不一定。持续的负面反馈可能导致它暂停，最终永久停用。 **暂停和停用有什么区别？** 暂停会自动解除。停用是永久状态，消息模板无法再次使用。 **我怎样才能提前发现？** 订阅消息模板质量 Webhook。它会在消息模板仍可使用时报告其转为黄色。 **为什么编辑后发送开始失败？** 如果编辑改变了变量数量，未更新的集成现在会发送错误数量的参数，因此返回错误 132012。 --- ## 发送带变量的消息模板 https://easycoexistence.com/zh-hans/docs/sending-a-template-with-variables 消息模板变量按位置传递，而不是按名称传递。您需要按顺序为每个组件发送参数列表，数量必须与模板定义完全一致。这样做错会产生 3 种不同错误，每种错误都对应不同问题。 ### 参数如何匹配 按位置匹配，而不是按名称匹配。正文列表中的第 1 个参数会填入第 1 个占位符，第 2 个参数会填入第 2 个占位符，依此类推。您无法为变量命名；如果交换两个参数，消息仍会成功发送，但值会出现在错误位置。 最后一种情况最危险，因为不会发生失败。客户收到订单确认时，日期可能出现在金额的位置，而且任何地方都不会记录错误。 ### 组件使用不同列表 标题变量和正文变量不共用同一个列表。每个组件都有自己的参数；把它们合并会导致数量不匹配。 - 标题参数放在标题组件中，最多只能有 1 个。 - 正文参数放在正文组件中，并按顺序排列。 - 按钮 URL 参数放在按钮组件中，并按按钮建立索引。 - 为所有组件发送一个扁平列表会返回错误 132000。 ### 正确设置语言 模板由名称和语言共同标识，因此同名但语言不同的是两个模板。模板创建时使用的是 en_US，您发送 en 不会自动回退，而会因错误 132001 失败；该错误显示为模板不存在。 请列出该号码上的模板，并复制准确的语言字符串，不要自行假定其格式。这是最常见、也最不明确的模板错误。 ### 类型化参数 大多数参数都是普通文本，但有些不是。将这些参数作为文本发送会失败，并返回错误 132012。 - 货币参数包含金额、货币代码和备用字符串。 - 日期和时间参数包含带备用值的结构化对象。 - 媒体标题参数包含媒体 ID 或链接，而不是文件名。 - 如果收件人的应用无法格式化该值，显示的就是备用字符串。 ### 各错误分别代表什么 这 3 种失败可以区分。如果分别记录，而不是统称为模板错误，就能减少大量猜测。 错误 132001 表示名称和语言组合无法解析，请先检查语言。错误 132000 表示数量错误，请与模板自身的定义进行比较。错误 132012 表示值的格式错误，通常是把类型化参数作为普通字符串发送。 - 以为 en 会回退到 en_US。事实并非如此，该错误会显示为模板不存在。 - 把标题和正文参数合并到一个列表中。它们属于不同组件。 - 把货币或日期作为普通文本发送。类型化参数有明确格式。 **消息模板变量有名称吗？** 没有。它们按位置传递，因此参数顺序就是完整约定。 **为什么我的模板不存在？** 通常是语言代码的问题。模板由名称和语言共同标识，并且不会自动回退。 **如果我发送了过多参数，会怎样？** 错误 132000。参数过多和参数过少会以相同方式失败。 **如何发送金额？** 使用包含金额、货币代码和备用字符串的货币参数，而不是普通文本。 --- ## 速率限制与消息吞吐量 https://easycoexistence.com/zh-hans/docs/rate-limits-and-throughput 限制共有四种，彼此独立，把它们混为一谈正是速率限制令人困惑的原因。消息限制按 Business Portfolio 统计每天的唯一收件人数量，吞吐量限制每秒发送的消息数，配对限制约束发给同一个人的消息数量，管理限制则约束不属于消息的 API 调用。 ### 消息层级 指在客户服务窗口之外，每个滚动 24 小时内您最多可以向多少位唯一客户发送消息。自 2025 年 10 月 7 日起，该限制按 Business Portfolio 设定，由其中所有号码共享；只要质量保持稳定且发送量增长，限制就会自动上调。 - 限制逐级提升：每天 250、2,000、10,000、100,000 个唯一收件人，最后是不限量。 - 只有在客户服务窗口之外发送的消息才会计入。 - 在服务窗口内的回复不计入。 - 质量下降不会再使限制回落，但会使限制停止增长。 ### 吞吐量 指每秒发送的消息数，与每日的消息层级是两回事。一个号码即使远低于自己的层级，也可能因为突发大量发送而触及吞吐量限制。 在 Coexistence 号码上，这是最容易让人意外的限制，因为它的上限比标准 Cloud API 号码更低。这个上限由 Meta 设定，适用于所有 Coexistence 提供商，因此没有任何提供商能够提高它。 ### 单一收件人限制 这是另一项上限，约束在短时间内您的号码与同一位收件人之间可以往来的消息数量，对应错误 131056。它的作用是避免同一个人被大量消息淹没，因此即使账户发送量很低也可能触发。 原因几乎总是自动化造成的：重试循环、同一事件触发了两次的 Webhook 处理程序，或是把一条回复拆成多条短消息的机器人。 ### 管理调用限制 与消息无关。读取号码、列出模板和查询状态都会计入另一项账户限制，对应错误 80007。 耗尽这项限制的通常是轮询。每三十秒查询一次状态，一天就是数千次调用，而这些数据每月只变化几次。使用 Webhook 几乎可以省去所有这类调用。 ### 什么能提高限制 靠的是质量和历史记录，而不是付款。没有可以购买的方案，也没有任何提供商能代您提高上限。 - 保持绿色质量评级；收件人的屏蔽会拉低评级。 - 持续稳定地发送，而不是集中突发发送。 - 完成商家验证，这是从 250 提升到 2,000 的途径之一。 - 使用当前限制的至少一半；超过 2,000 的提升是自动进行的。 - 把所有速率限制当成同一种。四种不同的限制会产生四种不同的错误。 - 以很短的间隔轮询状态。这会在很少变化的数据上耗尽管理调用限制。 - 指望付费提高限制。限制的变化取决于质量和历史记录。 **为什么发送量很低却被限速？** 很可能是单一收件人限制，即错误 131056。它限制发给同一个人的消息数量，与您的账户总量无关。 **我可以付费获得更高的消息限制吗？** 不可以。限制会根据质量和发送历史自动提高。 **Coexistence 的吞吐量更低吗？** 是的。Meta 为其设定的上限比标准 Cloud API 号码更低，且没有任何提供商能够提高。 **哪些调用会计入管理限制？** 读取和配置类调用：列出号码、模板和状态。使用 Webhook 几乎可以避免所有这些调用。 --- ## 发送互动消息：按钮和列表 https://easycoexistence.com/zh-hans/docs/sending-interactive-messages 互动消息让收件人点击按钮或列表，而不必输入文字。互动消息分为回复按钮和列表消息两种，两者都有固定的小限制，往往比其他因素更影响对话设计。 ### 回复按钮 一条消息下方最多可放 3 个按钮。收件人点击其中一个后，回复会通过您的 Webhook 作为普通入站消息返回，并携带按钮的 id，因此您应根据 id 匹配，而不是根据标签匹配。标题最多 20 个字符，这比听起来更短，通常会迫使您重写文案。 - 每条消息最多 3 个按钮。 - 标题最多 20 个字符。 - 每个按钮都有由您选择的 id，回复时会原样返回。 - 按钮周围可选择添加标题、正文和页脚。 ### 列表消息 一个按钮可以打开包含最多 10 行的菜单，并分成最多 10 个分区。每一行都有标题、可选描述和 id。当 3 个按钮不够用时可以使用列表，但请记住，收件人必须先打开列表才能看到内容，因此按钮标签需要清楚说明用途。 - 总共最多 10 行，分布在最多 10 个分区中。 - 行标题最多 24 个字符，描述最多 72 个字符。 - 每条消息只能有一个列表，不能与按钮结合使用。 - 并非所有类别的模板消息都支持列表。 ### 回复如何返回 回复会通过与其他入站消息相同的消息 Webhook 返回，并带有标明按钮或行 id 的 interactive 对象。不需要另外订阅任何内容。 请根据 id 匹配，而不是根据标题匹配。编辑文案的人可能会修改标题，而 id 不会改变。根据文字匹配的处理程序，可能会在有人修正错字后静默失效。 ### Coexistence 会带来什么变化 按钮和列表本身没有变化。它们都是普通的 Cloud API 消息，在 Coexistence 号码上的工作方式与其他号码相同。 变化在于回复会送达的位置：客户的点击会同时出现在手机上的 WhatsApp Business 应用和您的 Webhook 中，因为 Coexistence 号码会向两边送达消息。如果处理程序会自动回复，就应考虑到客户可能同时在应用中手动回复同一条消息。 - 根据按钮标题匹配回复。标题会被编辑，id 不会。 - 为超过 3 个按钮设计流程。这个限制是固定的，没有变通方法。 - 忘记客户可能会在 WhatsApp Business 应用中手动回复同一次点击。 **我可以发送多少个按钮？** 3 个。这是平台的硬性限制，没有变通方法。 **有人点击后会返回什么？** 一条通过消息 Webhook 返回的普通入站消息，其中带有您分配给按钮或行的 id。 **可以同时使用按钮和列表吗？** 不可以。一条消息只能使用其中一种。 **这些消息需要额外收费吗？** 不需要。它们是普通消息，Meta 会按照该对话中其他消息的相同方式计费。 --- ## 发送媒体：图片、视频、音频和文档 https://easycoexistence.com/zh-hans/docs/sending-media-messages 媒体文件有两种发送方式：先上传文件，再使用返回的 ID；或提供公开链接，让 Meta 获取文件。上传更可靠，而且不同类型的大小限制差异很大，容易被忽略。 ### 按类型划分的限制 每种类型都不同。超过限制会返回错误 131053，而不是明确的说明。 - 图片：5 MB。JPEG 和 PNG。 - 视频：16 MB。MP4 和 3GPP，视频使用 H.264，音频使用 AAC。 - 音频：16 MB。AAC、AMR、MP3、MP4 音频，以及使用 Opus 的 OGG。 - 文档：100 MB。常见文档类型，包括 PDF 和 Office 格式。 - 贴纸：动态 100 KB，静态 500 KB，仅支持 WebP。 ### 上传与提供链接 发送同一文件有两种方式，但失败原因不同。 上传会先将文件发送至 Meta，并返回媒体 ID。发送消息时，您可以引用此 ID。提供链接则是让 Meta 在发送时通过 URL 获取文件。提供链接看似更简单，却多出一种您看不见的失败原因：URL 即使能在您的浏览器中打开，也可能因地理位置、防火墙规则，或浏览器已有的会话 Cookie，无法从 Meta 的基础设施访问。 请上传文件。只多一次请求，就能移除整类故障。 ### 接收媒体 入站媒体会以媒体 ID 传入，而不是以字节传入。您的处理程序需要使用该 ID，另外获取文件。 - 尽快获取。ID 的有效期不是永久的。 - 获取失败会返回错误 131052，通常表示发送方的上传未完成。 - 如果之后还需要使用文件，请自行保存。Meta 不是归档系统。 - 即使媒体获取失败，也要记录消息，让文字和上下文得以保留。 ### Coexistence 带来的变化 在 Coexistence 连接上，媒体处理方式与其他 Cloud API 连接完全相同，限制也相同。 唯一值得了解的差异是历史记录。首次连接时，Meta 会从 WhatsApp Business 应用同步近期消息，但同步内容是消息文字，并非完整的媒体归档。连接前的媒体仍在手机上，位置没有改变。 - 因为提供链接看似更简单就这样做。Meta 的网络不是您的浏览器。 - 数小时后才获取入站媒体。媒体 ID 会过期。 - 未检查编解码器就导出视频。编辑软件的默认设置常常不受支持。 **我能发送的最大文件是多少？** 100 MB，但仅适用于文档。视频和音频上限为 16 MB，图片上限为 5 MB。 **我应该上传文件，还是发送 URL？** 请上传文件。这样可排除可访问性问题这一失败原因。 **媒体 ID 的有效期有多长？** 不是永久有效，因此入站媒体应在事件到达后尽快获取。 **连接时会同步旧媒体吗？** 不会。历史同步只涵盖近期消息内容；连接前的媒体仍留在手机上。 --- ## 消息反应：发送和接收表情符号 https://easycoexistence.com/zh-hans/docs/message-reactions 反应会将单个表情符号附加到现有消息。发送反应时，需要引用消息 id 和表情符号；移除反应时，则发送相同的反应，但将 emoji 字符串设为空，而不是调用删除操作。 ### 发送反应 类型为 reaction 的消息，其中包含被反应消息的 id 和单个表情符号。向同一条消息发送第二个反应会替换第一个，而不是在其基础上添加，因为每位发送者每条消息只能保留 1 个反应。 消息 id 必须是您的号码可以看到的消息：该客户发来的消息，或您发送给该客户的消息。 ### 移除反应 这部分最容易让人意外。没有删除调用。您需要发送相同的反应消息，将 emoji 字段设为空字符串，这样就会清除反应。 如果处理程序预期接收移除事件，就会一直等待。实际送达的是 emoji 为空的 reaction，结构与新反应相同，因此必须通过检查该字段，将其识别为移除操作。 ### 接收反应 传入的反应会通过 messages Webhook 送达，作为类型为 reaction 的消息，其中标明所附加消息的 id 和表情符号。 - 订阅 messages 字段，没有单独的 reactions 字段。 - emoji 为空表示客户移除了自己的反应。 - 引用的消息 id 是您之前发送或接收的消息。 - 反应不会重新开启 24 小时服务窗口。 ### 服务窗口仍然适用 反应属于消息，因此发送反应需要 24 小时客户服务窗口处于开启状态。对客户 3 天前的消息添加反应时，会返回错误 131047，就像发送普通文字消息一样。 收到客户的反应会重新开启服务窗口，因为任何传入消息都会这样做。这一点对自动化很有用：客户对您上一条消息点个赞，就是一个有效信号，表示您现在可以自由回复。 - 寻找删除端点。移除反应使用相同的调用，只需将 emoji 设为空。 - 将空 emoji 视为格式错误。空 emoji 就是表达移除反应的方式。 - 在服务窗口之外发送反应。它会像其他消息一样失败。 **如何移除反应？** 发送相同的反应消息，并将 emoji 字符串设为空。没有删除调用。 **反应收费吗？** 不收费。反应不会开启计费对话。 **我可以对任何消息添加反应吗？** 只能对您的号码发送或接收的消息添加反应，而且必须在 24 小时服务窗口内。 **客户的反应会重新开启服务窗口吗？** 会。客户发来的任何消息都会重新开启窗口，包括反应。 --- ## 发送位置和联系人消息 https://easycoexistence.com/zh-hans/docs/sending-location-and-contacts 位置消息会发送一个图钉，可选择附上名称和地址。联系人消息会发送一张或多张联系人卡片。两者都很简单，但需要知道的是，实时位置会随着对方移动而更新，在 Coexistence 号码上无法使用。 ### 位置消息 纬度和经度会显示在图钉下方，也可以选择附上名称和地址。收件人会看到地图预览，并可在自己的地图应用中打开。 提供名称和地址很值得。如果不提供，图钉只会显示坐标，客户无法知道自己看到的是不是正确分店。 ### 接收位置 客户分享位置后，会以 type location 的消息形式抵达 messages webhook，其中包含坐标；如果客户的应用提供了名称和地址，也会一并包含。 - 坐标一定存在，名称和地址则不一定。 - 分享的位置属于消息，因此会重新开启 24 小时服务窗口。 - 坐标应视为大概位置，手机定位准确度各有不同。 - 只储存您需要的资料，Meta 不会提供位置历史记录。 ### 联系人消息 一条消息可以包含一张或多张联系人卡片，每张卡片都带有 vCard 的字段，包括姓名、电话号码、电子邮件、地址、组织和生日。收件人可以直接储存卡片。 当您要把正确联系人的资料交给客户时，这很有用。否则，把号码输入聊天后会以未格式化文本抵达，还需要手动复制。 ### Coexistence 会移除什么 实时位置是 Coexistence 启用后，Meta 会在号码上停用的 4 项 WhatsApp 功能之一，其他包括消失消息、仅看一次媒体和广播列表。 尝试发送实时位置会返回错误 131051，unsupported message type。这个错误看起来像格式错误，但实际并不是。任何服务提供商都无法启用该功能，因为这是 Meta 的限制，适用于所有 Coexistence 号码。静态位置图钉不受影响，可以正常使用。 - 发送图钉时没有附上名称或地址。只有坐标对客户没有帮助。 - 围绕实时位置进行开发。所有 Coexistence 号码都无法使用该功能。 - 把错误 131051 当成格式错误，但实际是该消息类型无法使用。 **可以发送实时位置吗？** Coexistence 号码不可以。Meta 会停用该功能，任何服务提供商都无法重新启用。 **静态位置图钉可以使用吗？** 可以正常使用，也可以选择在地图预览下方显示名称和地址。 **一条消息可以包含多少位联系人？** 可以包含多位联系人。每位联系人都带有标准 vCard 字段，收件人可以直接储存。 **分享的位置会重新开启服务窗口吗？** 会。它和其他入站消息一样。 --- ## EasyCoexistence 与 AiSensy https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-aisensy AiSensy 是按月收费的 WhatsApp 营销和聊天机器人平台，深受印度电商企业欢迎。EasyCoexistence 是基础设施：通过 Meta 自己的 Coexistence 功能连接号码，把消息送到您现有的系统，并按已连接号码收费。哪一个更便宜，取决于您是否要在平台内工作。 ### 每个产品是什么 它们争取的不是同一种购买需求，先说清这一点，比较才有意义。 - AiSensy:: 围绕群发活动、聊天机器人流程和团队共享收件箱打造的 WhatsApp 互动平台，按月分级收费，并限制联系人和代理人数。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一个号码，消息事件从 Meta 直接发送到您的 CRM、服务台、自动化工具或 AI 代理。您的团队无需迁移到另一个产品。 ### 产品适合谁 两者都能连接 WhatsApp，但各自预期您每天完成的工作不同。 - AiSensy:: 负责群发活动和聊天机器人漏斗的营销团队。他们希望在一个地方使用活动构建器、联系人名单和分析工具，也愿意在该平台内工作。 - EasyCoexistence:: 已经有系统的企业或开发者。我们把 WhatsApp 消息送入您的系统并保持连接，然后不再干预。如果您需要活动，就在客户数据已有的地方运行。 ### 让手机上的应用继续运行 这是 Coexistence 存在的具体原因，也是您应该向任何平台提出的问题。 - AiSensy:: 他们的产品就是平台收件箱，因此通常预期您在其中处理对话，而不是在手机上的 WhatsApp Business 应用中处理。 - EasyCoexistence:: WhatsApp Business 应用会完全照常运行。员工在手机上回复，API 看到相同的对话，双方都无需停止。这就是整个功能。 ### 账单按什么计算 这是结构上的差异，也是您扩大规模后决定总费用的因素。 - AiSensy:: 按用户和方案等级设计的订阅，因此账单跟随团队规模和已解锁功能，无论席位是否使用都要付费。 - EasyCoexistence:: 按已连接号码收费。添加同事无需付费，因为没有席位；随着号码增加，每个号码的费率会从 US$ 9 降至 US$ 1。代理机构的第 40 个号码与第 1 个号码功能相同，费用却更低。 ### 离开后会怎样 任何承载您对话的产品，都值得问这个问题。 - AiSensy:: 收件箱、联系人历史记录和自动化流程都在该平台中。它们因此能够运行，但离开也会变成一次迁移项目。 - EasyCoexistence:: 您的任何内容都不在我们这里。消息到达时就已送入您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍在原处。 - 比较席位价格和按号码价格，却没有按自己的使用结构计算两者总数。 - 团队已经在 CRM 中工作，却仍为收件箱付费。 - 误以为 WhatsApp 连接不同。两者底层使用的都是 Meta 的 Cloud API。 **哪一个更便宜？** 取决于您的使用结构。5 人团队使用一个收件箱，可能更适合按席位收费。拥有多个号码且已有系统的企业，使用我们按号码收费会便宜得多。 **我会失去共享收件箱吗？** 您从来不需要迁移到共享收件箱。消息会送到团队已经使用的工具中，您也会在那里继续工作。 **WhatsApp 连接不同吗？** 不不同。两者使用的都是 Meta 的 Cloud API。不同之处在于前端连接的产品以及计费方式。 **我能使用群发活动吗？** 我们不提供群发活动，也不会向您收取这项费用。消息会送到您自己的系统，因此活动可以在客户数据所在的地方运行。 --- ## EasyCoexistence 与 Interakt 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-interakt Interakt 是按月订阅、按坐席设限的 WhatsApp 商务和支持平台。EasyCoexistence 是基础设施：通过 Meta 自有的 Coexistence 功能连接号码，把消息发送到您现有的系统，并按已连接号码收费。哪一个更便宜，取决于您是否需要一个供团队使用的产品。 ### 每个产品是什么 它们并不是争夺同一笔采购预算的产品，先厘清这一点，比较才有意义。 - Interakt:: 一个 WhatsApp 商务平台，提供目录集成、订单通知、共享收件箱和自动化功能，按月订阅，并限制坐席和联系人数量。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一个号码，消息事件从 Meta 直接发送到您的 CRM、客服系统、自动化工具或 AI 代理。您的团队无需迁移到另一个产品。 ### 商务逻辑在哪里运行 这是网店真正需要作出的选择，关键在于您的目录已经在哪里。 - Interakt:: 商务逻辑在平台内运行，并连接您的商店。如果您希望在一个地方配置订单通知和目录消息，而且不想开发，这会更方便。 - EasyCoexistence:: 商务逻辑在您的商店内运行。我们把 WhatsApp 事件发送到您的后端，因此订单通知由已经了解订单状态的系统发出。无需将任何内容同步到第二个产品。 ### 代理商要付多少钱 这是按坐席收费和按号码收费差异最大的一点。 - Interakt:: 方案设有坐席和联系人数量限制，因此为多个客户管理号码的企业，需要为每个账户购买席位和额度。 - EasyCoexistence:: 一个账户可以容纳任意数量的客户号码，每个号码按连接收费，量越大单价越低。无需计算坐席，也不会超出联系人额度。 ### 账单按什么计算 这是结构上的差异，也是业务扩大后决定总费用的一点。 - Interakt:: 订阅围绕用户和方案等级设计，因此账单跟随团队规模和已解锁的功能，不论席位是否使用都要付费。 - EasyCoexistence:: 账单按已连接号码计算。添加同事无需付费，因为没有席位；添加的号码越多，单号码费率越低，从 US$ 9 降至 US$ 1。代理商的第 40 个号码与第 1 个号码功能相同，而且费用更低。 ### 离开后会怎样 凡是承载您对话的产品，都值得问这一点。 - Interakt:: 收件箱、联系人历史记录和自动化功能都保存在平台内。这正是它们能够运行的原因，也意味着离开时需要进行迁移。 - EasyCoexistence:: 您的任何资料都不在我们这里。消息到达时就已发送到您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍在原来的位置。 - 没有根据自身业务规模，计算双方的席位费用和号码费用，就直接比较单价。 - 团队已经在 CRM 中工作，却仍为收件箱付费。 - 以为 WhatsApp 连接方式不同。两种方案底层使用的都是 Meta 的 Cloud API。 **哪一个更便宜？** 取决于业务规模。一个收件箱内有 5 人的团队可能更适合席位收费。拥有多个号码且已有系统的企业，使用我们按号码收费会便宜得多。 **我会失去共享收件箱吗？** 您根本无需迁移到共享收件箱。消息会到达团队已经使用的工具，团队也会继续在那里工作。 **WhatsApp 连接方式不同吗？** 不不同。两者使用的都是 Meta 的 Cloud API。不同之处在于前端连接的产品，以及计费方式。 **可以发送目录消息吗？** 可以，通过您自己号码上的 Cloud API，并由您自己的系统发送。我们不会为您建立目录，因为您的商店已经有目录。 --- ## EasyCoexistence 与 DoubleTick 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-doubletick DoubleTick 是按用户收费的 WhatsApp 销售平台，以移动端优先的共享收件箱为核心。EasyCoexistence 是基础设施：通过 Meta 自有的 Coexistence 连接号码，把消息送到您现有的系统，并按已连接号码收费。若您已有系统，EasyCoexistence 按号码计费，成本更低；若您要一套供团队直接使用的销售产品，DoubleTick 是不同的产品。 ### 两种产品分别是什么 它们并非针对同一项采购需求，先厘清这一点，比较才有意义。 - DoubleTick:: 围绕移动端共享收件箱、群发消息和商品目录分享打造的 WhatsApp 销售平台，按用户席位收费，面向通过手机工作的销售团队。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 在同一号码上运行，消息事件从 Meta 直接发送到您的 CRM、客服系统、自动化工具或 AI 代理。团队无需迁移到另一套产品。 ### 销售团队日常如何工作 这是两种产品背后的采购决定。 - DoubleTick:: 在他们的应用中使用，共享收件箱、商品目录和群发功能都在那里运行；方案每月约 2,500 卢比起，按用户收费，因此账单会随销售人员数量变化。 - EasyCoexistence:: 在团队已经使用的 CRM 中工作。我们把对话送到那里，销售人员可以在交易记录旁查看 WhatsApp，而不是打开另一套独立应用。 ### 增加第二个号码要花多少 对于拥有多条线路的销售业务，这是常见问题。 - DoubleTick:: 席位是计费单位，因此增加第二个号码时，还要承担随团队扩大而增加的按用户订阅费用。 - EasyCoexistence:: 第二个号码就是第二个号码，按公布费率计费；添加更多号码后，单价会下降。人数完全不影响计算。 ### 账单随什么变化 这是结构上的差异，也是业务增长后决定总费用的因素。 - DoubleTick:: 订阅围绕用户和方案层级设计，因此账单会随团队规模和已解锁功能变化；无论席位是否使用，都需要付费。 - EasyCoexistence:: 计费单位是已连接号码。增加同事无需付费，因为没有席位；增加号码后，单号码费率会从 US$ 9 降至 US$ 1。代理商的第 40 个号码具备与第 1 个相同的功能，费用更低。 ### 停止使用后会怎样 凡是承载您对话的产品，都值得问清楚这一点。 - DoubleTick:: 收件箱、联系人记录和自动化功能都在该平台中运行。这正是它们能工作的原因，也意味着离开时需要进行迁移。 - EasyCoexistence:: 您的内容不会存放在我们这里。消息到达时就已送入您的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍在原处。 - 不先按自身情况计算两边的总量，就直接比较席位价格和号码价格。 - 团队已经在 CRM 中工作，却仍为收件箱付费。 - 误以为 WhatsApp 连接不同。两边底层使用的都是 Meta 的 Cloud API。 **哪一个更便宜？** 如果 5 人团队只用单一收件箱，按席位计费可能更合适；如果企业有多个号码并已有系统，使用我们按号码计费，费用会低得多。 **我会失去共享收件箱吗？** 您无需迁移到共享收件箱。消息会到达团队已经使用的工具，团队也会继续在那里工作。 **WhatsApp 连接方式不同吗？** 不不同。两边使用的都是 Meta 的 Cloud API。不同之处在于前端连接的内容，以及计费方式。 **有移动应用吗？** 我们提供的是基础设施，因此团队继续使用现有应用。WhatsApp Business 应用也会在整个过程中继续在手机上运行。 --- ## EasyCoexistence 与 Zoko https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-zoko Zoko 是面向 Shopify 商店的 WhatsApp 商务平台，按月套餐销售。EasyCoexistence 是基础设施：通过 Meta 自有的 Coexistence 连接号码，将消息发送到您已经使用的系统，并按已连接号码收费。哪一个更便宜，取决于您是否要购买一个供团队直接使用的产品。 ### 每个产品是什么 它们并不是在争夺同一种购买需求，先说明这一点，比较才有意义。 - Zoko:: 一款紧密围绕 Shopify 构建的 WhatsApp 商务平台，涵盖目录、弃购挽回、订单流程和共享收件箱，按月套餐销售。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一个号码，消息事件从 Meta 直接发送到您的 CRM、客服系统、自动化流程或 AI 代理。您的团队无需迁移到另一个产品中。 ### 如果您是 Shopify 商店 这是诚实的答案，因为这确实是不同的购买需求。 - Zoko:: 正是为此而建。弃购挽回、目录和订单流程都已配置好，无需开发。如果 Shopify 就是您的全部业务，并且希望本周投入使用，这些功能确实有价值。 - EasyCoexistence:: 底层基础设施。如果您的商店不是 Shopify，或业务逻辑位于自己的后端，我们会将 WhatsApp 事件发送给它，由您的系统决定消息的含义。我们没有的平台，也就没有需要围绕它配置的内容。 ### 当商店不是全部业务时会怎样 这是面向商店的平台开始不再适用的情况。 - Zoko:: 专注于一个生态系统的深度，这是专业产品作出的取舍，也是它在该生态系统内运行良好的原因。 - EasyCoexistence:: 不受生态系统影响。Webhook 会发送到您的端点，因此同一个连接可以服务 Shopify 商店、自定义后端、n8n 工作流或 AI 代理，而无需改变号码的连接方式。 ### 账单按什么计算 这是结构上的差异，也是业务增长后决定总费用的因素。 - Zoko:: 围绕用户和套餐层级设计的订阅，因此账单会随团队规模和已解锁功能变化，无论席位是否使用都要付费。 - EasyCoexistence:: 按已连接号码计费。添加同事无需付费，因为没有席位；增加号码后，每个号码的费率还会下降，从 US$ 9 降至 US$ 1。代理商的第 40 个号码与第 1 个号码功能相同，费用却更低。 ### 如果您离开，会发生什么 任何承载您对话的产品，都值得问这个问题。 - Zoko:: 收件箱、联系人记录和自动化流程都位于该平台中。这正是它们能够运行的原因，也意味着离开时需要进行迁移。 - EasyCoexistence:: 您的任何内容都不在我们这里。消息到达时就已发送到您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍在原来的位置。 - 没有根据自己的业务规模，同时计算席位费和按号码收费后就进行比较。 - 团队已经在 CRM 中工作，却仍为收件箱付费。 - 误以为 WhatsApp 连接不同。两者底层使用的都是 Meta 的 Cloud API。 **哪一个更便宜？** 这取决于业务规模。5 人团队使用一个收件箱时，可能更适合按席位收费。如果企业有多个号码和现有系统，通过我们按号码付费会便宜得多。 **我会失去共享收件箱吗？** 您不需要迁移到共享收件箱。消息会到达团队已经使用的工具，团队也会继续在那里工作。 **WhatsApp 连接不同吗？** 不不同。两者使用的都是 Meta 的 Cloud API。区别在于前端连接的内容，以及计费方式。 **我使用 Shopify，应该选择 Zoko 吗？** Zoko 按月套餐销售已配置的 Shopify 流程。如果您的逻辑已经位于自己的商店或后端，我们可以按每个号码 US$ 9 的价格将 WhatsApp 接入其中，您仍可在订单数据所在的位置保留这些流程。 --- ## EasyCoexistence 与 Trengo https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-trengo Trengo 是一个多渠道团队收件箱，涵盖 WhatsApp、电子邮件、语音和聊天，按用户收费。EasyCoexistence 是基础设施：通过 Meta 自有的 Coexistence 功能连接号码，将消息传送到您现有的系统，并按已连接号码收费。对于已有系统并按号码使用的企业，EasyCoexistence 更便宜；需要多渠道收件箱的团队购买的是不同产品。 ### 每个产品是什么 它们争取的不是同一笔采购，明确这一点后，比较才有意义。 - Trengo:: 一个多渠道团队收件箱，把 WhatsApp、电子邮件、在线聊天、语音和社交渠道整合到一个视图中，按用户席位收费，面向同时处理多个渠道的支持团队。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一个号码，消息事件从 Meta 直接发送到您的 CRM、帮助台、自动化流程或 AI 代理。您的团队无需转移到另一个产品中。 ### 每个渠道一个收件箱 这是他们的核心承诺，对于合适的团队来说确实有效。 - Trengo:: 电子邮件、WhatsApp、聊天和语音集中在一个地方，并提供共享分配和规则。对于在多个标签页之间疲于切换的支持团队，这种整合就是产品本身，而且确实好用。 - EasyCoexistence:: 我们只处理一个渠道，也不要求您进行整合。如果您的帮助台已经处理电子邮件和聊天，WhatsApp 会通过 Webhook 到达那里，您的团队无需学习第二个工具。 ### 团队扩大后要支付什么 按席位收费有固定的增长方式，招聘前值得先看清楚。 - Trengo:: 按用户收费，因此每增加一名支持人员，月费就会上升，无论他是否处理 WhatsApp。 - EasyCoexistence:: 按号码收费。两人的支持团队和二十人的支持团队支付相同费用，因为计费单位是连接，而不是人员。 ### 账单跟随什么变化 这是结构上的差异，也是业务增长后决定总成本的因素。 - Trengo:: 围绕用户和方案等级设置订阅，因此账单会随着团队规模和解锁的功能变化，无论席位是否实际使用，都需要付费。 - EasyCoexistence:: 按已连接号码收费。增加同事不会产生费用，因为没有席位；随着号码增加，每个号码的费率也会下降，从 US$ 9 降至 US$ 1。代理商的第 40 个号码能完成与第 1 个号码相同的工作，而且成本更低。 ### 离开后会发生什么 任何承载您对话的平台，都值得问清楚这一点。 - Trengo:: 收件箱、联系人历史记录和自动化流程都存在平台中。这正是它们能够运作的原因，也意味着离开时需要进行迁移。 - EasyCoexistence:: 您的任何内容都不在我们这里。消息到达时就已传送到您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍会留在原处。 - 比较席位价格和按号码价格，却没有按自己的实际情况计算两者。 - 团队已经在 CRM 中工作，却仍然为一个收件箱付费。 - 以为 WhatsApp 连接方式不同。两种方案底层使用的都是 Meta 的 Cloud API。 **哪个更便宜？** 如果您已有系统并按号码使用，EasyCoexistence 更便宜。需要多渠道收件箱的团队购买的是按席位收费的不同产品。 **我会失去共享收件箱吗？** 您无需转移到共享收件箱。消息会到达团队已经使用的工具，您也会继续在那里工作。 **WhatsApp 连接方式不同吗？** 不不同。两种方案使用的都是 Meta 的 Cloud API。不同之处在于前端连接的产品，以及计费方式。 **我还需要电子邮件和聊天。你们支持吗？** 不支持，而且我们也不会为此收费。我们只把 WhatsApp 连接到已经处理其他渠道的帮助台。 --- ## EasyCoexistence 与 Rasayel 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-rasayel Rasayel 是以 WhatsApp 为核心、支持 CRM 集成的销售收件箱，按用户收费。EasyCoexistence 是基础设施：通过 Meta 自有的 Coexistence 功能连接号码，将消息送入您现有的系统，并按已连接号码收费。哪一个更便宜，取决于您是否需要一个供团队使用的产品。 ### 每个产品是什么 它们并不是在争夺同一笔购买需求，明确这一点能让比较更有用。 - Rasayel:: 以 WhatsApp 为核心、为销售团队打造的共享收件箱，支持与 HubSpot、Pipedrive 等 CRM 双向集成，按用户席位收费。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 在同一号码上运行，消息事件从 Meta 直接发送到您的 CRM、服务台、自动化工具或 AI 代理。您的团队无需转移到另一个产品中。 ### 将 WhatsApp 接入 CRM 这是两种产品最接近的重叠点，需要准确说明。 - Rasayel:: 他们的收件箱会将对话同步到 CRM，因此销售人员可以在任一处工作，记录也会随之同步。这是真正的产品，背后有实际的工程支持。 - EasyCoexistence:: 消息从 Meta 直接发送到您的 CRM，中间没有收件箱需要同步。对话只有一份，而不是两份，同步失败时也无需重新核对。 ### 您付费购买的是什么 两者都会将 WhatsApp 送入 CRM，但账单的计算方式不同。 - Rasayel:: 席位，因为收件箱就是产品，每位销售人员都需要一个席位才能在其中工作。 - EasyCoexistence:: 连接。整个销售团队都能在已经付费使用的 CRM 中阅读 WhatsApp，无论团队有多少人，我们都按号码收费。 ### 账单跟随什么变化 这是结构上的差异，也是业务增长后决定总费用的因素。 - Rasayel:: 围绕用户和套餐级别设置的订阅，因此账单会跟随团队规模和已解锁的功能变化，无论席位是否使用都要付费。 - EasyCoexistence:: 已连接号码。增加同事不会产生费用，因为没有席位；随着号码增加，每个号码的费率也会下降，从 US$ 9 降至 US$ 1。代理机构的第 40 个号码能做与第 1 个号码相同的事，费用还更低。 ### 如果您离开，会发生什么 任何承载您对话的产品，都值得问这个问题。 - Rasayel:: 收件箱、联系人历史记录和自动化流程都存在于该平台中。正因为如此它们才能运行，但离开也会变成一个迁移项目。 - EasyCoexistence:: 您的任何内容都不在我们这里。消息到达时就已送入您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍在原处。 - 比较席位价格和按号码收费的价格，却没有按您自己的使用规模分别计算。 - 团队已经在 CRM 中工作，却仍为收件箱付费。 - 以为 WhatsApp 连接不同。两种情况下底层都是 Meta 的 Cloud API。 **哪一个更便宜？** 这取决于使用规模。一个收件箱内有 5 人的团队可能更适合按席位收费。拥有多个号码且已有系统的企业，通过我们按号码付费，费用会低得多。 **我会失去共享收件箱吗？** 您根本无需转移到共享收件箱。消息会到达团队已经使用的工具，团队也会继续在那里工作。 **WhatsApp 连接不同吗？** 不不同。两者使用的都是 Meta 的 Cloud API。不同之处在于前端连接的是什么，以及如何收费。 **你们支持与 HubSpot 集成吗？** 我们会将 Meta 的 Webhook 发送到任何端点，因此带有入站 Webhook 的 CRM，或位于 CRM 前面的工作流工具，都能直接接收对话。 --- ## EasyCoexistence 与 Callbell https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-callbell Callbell 是面向小型团队的多客服 WhatsApp 消息收件箱，按用户收费。EasyCoexistence 属于基础设施，通过 Meta 自有的 Coexistence 将号码连接起来，把消息发送到您已经使用的系统，并按已连接号码收费。两者适合不同需求：如果您要直接使用现成产品，Callbell 可能更合适；如果您已有系统，EasyCoexistence 通常更省钱。 ### 两种产品分别是什么 两者并不是在争夺同一种购买需求，先厘清这一点，比较才有意义。 - Callbell:: 面向小型团队的多客服 WhatsApp 消息收件箱，提供聊天机器人流程和基本自动化，按用户席位收费，在拉丁美洲和南欧的小型企业中较常见。 - EasyCoexistence:: Coexistence 基础设施。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一个号码，消息事件从 Meta 直接发送到您的 CRM、客服系统、自动化工具或 AI 代理。您的团队无需迁移到另一个产品中。 ### 小型团队的情况 这是对方定价最合理、双方比较最接近的情况。 - Callbell:: 两三名客服共用一个号码，只需要简单的消息收件箱，也没有要整合的 CRM。对方按用户每月收费，WhatsApp 还要另加费用，因此即使团队很小，也同时承担席位费用和渠道费用。 - EasyCoexistence:: 同一家企业如果已经有系统，情况就不同。使用电子表格或简单后端处理订单的小店，可以用低于一个席位的费用接入 WhatsApp，员工也能像往常一样继续在 WhatsApp Business 应用中回复。 ### 多个地点，一个账户 这是最能清楚区分两者的情况。 - Callbell:: 每个号码和每名客服都属于订阅范围，因此连锁店需要同时购买席位和号码。 - EasyCoexistence:: 每个地点都是一个连接，按公布费率收费，连接越多，单价越低。10 家店使用 10 个号码、共 40 名员工时，只需支付 10 个号码的费用。 ### 账单按什么计算 这是两者的结构性差异，也是业务增长后决定总费用的因素。 - Callbell:: 订阅围绕用户和方案等级设计，因此账单会随着团队规模和已解锁功能变化，无论席位是否实际使用，都需要付费。 - EasyCoexistence:: 按已连接号码收费。增加同事无需额外付费，因为没有席位费用；连接越多，每个号码的费率越低，从 US$ 9 降至 US$ 1。代理商的第 40 个号码与第 1 个一样完整，费用还更低。 ### 如果停止使用会怎样 任何承载您对话的产品，都值得问清楚这一点。 - Callbell:: 消息收件箱、联系人历史记录和自动化流程都保存在该平台中。这正是它们能够运行的原因，也意味着离开时需要进行迁移。 - EasyCoexistence:: 您的资料不存放在我们这里。消息到达时就已经发送到您自己的系统，号码也位于客户自己的 Meta Business Portfolio 中，因此移除我们后，一切仍留在原来的位置。 - 不按自己的实际情况，同时计算席位费用和号码费用，就直接比较两种价格。 - 团队已经在 CRM 中工作，却仍然为另一个消息收件箱付费。 - 以为 WhatsApp 连接方式不同。两者底层使用的都是 Meta 的 Cloud API。 **哪一个更便宜？** 如果 5 人团队只需一个消息收件箱，按席位收费的 Callbell 可能更合适；如果企业有多个号码和现成系统，EasyCoexistence 按号码收费，费用会低得多。 **我会失去共享消息收件箱吗？** 您不需要迁移到共享消息收件箱。消息会到达团队已经使用的工具，员工也能继续在那里工作。 **WhatsApp 连接方式不同吗？** 不不同。两者使用的都是 Meta 的 Cloud API。不同之处在于前端连接的产品，以及收费方式。 **两名客服使用时，Callbell 更便宜吗？** 如果只有一个号码且没有现成系统，Callbell 可能更省钱。但增加第二个地点或接入 CRM 后，EasyCoexistence 的按号码收费很快会更划算。 --- ## EasyCoexistence 与 Baileys https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-baileys Baileys 是一个开源库，通过直接实现设备连接协议来连接 WhatsApp。它确实能用，免费或成本低，但也带来官方方式没有的风险：WhatsApp 商业条款并未提供通过设备连接会话自动发送消息的途径，以这种方式使用的号码可能在没有警告的情况下被限制或封禁。EasyCoexistence 则通过 Meta 自有的 Coexistence 功能连接同一号码。 ### 每种方式如何连接 WhatsApp 整个比较的关键就在这里，其他差异都由此产生。 - Baileys:: 一个通过 websocket 实现 WhatsApp 设备连接协议的 TypeScript 库。它像网页客户端一样，通过扫描二维码登录，然后自行维持会话。由于没有向 Meta 发起请求，因此不涉及 Meta 审批。 - EasyCoexistence:: Meta 的 Cloud API 通过 Coexistence 运行，并使用 Meta 为客户自己的 WhatsApp Business 账户签发的凭据。号码会在 Meta 注册为 API 号码，同时 WhatsApp Business 应用仍可在手机上继续使用。 ### 出问题时会发生什么 两者有时都会中断，区别在于是否有人可以联系。 - Baileys:: GitHub 上的社区项目。当 WhatsApp 更改协议时，库必须跟上，在此之前您的集成都会中断。没有支持合约，也没有封禁申诉渠道。 - EasyCoexistence:: 运行在 Meta 自有基础设施上的连接会持续受到监控。连接中断时，我们会读取 Meta 提供的断开原因，因此可以区分 14 天没有活动和真正被移除的情况，并在客户发现前通知您。 ### 实际费用是多少 非官方方式通常看起来免费，但真正的比较并不在许可费用。 - Baileys:: 库本身免费，但您还需要服务器、持续维持的会话，以及了解它的工程师。成本主要来自维护和风险，而不是许可费。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，包含托管、监控和 MCP 连接器。无需运行服务器，无需重新连接会话，也无需在协议更改时重建系统。 ### 每种方式实际能做什么 这是最坦诚的部分，也是非官方项目存在的原因。 - Baileys:: 在某些方面比官方 API 做得更多：协议层面支持群聊、个人对话、在线状态和已读回执。这种覆盖范围正是它存在的原因。 - EasyCoexistence:: 支持 Cloud API 允许的一切功能：发送和接收消息、消息模板、媒体和互动消息，并由 Meta 传送 Webhook。群聊不在 API 支持范围内，自由格式回复需要保持 24 小时窗口开放。这些是 Meta 的规则，适用于所有官方服务商。 ### 谁应该选择哪一种 两种方式都有真实使用场景，完全取决于这个号码对您的价值。 - 用于您不介意失去的号码上的个人项目：非官方方式免费且功能丰富。 - 企业用来回复客户的号码：选择官方方式，因为封禁会终止业务线路。 - 涉及客户号码的任何项目：选择官方方式，因为不应由您承担这个风险。 - 必须让 WhatsApp Business 应用继续在手机上运行的场景：选择 Coexistence，这正是我们的服务。 - 在企业号码上测试非官方桥接。封禁会在没有警告、也没有申诉渠道的情况下发生。 - 把多年稳定运行当成安全证明。执行检查是周期性的，不是持续进行的。 - 以为封禁只会影响 API。WhatsApp Business 资料也会一起受到影响。 **Baileys 真的能用吗？** 能，这正是它受欢迎的原因。问题不在于它能否运行，而在于 WhatsApp 发现后会如何处理这个号码。 **号码会因此被封禁吗？** 会。WhatsApp 商业条款并未提供非官方访问，而执行检查不会提前警告，也没有申诉渠道。 **使用您的服务后，我的 WhatsApp Business 应用会停止运行吗？** 不会。这正是 Coexistence 的作用：手机上的应用继续运行，同时 Cloud API 在同一号码上运行。 **Baileys 违法吗？** 这不是犯罪，而是 WhatsApp 商业条款并未提供的途径。后果是对号码采取执行措施，而不是法律行动。 --- ## EasyCoexistence 与 WPPConnect https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-wppconnect WPPConnect 是一个开源项目，通过受控浏览器会话自动化 WhatsApp Web。它确实能运行，免费或成本低，但也带来官方路径没有的风险：WhatsApp 商业条款并未提供通过设备连接会话自动发送消息的途径，以这种方式使用的号码可能在没有警告的情况下被限制或封禁。EasyCoexistence 则通过 Meta 自己的 Coexistence 功能连接同一个号码。 ### 两者如何连接 WhatsApp 整个比较的关键就在这里，其他差异都由此产生。 - WPPConnect:: 一个在无界面会话中运行 WhatsApp Web 的浏览器自动化项目，外加 REST 封装。号码通过二维码连接，会话保存在浏览器配置文件中，因此 WhatsApp 看到的是已连接设备，而不是 API 客户端。 - EasyCoexistence:: Meta 的 Cloud API 通过 Coexistence 运行，凭据由 Meta 发给客户自己的 WhatsApp Business 账户。号码会在 Meta 注册为 API 号码，同时 WhatsApp Business 应用继续在手机上使用。 ### 出问题时会发生什么 两者偶尔都会中断，差别在于是否有人可以协助您。 - WPPConnect:: 一个活跃且响应迅速的开源社区，但不对任何人承担义务。WhatsApp Web 改动可能破坏会话处理；由于这种访问从未获认可，被封禁后也没有申诉途径。 - EasyCoexistence:: 连接运行在 Meta 自己的基础设施上，并持续受到监控。连接中断时，我们会读取 Meta 提供的断开原因，因此可以区分 14 天不活动和真正移除，并在客户发现前通知您。 ### 实际成本是多少 非官方路径通常看起来是免费的，但比较重点并不只是许可费用。 - WPPConnect:: 免费，但您仍需要一台能持续运行浏览器的服务器、为每个会话准备的内存，以及在会话失效时重新启动它的人。多个号码会放大这些成本。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，包含托管、监控和 MCP 连接器。无需运行服务器，无需重新连接会话，协议变更时也无需重建。 ### 两者实际能做什么 这是最坦诚的一点，也是非官方项目存在的原因。 - WPPConnect:: WhatsApp Web 能做的事情都可以做，包括群组和个人聊天，实际功能范围确实比官方 API 更广。但因为链路中有浏览器，速度更慢，资源占用也更高。 - EasyCoexistence:: Cloud API 允许的一切功能：发送和接收消息、消息模板、媒体和互动消息，并由 Meta 交付 Webhook。群组聊天不在 API 范围内，自由格式回复则需要保持 24 小时窗口开放。这些是 Meta 的规则，适用于所有官方服务提供商。 ### 应该选择哪一个 两者都有合理的使用场景，完全取决于这个号码对您的价值。 - 用于您不介意失去的号码上的个人项目：非官方路径免费且功能丰富。 - 企业用来回复客户的号码：选择官方路径，因为封禁会终止业务线路。 - 任何使用客户号码的场景：选择官方路径，因为风险不应由您承担。 - WhatsApp Business 应用必须继续在手机上运行的场景：选择 Coexistence，这正是我们的方案。 - 在企业号码上测试非官方桥接。封禁来得毫无警告，也没有申诉途径。 - 把多年正常运行时间当成安全证明。监管是周期性的，不是持续进行的。 - 以为封禁只影响 API。WhatsApp Business 资料也会一并受到影响。 **WPPConnect 真的能运行吗？** 能，所以它很受欢迎。问题不在于它能否运行，而在于 WhatsApp 发现后，这个号码会发生什么。 **号码会因此被封禁吗？** 会。WhatsApp 的商业条款并未提供非官方访问，而监管不会提前警告，也没有申诉途径。 **使用你们的服务后，我的 WhatsApp Business 应用会停止运行吗？** 不会。这正是 Coexistence 的作用：手机上的应用继续运行，同时 Cloud API 使用同一个号码。 **为什么它在巴西很受欢迎？** 它较早进入市场，文档使用葡萄牙语，而且免费，因此成为一代本地集成的默认选择。 --- ## EasyCoexistence 与 Evolution API 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-evolution-api Evolution API 是一个开源 REST API，将非官方 WhatsApp 库封装在简洁的接口后面。它确实能运行，而且免费或价格低廉，但也带来官方方式没有的风险：WhatsApp 商业条款并未提供通过设备连接会话自动发送消息的途径，以这种方式使用的号码可能在没有预警的情况下被限制或封禁。EasyCoexistence 则通过 Meta 自家的 Coexistence 功能连接同一个号码。 ### 两者如何连接 WhatsApp 整个对比的核心就在这里，其他差异都由此产生。 - Evolution API:: 自行托管的 REST API 和管理器，将关联设备库封装在简洁的接口后面，并提供控制台、多实例支持和 Webhook。开发体验不错，但每个实例底层仍然是通过二维码关联的设备。 - EasyCoexistence:: Meta 的 Cloud API 通过 Meta 为客户自己的 WhatsApp Business 账户签发的凭据运行，并使用 Coexistence。号码会在 Meta 注册为 API 号码，同时 WhatsApp Business 应用仍可在手机上继续使用。 ### 出问题时会发生什么 两者有时都会中断，差别在于是否有人可以提供支持。 - Evolution API:: 这是一个活跃的开源项目，拥有庞大的社区。接口稳定，但它封装的内容未经认可，因此号码因非官方接入被封禁后，无论封装器构建得多好，号码都无法恢复。 - EasyCoexistence:: 连接运行在 Meta 自家的基础设施上，并持续受到监控。连接中断时，我们会读取 Meta 提供的断开原因，因此可以区分 14 天不活跃和真正的移除，并在客户发现之前通知您。 ### 实际费用是多少 非官方方式通常看起来免费，但真正的比较并不只是许可费用。 - Evolution API:: 许可免费，需要自行托管，因此实际成本是基础设施和维护人员。它的界面让启动成本较低，但不会改变底层性质。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，包含托管、监控和 MCP 连接器。您无需运行服务器，无需重新关联会话，也无需在协议变化时重建系统。 ### 两者实际能做什么 这是最诚实的一部分，也是非官方项目存在的原因。 - Evolution API:: 发送和接收消息、媒体和群组消息；一次部署支持多个实例，并提供 Webhook 和实用的控制台。对于开发者来说，这是目前最易用的非官方选项。 - EasyCoexistence:: Cloud API 允许的一切功能：发送和接收消息、消息模板、媒体和互动消息，并由 Meta 投递 Webhook。群聊不在 API 范围内，自由格式回复需要保持 24 小时窗口开放。这些是 Meta 的规则，适用于所有官方服务商。 ### 应该选择哪一种 两者都有实际适用场景，完全取决于这个号码对您的价值。 - 用于您不介意失去的号码上的业余项目：非官方方式免费且功能够用。 - 企业用来回复客户的号码：选择官方方式，因为号码被封禁会终止业务线路。 - 任何使用客户号码的项目：选择官方方式，因为风险不应由您承担。 - 任何必须让 WhatsApp Business 应用继续在手机上运行的场景：选择 Coexistence，这正是我们的方案。 - 在企业号码上测试非官方桥接。封禁会在没有预警、也没有申诉渠道的情况下发生。 - 把多年正常运行的时间当作安全证明。执法是周期性的，不是持续进行的。 - 以为封禁只会影响 API。WhatsApp Business 资料也会一并受到影响。 **Evolution API 确实能运行吗？** 可以，所以它很受欢迎。问题不在于它能否运行，而在于 WhatsApp 发现后会如何处理这个号码。 **号码会因此被封禁吗？** 会。WhatsApp 商业条款并未提供非官方接入，执法不会预警，也没有申诉渠道。 **使用您们的服务后，我的 WhatsApp Business 应用会停止运行吗？** 不会。这正是 Coexistence 的作用：手机上的应用继续运行，同时 Cloud API 在同一个号码上运行。 **它看起来很专业，会更安全吗？** 不会。它的界面比大多数选项更好，但封装的仍是相同的关联设备接入方式，执法针对的是号码，而不是封装器。 --- ## EasyCoexistence 与 Whapi https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-whapi Whapi 是提供 WhatsApp 访问的托管服务，通过非官方网关运行。它确实可用，且免费或价格低，但存在官方路径没有的风险：通过这种方式访问的号码违反 WhatsApp 条款，可能在没有警告的情况下被封禁。EasyCoexistence 则通过 Meta 自己的 Coexistence 功能连接同一个号码。 ### 两者如何连接 WhatsApp 这就是整个比较的核心，其他一切都由此而来。 - Whapi:: 带 REST API 和付费方案的托管网关。便利性确实存在：您无需运行服务器，也无需维护库。但在底层，号码仍作为设备连接，而不是作为 API 号码向 Meta 注册。 - EasyCoexistence:: Meta 的 Cloud API 通过 Meta 为客户自己的 WhatsApp Business 账户签发的凭据运行，并通过 Coexistence 连接。号码会作为 API 号码向 Meta 注册，WhatsApp Business 应用也会继续在手机上同时运行。 ### 出问题时会怎样 两者有时都会中断。区别在于您是否有对象可以求助。 - Whapi:: 提供支持的商业服务商，这比开源库能提供的服务更多。但支持无法撤销封禁，因为该访问从未获 Meta 认可，也没有相应的申诉渠道。 - EasyCoexistence:: 连接运行在 Meta 自己的基础设施上，并持续受到监控。连接中断时，我们会读取 Meta 提供的断开原因，因此可以区分 14 天不活跃和真正被移除的情况，并在客户发现前通知您。 ### 实际费用是多少 非官方路径通常看起来是免费的，但真正的比较并不在许可费用。 - Whapi:: 按月收费，因此不是开源路径那种低价选项。您支付的是便利性，同时承担免费工具带来的风险。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，包含托管、监控和 MCP 连接器。您无需运行服务器，无需重新连接会话，也无需在协议变化时重建任何内容。 ### 两者实际上能做什么 这是最诚实的部分，也是非官方项目存在的原因。 - Whapi:: 通过整洁的 REST API 发送和接收消息、媒体、群组消息及个人聊天，无需运行任何基础设施。逐项比较，它的功能范围比官方 API 更广。 - EasyCoexistence:: Cloud API 允许的一切功能：发送和接收消息、模板、媒体及互动消息，并由 Meta 交付 Webhook。群组聊天不在 API 范围内，自由格式回复需要处于 24 小时窗口内。这些是 Meta 的规则，适用于每一家官方服务商。 ### 谁应该选择哪一种 两者都有合理的使用场景，完全取决于这个号码对您的价值。 - 用于您不介意失去的号码的个人项目：非官方路径免费且功能足够。 - 企业用来回复客户的号码：选择官方路径，因为封禁会终止业务线路。 - 任何包含客户号码的项目：选择官方路径，因为这种风险不应由您承担。 - WhatsApp Business 应用必须继续在手机上运行的场景：选择 Coexistence，这正是我们的方案。 - 在企业号码上测试非官方桥接。封禁可能毫无预警，也没有申诉渠道。 - 把多年的正常运行时间当成安全证明。执法是周期性的，并非持续进行。 - 以为封禁只影响 API。WhatsApp Business 资料也会一并受到影响。 **Whapi 真的能用吗？** 可以，所以它很受欢迎。问题不在于它是否能用，而在于 WhatsApp 发现后会如何处理这个号码。 **号码会因此被封禁吗？** 会。非官方访问违反 WhatsApp 的商业条款，执法不会提前警告，也没有申诉渠道。 **使用您们的服务后，我的 WhatsApp Business 应用会停止运行吗？** 不会。这正是 Coexistence 的作用：手机上的应用继续运行，同时 Cloud API 在同一个号码上工作。 **它需要付费，所以获得 Meta 认可了吗？** 没有。向第三方付费不会让访问获得认可。只有 Meta 为该号码签发凭据才代表获得认可，而 Coexistence 正是这样做的。 --- ## 最佳 WhatsApp Coexistence 服务商 https://easycoexistence.com/zh-hans/compare/best-whatsapp-coexistence-providers 名单不长，因为 Coexistence 比 WhatsApp API 行业更新，大多数服务商仍不支持。这些是目前支持的服务商，以及各自收费和适用的业务类型。 ### 1. EasyCoexistence，适合只要连接功能的企业或代理机构 我们把自己排在首位，因此请阅读后文并核对来源。这个判断范围明确，也可以核查：本文列出的公开起步价最低，按号码收费，不设席位或方案等级；消息事件由 Meta 直接送达您自己的系统，而不是进入另一个收件箱；持续监控会读取 Meta 提供的断开原因；另有 MCP 连接器，让 AI 助手可以执行整套流程。 - 每个已连接号码每月 US$ 9 起，随号码增加降至 US$ 1。 - 不设席位，不签合约，不收设置费，免费试用 3 天。 - 零加价：Meta 直接向客户收取对话费用。 - 通过 OAuth 提供 16 个 MCP 工具，支持 Claude、ChatGPT、Cursor 和 Claude Code。 ### 2. YCloud，适合想要完整平台的团队 定位上最接近的替代方案：他们公开支持 Coexistence，并承诺 WhatsApp 消息零加价，这正是最重要的两点。差别在于收费。他们的付费方案每月 US$ 39 起，按用户席位、频道和 AI 积分计费，还没计算任何号码。我们的方案按每个已连接号码 US$ 9 起，不设席位或积分，因此拥有 1 至 3 个号码的企业只需支付其中一小部分；拥有 40 个号码的代理机构，费率则降至 US$ 5。 ### 3. SleekFlow，适合依赖共享收件箱的团队 他们把 Coexistence 列为解决方案之一，产品是带有营销活动和自动化功能的全渠道收件箱，按用户席位收费，并设有最低席位数，新增 WhatsApp 号码还要另行付费。这种模式适合希望所有人集中工作的销售或支持团队。对于多地点企业则不太合适，因为席位和号码附加费都会增加您的成本。 ### 4. 8x8，适合已经采购通信服务的大型企业 他们关于 Coexistence 的文档是所有服务商中最清楚的，无论您选择谁，包括我们，都值得阅读。该产品属于企业级 CPaaS，与联络中心和语音服务一起销售，通过客户团队和商业安排提供。如果您已经在整合通信支出，这种模式很合适。若只是为一个号码接入 Webhook，这会是较重的做法。 ### 5. Dualhook，直接的专业服务商 他们采用与我们相同的架构：Coexistence 配合来自 Meta 的 Webhook 直连，不储存消息，并公布价格。他们公布的价格是每个号码 US$ 12，而我们是 US$ 9；他们在 13 天时发出提醒，说明计时正在进行，而不是读取 Meta 提供的断开原因；其文档也没有说明 MCP 连接器。 ### 签约前应向任何一家服务商询问什么 以下 4 个问题可以区分名单上的服务商，而销售页面本身不会回答这些问题。 - 号码是否留在我自己的 Meta Business Portfolio 中，费用是否由 Meta 直接向我收取？ - 您是否按消息另行收费？这笔费用是否与 Meta 的费用分开列明？ - 重新连接后，您是否会重新应用 Webhook override？还是会让消息传送在没有提示的情况下停止？ - 对于 14 天不活跃规则，您会如何处理？是否会读取 Meta 提供的断开原因？ - 只按功能数量选择。Coexistence 是 Meta 的机制，因此底层平台在各家都相同。 - 因为服务商支持 WhatsApp，就假定它支持 Coexistence。大多数服务商仍不支持。 - 比较席位价格和按号码收费的价格时，没有按您的实际使用方式同时计算两者。 **为什么把自己排在名单首位？** 因为我们认为这个定位经得起核查：本文列出的公开起步价最低，不设席位，零加价，并包含监控。所有数字都有来源，请自行核对。 **哪些服务商支持 Coexistence？** 比普遍支持 WhatsApp 的服务商少得多。名单上的服务商都在自己的网站上说明支持，大多数 WhatsApp API 服务商仍未提供这项功能。 **服务商会改变 Coexistence 能做的事情吗？** 不会。这项功能属于 Meta，因此各家的限制都相同：同样的 4 项被禁用功能、同样的 14 天规则，而且不支持群组聊天。 **哪种方案最便宜？** 我们的方案按公开起步价计算最便宜，而且号码越多，差距越大，因为我们的按号码费率会下降，而席位费和方案价格不会。 --- ## 最佳 WhatsApp Cloud API 提供商 https://easycoexistence.com/zh-hans/compare/best-whatsapp-cloud-api-providers 这里的每家提供商连接的都是同一个 Cloud API，因为它属于 Meta，而且只有一个。不同之处在于收费方式，清晰分为 3 类：按消息收费、按席位收费，或按已连接号码收费。 ### 3 种收费模式，真正需要选择的是什么 由于底层 API 完全相同，功能列表看起来很接近。但账单计算方式并不相同，而且会决定您的业务增长后要支付多少费用。 - 按消息收费：每条消息都收取费用，因此业务越成功，成本就按消息量上升。 - 按席位收费：每位用户收取费用，因此团队扩大时成本上升，无论用户是否登录都要付费。 - 按号码收费：每个连接收取费用，号码连接后费用不再随消息量变化。 ### 按消息收费的提供商 这是 CPaaS 类提供商。Twilio 公布的价格是每条入站和出站消息 US$ 0.005，另加 Meta 的费用。Gupshup 公布的标准价格是每条消息 US$ 0.001。Bird 报价为综合费率，已包含 Meta 的费用，因此确实有加价，但无法与 Meta 公布的费率核对。Infobip 按目标国家收费，需要通过销售团队询价。这 4 家都是功能完善的平台，但使用它们后，平台账单都会随消息量变化。 ### 按席位收费的提供商 这是共享收件箱类提供商。SleekFlow、Wati 和 Respond.io 销售带有营销活动和自动化功能的共享收件箱，按用户收费，分为不同方案，部分方案还会按 WhatsApp 号码另收附加费。如果您希望团队整天在一个产品中工作，这种购买方式合适。如果团队已经有 CRM，则不合适，因为无论是否有人打开第二个收件箱，您都要付费。 ### 按号码收费的提供商 这是基础设施类提供商，也是规模最小的一类。EasyCoexistence 每个已连接号码每月 US$ 9 起，随号码增加降至 US$ 1，不收取按消息费用，也不收取席位费。Dualhook 是另一家公开按号码收费的专业提供商。这种模式适合已有系统、希望让 WhatsApp 接入系统的企业，也适合持有许多客户号码的代理机构，因为按号码递减的费率会持续放大节省金额。 ### 这些模式何时交叉 值得计算，不要凭感觉判断，而且算式很简单。 - 按每条消息 US$ 0.005 计算，每月超过约 1,800 条消息后，US$ 9 的按号码费用更便宜。 - 按每条消息 US$ 0.001 计算，交叉点约为每月 9,000 条消息。 - 按席位收费的交叉点取决于人数，而不是消息量，因此应将席位数与号码数进行比较。 - Meta 自行收取的会话费用在所有模式下都相同，不属于本次比较范围。 ### 它们都无法改变的部分 在功能比较影响您的判断前，先了解这一点很重要。 - Cloud API 属于 Meta，因此可靠性和能力由平台决定，而不是由提供商决定。 - 消息模板审核由 Meta 决定，没有任何提供商可以加快审核。 - 质量评级和消息等级由 Meta 根据收件人的行为设定。 - 在支持 Coexistence 的情况下，各家限制都完全相同，因为这项功能属于 Meta。 - 比较宣传中的功能。每家提供商底层使用的都是 Meta 的同一个 API。 - 忽略交叉用量。一分钱的十分之一看似很少，但乘以一整年后就不同了。 - 假设捆绑的按消息费率没有加价。这只表示加价没有单独列出。 **一家提供商的 Cloud API 会比另一家更快吗？** 不会。无论哪一家，使用的都是 Meta 的 API。提供商只能改变 API 前端的内容，以及收取的费用。 **哪种模式最便宜？** 达到适中用量后，按号码收费更便宜。按 Twilio 公布的费率，交叉点约为每月 1,800 条消息；按 Gupshup 的费率，约为每月 9,000 条。 **我一定需要提供商吗？** 如果您要让已经运行 WhatsApp Business 应用的号码接入 Cloud API，则需要。Coexistence 开通需要 Meta Tech Provider。 **谁向我收取消息费用？** 如果您的提供商不转售消息服务，则由 Meta 收取。使用我们的服务时，Meta 会直接向您开票，我们不会加价。 --- ## 最佳 WhatsApp MCP 服务器 https://easycoexistence.com/zh-hans/compare/best-whatsapp-mcp-servers 搜索 WhatsApp MCP 服务器时，大多数结果是开源项目，它们会以已关联设备的方式登录 WhatsApp。这些项目能运行，但会让号码面临风险。真正重要的区别不是功能，而是服务器是否连接 Meta 官方 API。 ### 真正重要的区别 每个 WhatsApp MCP 服务器都位于同一条界线的一侧，而界线与工具数量无关。 - 官方路线：服务器使用 Meta 签发的凭据调用 Meta 的 Cloud API。该路线获批准，号码安全。 - 非官方路线：服务器驱动某个库，以已关联设备的方式登录，方式与网页版客户端相同。 - 非官方路线无需 Meta 批准，因此常见于开源项目。 - 这也违反 WhatsApp 的条款，号码可能因此被封，且没有申诉机会，也不会收到警告。 ### 您会找到的开源项目 GitHub 上的大多数 WhatsApp MCP 服务器都基于 Baileys、WPPConnect 或 Venom 等库构建，这些库通过逆向工程实现已关联设备协议。它们确实很巧妙、免费，并能让助手访问官方 API 无法提供的个人聊天和群组。代价是账户：以这种方式被封的号码会连同 WhatsApp Business 资料一起失效，而且没有支持渠道可供申诉。如果是您愿意失去的个人号码，这种取舍可能说得通。但如果是企业用来回复客户的号码，就不值得。 ### 实际运行一个服务器需要什么 除了风险之外，实际差异还包括人们通常在第 2 天遇到的问题。 - 通常在笔记本电脑上运行的本地服务器进程，必须持续运行，助手才能工作。 - 扫描二维码来关联设备；每当会话中断，都要重新扫描。 - 凭据存放在本地配置文件中，API 访问令牌也会留在那里。 - 笔记本电脑进入睡眠后，您的助手与号码之间就没有连接。 ### EasyCoexistence，官方路线 这是一个通过 OAuth 提供的远程 MCP 服务器，无需安装任何程序，也无需将访问令牌放入配置文件。16 个工具覆盖人们实际会要求助手执行的操作：列出号码、检查号码的连接状态、读取 API 凭据、发送消息、列出、创建和发送消息模板、检查模板状态、将 Webhook 指向您的系统、搜索文档，以及开始新的连接。另有 5 个工具用于设置 Partner API：设置状态、API 密钥、事件 URL 和托管的连接链接。由于服务托管在远程服务器上，无论您的笔记本电脑是否打开，它都能运行。底层号码通过 Coexistence 使用 Meta 官方 Cloud API，因此 WhatsApp Business 应用仍可继续使用，号码也不会面临风险。 ### 官方路线无法做什么 这里直接说明这一点，因为这正是非官方项目存在的原因，您也应在选择前了解。 - 在所有官方提供商中，群组聊天都完全不属于 Cloud API 的范围。 - 无法读取消费者 WhatsApp 账户中的个人对话。 - 自由格式回复只在 24 小时服务窗口内有效；超出窗口后，必须使用获批准的消息模板来开启对话。 - 这些是 Meta 的规则，不是我们的规则，任何官方提供商都无法解除这些限制。 - 只按工具数量评估 MCP 服务器。关键是它连接 Meta 的 API，还是冒充手机。 - 在企业号码上测试非官方桥接。封号不会提前警告，也无法申诉。 - 以为本地服务器就是私密的。将访问令牌放在笔记本电脑的配置文件中，安全性更弱。 **开源 WhatsApp MCP 服务器安全吗？** 它们能运行，并会以已关联设备的方式登录，这违反 WhatsApp 的条款。号码可能因此被封，且不会收到警告。 **官方 MCP 服务器能读取我的群组聊天吗？** 不能。在包括我们在内的所有官方提供商中，群组聊天都不属于 Meta 的 Cloud API 范围。 **我需要安装任何程序吗？** 不需要。我们提供的是通过 OAuth 运行的远程服务器，您只需添加端点并登录。任何程序都不会在您的设备上运行。 **哪些助手可以使用它？** 任何 MCP 客户端都可以。我们提供文档说明的客户端包括 Claude、ChatGPT、Cursor 和 Claude Code。 --- ## EasyCoexistence 与 Twilio 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-twilio Twilio 是通用通信平台，在多个渠道中转售 WhatsApp，并在 Meta 自身收费之外收取公开的按消息费用。EasyCoexistence 只做一件事：通过 Coexistence 连接 WhatsApp Business 应用号码，并按号码收取固定费用。 ### 各自适合什么用途 两种产品针对不同问题，先明确这一点最重要。 - Twilio:: 覆盖 SMS、语音、电子邮件和 WhatsApp 的通信平台，面向需要整合多个渠道的工程团队。WhatsApp 只是众多渠道之一，和其他渠道一样按消息收费。 - EasyCoexistence:: Coexistence 专业产品。手机上的 WhatsApp Business 应用继续运行，Cloud API 使用同一号码，消息事件发送到您自己的端点，我们监控连接状态。专注一项工作，并完整做好。 ### 用量增长后，价格如何变化 这是会持续累积的差异，关键是算术，而不是观点。 - Twilio:: 每条消息 US$ 0.005，包括入站和出站，另加 Meta 收费。费用随每次对话增加，因此平台成本取决于业务表现。 - EasyCoexistence:: 按每个已连接号码收取固定费用。每月 10,000 条消息和 10 条消息的费用相同。业务越成功，平台的每条消息成本越低，量大时每个号码的价格也会下降。 ### 谁持有 WhatsApp 账户 号码和 Meta 关系由谁持有，决定了您日后能否轻松离开任一方。 - Twilio:: 号码通过 Twilio 的发送方接入，消息关系运行在 Twilio 的基础设施上，账单关系也由 Twilio 管理。 - EasyCoexistence:: 号码保留在客户自己的 Meta Business Portfolio 和 WhatsApp Business Account 中，Meta 直接向客户收取对话费用。我们是负责连接的 Tech Provider，移除我们不会带走号码。 ### 消息会发送到哪里 两者都会把入站消息发送到您控制的服务器，区别在于路径及路径上的处理方。 - Twilio:: 入站消息经由 Twilio 抵达您的 Webhook，Twilio 会在消息经过时处理并按条计费。 - EasyCoexistence:: 我们在 WhatsApp Business Account 上设置 Meta 自有的 override_callback_uri，让消息事件从 Meta 直接发送到您的端点。消息不会经过我们，我们不会储存消息，路径上也没有任何计量环节。 ### 如何通过 AI 助手访问 这是较新的需求，也是通用平台较少需要回答的问题。 - Twilio:: 完整的 REST API，提供主要编程语言的 SDK，按公开的 US$ 0.005 每条消息计费，因此您编写的集成每次发送或接收消息都会产生费用。 - EasyCoexistence:: 底层使用相同的 API，另加通过 OAuth 提供 16 个工具的远程 MCP 连接器，让 Claude、ChatGPT、Cursor 和 Claude Code 无需编写客户端，就能列出号码、检查连接状态、发送消息和设置 Webhook 目标。 - 只比较表面费用。按消息收费和按号码收费会在某个用量交叉，应该先计算这个用量。 - 以为大型平台就意味着更好的 WhatsApp 连接。无论哪种情况，底层的 Cloud API 都属于 Meta。 - 忽略谁向 Meta 付费。夹在您和 Meta 账单之间的提供商，可能会在费用上加价。 **低用量时，Twilio 更便宜吗？** 每月少于约 2,000 条消息时，按消息收费的费用较低。超过这个用量后，按号码收取固定费用更划算，而且用量越高优势越明显。 **Twilio 支持 Coexistence 吗？** 他们的 WhatsApp 定价页面没有说明这一点。Coexistence 是我们专门构建的产品，因此 WhatsApp Business 应用可以继续使用同一号码。 **API 不一样吗？** 不一样的不是 API。两种情况的底层 Cloud API 都属于 Meta。区别在于谁位于路径上、收费多少，以及谁向 Meta 付费。 **以后可以转移号码吗？** 可以。使用我们的服务时，号码保留在您自己的 Business Portfolio 中，因此移除我们后，号码仍在原来的位置。 --- ## EasyCoexistence 与 Gupshup 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-gupshup Gupshup 是一个对话式消息平台，在 Meta 对话费用之外，按每条消息收取公布的费用。EasyCoexistence 按每个已连接号码收取固定月费，不在消息账单上加收费用。消息量越大，这项差异越明显。 ### 账单的计算方式 US$ 0.001 听起来微不足道，但在规模化使用时，它就是整笔对话成本。 - Gupshup:: 每条消息收取 US$ 0.001 的标准费用，叠加在 Meta 费用之上，模板消息和会话消息同样适用。每月 100,000 条消息，仅平台费用就是 US$ 100，还未计算 Meta 费用。 - EasyCoexistence:: 每条消息不收费。100,000 条消息的费用与 10 条相同，因为费用跟着号码走，而不是流量走。号码越忙，我们的费用分摊到每次对话就越低。 ### 产品围绕什么打造 两者都连接 WhatsApp，但服务的工作不同。 - Gupshup:: 这是一个对话式平台，提供机器人构建、营销活动工具和广泛的渠道列表，面向大规模运行主动触达项目的企业。 - EasyCoexistence:: Coexistence 基础设施。WhatsApp Business 应用继续在手机上运行，Cloud API 在同一个号码上运行，消息事件会到达您已经使用的系统或 AI agent。我们不会要求您把团队迁移到其他地方。 ### 对话数据存在哪里 这个问题决定了您的业务有多少会在别人的产品里运行。 - Gupshup:: 消息会经过该平台，因此它能够提供机器人构建、营销活动工具和分析功能。如果您需要这些功能，这是一项合理的取舍。 - EasyCoexistence:: 消息事件从 Meta 直接通过 Meta 自有的 Webhook override 到达您的端点。我们从不查看对话内容，因此您离开时没有任何属于您的内容需要导出，传输路径上也没有可计费的环节。 ### 连接已经运行应用的号码 这正是 Coexistence 要解决的具体问题。 - Gupshup:: 他们公布的定价页面没有提到 Coexistence。这并不证明他们不支持它，直接向他们询问才是正确做法。 - EasyCoexistence:: 这正是我们产品的全部用途。已经运行 WhatsApp Business 应用的号码可通过 Meta 自有的 Embedded Signup 连接，应用继续运行，并在数分钟内让同一个号码获得 Cloud API。 - 把 US$ 0.001 当作微不足道。先按 1 年的真实消息量计算，再作决定。 - 为不会使用的营销活动工具付费。平台费用覆盖整个产品，用不用都要付。 - 假设任何服务商都支持 Coexistence。无论选择谁，都要明确询问。 **按消息收费实际要多少钱？** 每月 100,000 条消息时，Gupshup 公布的 US$ 0.001 会产生 US$ 100 的平台费用。我们的 1 个号码无论消息量多少，费用都是 US$ 9。 **Gupshup 支持 Coexistence 吗？** 他们的定价页面没有提到。Coexistence 正是我们产品的全部用途。 **使用您们的服务会失去营销活动功能吗？** 我们不是营销活动工具，也不按这类工具收费。消息会到达您自己的系统，因此您可以在现有系统中运行营销活动。 **谁向 Meta 付款？** 客户直接通过自己的 WhatsApp Business Account 向 Meta 付款。我们从不在 Meta 费用上加价。 --- ## EasyCoexistence 与 Infobip https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-infobip Infobip 是企业级通信平台，其 WhatsApp 价格按国家报价，并通过销售安排。EasyCoexistence 公开价格，提供 3 天免费试用，无需沟通即可连接号码，这是面向不同买家的不同产品。 ### 每个产品适合谁 没有哪个产品更差。它们面向不同买家，而这几乎决定了其他所有差异。 - Infobip:: 企业级 CPaaS，提供全渠道路由、联络中心工具和全球运营商关系，通过客户团队销售，面向有采购流程和用量承诺的组织。 - EasyCoexistence:: 已经拥有 WhatsApp Business 号码、希望今天下午将它接入 Cloud API 的小型企业或代理机构。注册、连接，完成。无需与任何人沟通，因为没有需要协商的内容。 ### 在作出承诺前，您能查到什么 这是最实际的差异，也是人们最先感受到的差异。 - Infobip:: 价格按目标国家报价，并通过销售安排。这是企业级 CPaaS 的常见方式，适合协商年度用量的买家。 - EasyCoexistence:: 完整价格表就在定价页面上，并以您的货币显示各个用量档位。您可以在创建账户前计算账单，前 3 天完全免费。 ### 从决定到号码可用需要多久 对于只有一个号码且正面对实际问题的企业，这才是重要的比较。 - Infobip:: 企业入门流程会提供专属支持和配置协助，大型部署确实需要这些服务。 - EasyCoexistence:: 几分钟。Meta 自己的 Embedded Signup 会选择业务组合、账户和号码，WhatsApp Business 应用在整个过程中持续运行，监控也会立即开始。 ### 连接中断时会发生什么 每个 Coexistence 连接最终都会遇到状况。不同之处在于谁会先发现。 - Infobip:: 企业支持渠道和客户团队。当背后有合约和指定联系人时，这是合适的模式。 - EasyCoexistence:: 我们持续监控连接，并读取 Meta 自己提供的断开原因，因此可以区分号码因闲置 14 天而断开，还是客户确实已离开。警报会在客户发现前送达。 - 只比较企业级 CPaaS 与按号码收费工具的功能。它们解决的是不同问题。 - 为一个号码启动采购流程。它耗费的时间成本，一年下来比工具费用还高。 - 以为小用量时销售报价会低于公开价格。通常不会。 **为什么 Infobip 不公开统一价格？** 他们按目标国家报价，适合协商用量的企业级买家。我们的价格公开，因为我们的买家希望今天就作出决定。 **对于大型企业，Infobip 更好吗？** 他们面向这类买家，提供全球运营商覆盖和客户团队。对于连接自有号码的企业，我们是更快、更便宜的途径。 **开始使用前需要与任何人沟通吗？** 不需要。第一个已连接号码可享 3 天免费试用，号码通过 Meta 自己的 Embedded Signup 连接。 **谁会向我收取消息费用？** Meta 会直接向您自己的 WhatsApp Business 账户收费。我们从不介入这张账单。 --- ## EasyCoexistence 对比 YCloud https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-ycloud YCloud 支持 Coexistence，和我们一样，不在 Meta 的消息费率上加价。差别在于您购买的内容：他们的付费套餐是按平台、席位、渠道和 AI 积分收费的订阅，而我们提供的是按已连接号码计价的基础设施。 ### 双方都做对了什么 这一点值得直接说明，因为它把比较范围缩小到真正不同的地方。 - YCloud:: 他们支持 Coexistence，并明确说明定价页对 WhatsApp 消息零加价。在提供商最重要的两项承诺上，他们都符合要求。 - EasyCoexistence:: 同样是两项承诺：通过 Meta 自己的流程实现 Coexistence，不在 Meta 消息上加价。我们的差别在其余所有方面。 ### 订阅实际买到什么 这是真正的分水岭，也决定哪一个对您更便宜。 - YCloud:: 一个平台。他们的付费套餐从每月 US$ 39 起，并按用户席位、渠道和 AI 积分区分。如果您希望团队在他们的产品内工作，这种模式就很合适。 - EasyCoexistence:: 基础设施。每个已连接号码每月 US$ 9 起，不用计算席位，没有渠道等级，也没有会用完的积分。拥有 1 个号码的企业付 1 个号码的费用，拥有 40 个号码的代理机构则享有逐号码下降的费率。 ### 对话最终会到哪里 双方连接的是同一个 Cloud API。消息之后如何处理，才是设计上的选择。 - YCloud:: 他们的平台，收件箱、营销活动和 AI 积分都在那里，每月 US$ 39 起，未计任何号码费用。您的团队在那里工作，因为消息就在那边。 - EasyCoexistence:: 您的系统。我们设置 Meta 自己的 Webhook 覆盖设置，让消息事件从 Meta 直接发送到您的端点，或通过 MCP 发送给您的 AI 代理。不需要迁移到任何地方，也不需要迁出任何地方，您的团队不用再检查第二个收件箱。 ### 代理机构扩大规模后要付多少 这是两种模式差异最大的情况。 - YCloud:: 按席位数量分级的套餐，因此每增加人员和渠道，就要作出一次升级决定。 - EasyCoexistence:: 随着号码增加，按号码计费的费率会下降，从 US$ 9 降至 US$ 1。不需要讨论升级，因为没有可升级的内容：第 40 个号码具备与第 1 个号码相同的功能，而且费率更低。 ### 如何从 AI 助手访问 两家平台的套餐等级都没有说明这一点，而这正逐渐成为用户关注的问题。 - YCloud:: AI 积分属于他们的套餐结构，说明 AI 功能是在他们的产品内部运行。 - EasyCoexistence:: 通过 OAuth 提供 16 个工具的远程 MCP 连接器。Claude、ChatGPT、Cursor 和 Claude Code 可以直接列出号码、检查连接状态、发送消息和消息模板，以及设置 Webhook 目的地。不需要编写客户端，也不需要购买积分。 - 未先计算席位和号码，就把按席位收费的套餐与按号码收费的费用进行比较。 - 团队已经有自己的收件箱，却仍为另一个收件箱付费。无论您是否打开它，平台费都照收。 - 把 AI 功能和 MCP 连接器当成同一回事。前者在他们的产品内运行，后者在您的产品内运行。 **双方真的都不加价吗？** 是。YCloud 的定价页说明零加价，我们也是如此。因此应比较的是平台费，而不是消息费。 **哪一个更便宜？** 拥有 1 到 4 个号码时，我们更便宜：4 个号码每月 US$ 36，而对方的入门套餐为 US$ 39。从 5 个号码起，请把我们的总额与您的席位和渠道所需的套餐等级相比较。我们的逐号码费率会随号码增加而下降，最低降至 US$ 1。 **使用您们的服务后，我会失去收件箱吗？** 您从来不需要迁移到另一个收件箱。消息会到达您自己的系统或 AI 代理，也就是团队原本工作的地方。 **YCloud 有 MCP 连接器吗？** 他们的定价页介绍的是平台内的 AI 积分，而不是 MCP 服务器。我们提供通过 OAuth 使用的 16 个工具，可从任何 MCP 客户端使用。 --- ## EasyCoexistence 与 SleekFlow 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-sleekflow SleekFlow 是按用户席位收费的全渠道消息平台，设有最低席位数，每个 WhatsApp 号码还需支付附加费。EasyCoexistence 按已连接号码收费，不设席位这一概念，因此账单取决于您持有的号码，而不是团队规模。 ### 您实际支付的是什么 两种定价模式回答的是不同问题，其中一种还会问到您的组织架构。 - SleekFlow:: 按用户席位收费的共享收件箱和营销活动平台，套餐分为不同层级。如果团队希望所有工作集中在一个平台上，这种模式确实实用。 - EasyCoexistence:: 一个连接。计费单位是已连接号码，而不是人员，因此新增同事无需付费，团队扩大或缩小时账单也不会改变。 ### 您的团队在哪里工作 这是定价模式背后的决定，也是最难逆转的一项选择。 - SleekFlow:: 在 SleekFlow 里。这就是该产品的用途：将收件箱、自动化和营销活动集中在一个地方，适合希望统一使用这些功能的团队。 - EasyCoexistence:: 在团队原本使用的地方。消息事件通过 Meta 自有的 Webhook 覆盖机制，直接从 Meta 发送到您的 CRM、服务台、内部工具或 AI 代理。无需学习新的收件箱，也无需迁移任何内容。 ### 添加第 2 个或第 3 个号码 对拥有多个地点的企业来说很常见，而两种模式在这里差异明显。 - SleekFlow:: 额外的 WhatsApp 号码属于席位制套餐之外的附加项目，因此第 2 个号码意味着要在订阅之外再做一次决定。 - EasyCoexistence:: 第 2 个号码就是第 2 个号码，按公布的费率计费，添加得越多，单价越低。一个账户有 20 个号码，无需更换套餐，也无需沟通协商。 ### 停止付费后会怎样 任何保存您消息的产品，都值得问清楚这一点。 - SleekFlow:: 收件箱、历史记录和自动化功能都存在于该平台中，它们因此能够运行，但离开平台也就意味着要进行迁移。 - EasyCoexistence:: 我们这里没有您的内容需要迁移。消息到达时就已发送到您的系统，号码也在您自己的 Meta Business Portfolio 中，因此移除我们后，号码仍会留在原处。 - 比较席位价格和按号码收费的价格时没有同时计算两者。3 个席位和 1 个号码，与 1 个席位和 3 个号码，账单完全不同。 - 为团队不会打开的收件箱付费。无论是否使用，席位都要收费。 - 为多地点企业建模时，忘记计算每个号码的附加费。 **哪个更便宜？** 我们更便宜，除非您明确需要收件箱。他们公布的价格按席位计算，设有最低席位数，每个 WhatsApp 号码还需按月支付附加费。我们的价格为每个已连接号码 US$ 9，随号码增加降至 US$ 1，完全不设席位。 **我会获得共享收件箱吗？** 不会，您也不需要为收件箱付费。消息会到达您自己的系统，团队已经在那里工作。 **多个地点怎么办？** 每个号码都按公布的费率收费，添加得越多，单价越低。无需更换套餐，也没有需要协商的附加项目。 **我的数据会被锁定吗？** 使用我们时不会。消息会直接从 Meta 发送到您的端点，号码也会留在您自己的 Business Portfolio 中。 --- ## EasyCoexistence 与 Bird https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-bird Bird 按送达的每条 WhatsApp 消息收费，并把 Meta 自己的费用并入报价。EasyCoexistence 按每个已连接号码收取固定费用，不出现在消息账单中，因此 Meta 收取的费用清晰可见并且分开计算。 ### 混合费率隐藏了什么 这并不代表不诚实，而且他们在自己的页面上已公开说明。但它仍会改变您可以核对的内容。 - Bird:: 每送达一条消息收取一个费率，其中已经包含 Meta 的部分。他们的页面说明，Bird 在处理期间收取发送费用，并根据送达回执记录 Meta 的部分。 - EasyCoexistence:: 两张完全分开的账单，彼此不会混合。Meta 就您自己的 WhatsApp Business Account 中的对话向客户开具账单，我们则为连接开具账单。因为从未合并，您可以分别根据来源核对两张账单。 ### Meta 更改费率时会怎样 Meta 会定期调整对话价格，而两种模式的传导方式不同。 - Bird:: 底层费率变动时，混合费率也必须调整，这会改变您收到的报价数字。 - EasyCoexistence:: 我们这边的费用不会变。Meta 的调整会在 Meta 采用该费率的日期，按 Meta 自己的费率显示在客户的 Meta 账单上。我们的费用针对连接，与消息价格没有关系。 ### 两种产品分别围绕什么组织 两者都会发送 WhatsApp 消息，但它们并不是在争夺同一项工作。 - Bird:: 一个覆盖 email、SMS 和 WhatsApp 的营销与客户互动平台，适合团队跨渠道大规模运行营销活动。 - EasyCoexistence:: 面向已经运行 WhatsApp Business 应用的号码的 Coexistence 基础设施。应用继续运行，Cloud API 与其并行工作，事件到达您自己的系统。一个号码，一项工作，妥善完成。 ### 对话属于谁 这是两种定价模式背后的结构性问题。 - Bird:: 消息在经过平台时被处理并计费，这正是营销活动和分析工具能够运行的原因。 - EasyCoexistence:: 消息事件通过 Meta 自己的 override，从 Meta 直接发送到您的端点。它们不会经过我们，我们也不会存储这些事件，因此我们没有按消息收费的依据。 - 把混合费率与 Meta 公布的费率相比，仿佛它们是同一个数字。其实一个包含另一个。 - 以为捆绑价格代表没有加价。它只是没有逐项列出加价。 - 为了一个号码和一个 Webhook 的工作，选择营销活动平台。 **Bird 的定价不诚实吗？** 不是。他们清楚说明 Meta 的费用已包含其中。重点是，合并费率无法与 Meta 自己公布的费率直接核对。 **使用您的服务时，谁向我收取消息费用？** Meta 会直接通过您自己的 WhatsApp Business Account 收取。我们从不加价或转售 Meta 的费用。 **如果 Meta 提高费率，会怎样？** 它会按 Meta 的费率显示在您的 Meta 账单上。我们的费用不受影响，因为它与消息无关。 **Bird 支持 Coexistence 吗？** 他们的 WhatsApp 价格页面没有提到这一点。这正是我们全部的工作。 --- ## EasyCoexistence 与 Zenvia https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-zenvia Zenvia 销售月费软件方案，另收渠道套餐费用，并收取 WhatsApp 开通费。EasyCoexistence 按每个已连接号码收取一项公开费用，不设方案、套餐或开通费。这对小型企业来说，成本模式完全不同。 ### 账单如何组成 这是结构上的差异，也决定了最终总额。 - Zenvia:: 月费软件方案，加上按预期用量选择的渠道套餐；启用 WhatsApp 渠道时，还要支付开通费。三项决定、三行费用，适合需要运营营销工作的公司。 - EasyCoexistence:: 只有一行。每个已连接号码收取一项公开费用，号码越多，单价越低；没有额外方案、套餐，也无需支付开通费。Meta 的对话费用由客户直接向 Meta 支付，按 Meta 自行设定的费率另行计算。 ### 两者分别适合什么 两者都是成熟产品，但面向不同类型的公司。 - Zenvia:: 这是一个客户体验平台，提供全渠道营销活动、客户旅程和庞大的巴西企业客户基础，面向运营结构化沟通项目的公司。 - EasyCoexistence:: 适合已经在手机上使用 WhatsApp Business 号码，并希望将号码接入 Cloud API、同时保留应用的企业。应用继续运行，API 使用同一号码，消息会送达企业已经在使用的系统。 ### 用量增加后会怎样 两种模式的发展方向正好相反。 - Zenvia:: 渠道套餐按用量选择，因此业务增长意味着升级套餐，软件方案等级也可能随之调整。 - EasyCoexistence:: 号码越多，每个号码的费率越低，消息用量完全不参与计算。一个发送 100,000 条消息的号码，费用与使用量少的号码相同。 ### 多久可以使用号码 对小型企业来说，这往往就是决定因素。 - Zenvia:: 通过商业入驻流程启用 WhatsApp 渠道，并需要完成激活步骤；较大型的部署可从中获得支持。 - EasyCoexistence:: 通过 Meta 自己的 Embedded Signup，几分钟即可完成；第一个已连接号码可免费使用 3 天。整个过程中 WhatsApp Business 应用继续运行，号码连接后也会立即开始监控。 - 只比较方案价格。渠道套餐和开通费也属于总成本。 - 为了连接问题，购买一个营销活动平台。 - 以为 Meta 的对话费用已包含在某项费用中。费用由客户使用自己的账户直接承担。 **可以用雷亚尔支付吗？** 可以。价格以雷亚尔和美元公布，货币固定为您首次订阅所使用的货币。 **有开通费吗？** 没有。前 3 天免费，之后按号码收费。启用号码上的 WhatsApp 无需支付其他费用。 **我会失去营销活动工具吗？** 我们不是营销活动平台，也不会按这类平台的方式收费。消息会送达您自己的系统，营销活动可继续在原有系统中运行。 **谁向 Meta 支付对话费用？** 由客户使用自己的 WhatsApp Business 账户直接支付。我们从不在 Meta 的费用上加价。 --- ## EasyCoexistence 与 8x8 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-8x8 8x8 是企业级通信服务商，其 Coexistence 文档清晰易懂，因此经常被引用。EasyCoexistence 为阅读这些文档、希望今天连接号码的企业而设计，无需经历企业级销售流程。 ### 两者重叠的部分 技术基础相同，因此值得先说明这一点，再谈差异。 - 8x8:: 他们的 Coexistence 文档准确，而且对限制说明得异常清楚，包括号码连接后哪些 WhatsApp 功能会被停用。这确实是一份有用的参考资料。 - EasyCoexistence:: 这些限制相同，因为它们来自 Meta，而不是任何服务商。我们也会说明这些限制，并围绕实际使用来设计产品，包括 14 天不活跃规则、同步窗口，以及会消失的功能。 ### 从阅读到完成连接 文档无法填补的差距。 - 8x8:: 这是企业级 CPaaS，提供客户团队、联络中心产品和运营商服务，面向有采购流程的组织销售。大规模部署所需的协助会包含在开户过程中。 - EasyCoexistence:: 注册并连接。Meta 自己的 Embedded Signup 会选择企业组合、账户和号码，WhatsApp Business 应用继续运作，前 3 天免费。您不需要安排通话。 ### 提交前您能知道什么 这对小型企业或代理机构来说，是实际的差异。 - 8x8:: 价格按商业方式安排，这对企业级 CPaaS 很常见，也适合同时协商语音、联络中心和消息服务用量的买家。 - EasyCoexistence:: 完整价目表公开，并以您的货币显示可见的用量阶梯。拥有 40 个号码的代理机构可以在创建账户前计算账单。 ### 号码连接后 Coexistence 连接可能会静默失效，这是大多数比较文章略过的部分。 - 8x8:: 提供企业级支持和账户关系；如果背后有合约，这是正确的服务模式。 - EasyCoexistence:: 持续监控会读取 Meta 自己提供的断开原因，因此能区分 14 天不活跃规则和客户离开；此外还有包含 16 个工具的 MCP 连接器，让助手无需打开控制台即可检查连接状态并重新连接。 - 把优质文档误认为产品。文档说明的是 Meta 的机制，所有服务商都必须遵守。 - 为连接一个号码而启动企业级流程。 - 以为任何服务商都会在连接完成后持续监控。无论选择谁，都请明确询问。 **8x8 的文档准确吗？** 准确，我们也会引用。文档说明的限制来自 Meta，因此适用于所有 Coexistence 服务商，包括我们。 **Coexistence 下哪些功能会停止运作？** 根据 8x8 的文档和我们自己的资料，共有 4 项：消失消息、阅后即焚媒体、实时位置和广播列表。群组聊天完全不在 API 范围内。 **我需要企业合约吗？** 使用我们不需要。3 天免费试用、公开价格，几分钟即可连接一个号码。 **连接断开后会怎样？** 我们会读取 Meta 提供的断开原因并向您发出警报，从而区分 14 天不活跃规则和真正的客户离开。 --- ## Coexistence 注册中的“此电话号码不符合资格”提示 https://easycoexistence.com/zh-hans/docs/coexistence-error-number-not-eligible 当号码背后的 WhatsApp Business 应用账户未通过 Meta 对连接平台的检查时，Meta 的注册弹窗就会提示该号码不符合资格。Meta 文档给出的原因是该应用内的活动不足。解决办法是在该号码上真实、持续地使用应用，然后重新运行流程。 ### 这条消息到底说了什么？ 弹窗会以当前显示的语言展示这条消息。英文显示为 “This phone number isn't eligible for registration or migration”，西班牙语显示为 “Este número de teléfono no cumple los requisitos para el registro ni la migración”。Meta 的 Embedded Signup 错误参考在代码 3441045 下列出了最接近的文档版本：“Your phone number isn't eligible to connect to the WhatsApp Business Platform”。 无论使用哪种语言，含义都相同。流程进行到了电话号码步骤，Meta 查看了注册在该号码上的 WhatsApp Business 应用账户，并拒绝将其连接到 API。手机上没有任何改动，应用仍和以前一样正常运行。 ### 为什么 Meta 会拒绝看似符合条件的号码？ Meta 对 3441045 给出的解决办法很简短：需要在 WhatsApp Business 应用上有更多活动，才能帮助判断是否符合资格。Meta 没有公布门槛、天数或消息数量，因此您在别处看到的任何数字，都只是某个服务提供商的观察，而不是 Meta 的规则。 直白地说，这指向真实使用很少的账户：最近才注册的号码，或几乎没有承载过真实对话的号码。 另有两种拒绝看起来相似，但并不是一回事。代码 3441042 表示该功能不适用于来自该地区的号码。在 API 一侧，2388091 和 2388093 表示号码因未处于迁移中，所以不能接收或验证注册码，这属于迁移路径，与 Coexistence 无关。 ### 再次尝试之前应该做什么？ 请在 WhatsApp Business 应用中正常使用该号码：在一段有意义的时间内，进行真实的客户对话，包括发送和接收。等待期间，请避免删除账户或重新注册该号码，因为 Meta 检查的是该账户上的活动，从头开始只会让它能查看的内容更少。 同时检查基本条件。使用的必须是 WhatsApp Business 应用，而不是个人版 WhatsApp，版本为 2.24.17 或更新，并且该号码不能已连接到其他 API 服务提供商。这些情况会产生各自的消息，我们在单独的页面中说明。 然后从头重新运行流程。Meta 在每次尝试时都会重新评估资格，所以在有了真实活动之后再尝试一次，才是唯一有意义的测试。 - 连续多次重试流程。资格由 Meta 评估，重复尝试反而可能触发速率限制。 - 在全新安装的应用上重新注册号码，想要从头开始。Meta 检查的是活动，而新注册没有任何活动。 - 以为服务提供商可以把号码加入白名单。没有任何服务提供商能推翻 Meta 的资格决定。 **我的号码被封了吗？** 没有。这条消息只与将号码连接到 API 有关。WhatsApp Business 应用在手机上仍和以前一样正常运行。 **重试前应该等多久？** Meta 没有公布固定期限。它文档中的解决办法是在 WhatsApp Business 应用中有更多真实活动，所以请等到该号码有了真实使用之后再试。 **为什么消息里提到迁移？** 同一个弹窗也负责在账户之间移动号码。这次拒绝涵盖两种路径，所以措辞中同时写到了两者。 **换一个服务提供商会得到不同的答案吗？** 不会。所有服务提供商使用的都是 Meta 同一个 Embedded Signup，资格检查由 Meta 完成。 --- ## “此号码已注册到 WhatsApp 账户” https://easycoexistence.com/zh-hans/docs/coexistence-error-number-already-registered 当号码已在别处注册，而该注册会阻止当前尝试的步骤时，Meta 的注册弹窗就会显示此提示。这个账户可能是个人版 WhatsApp、WhatsApp Business API 账户，或其他平台上的账户。必须先将号码从该账户断开连接。断开后，Meta 表示号码可能需要几分钟才能再次可用。 ### Meta 的文档如何解释这条提示？ Meta 的 Embedded Signup 错误参考将该提示列为“此号码已注册到现有 WhatsApp 账户。要使用此号码，请先将其从现有账户断开连接，然后返回此页面并重新输入号码。”文档还补充说，号码可能需要最多 3 分钟才能变为可用。 Meta 的解释是，该电话号码已在其平台上注册，涉及的位置包括 WhatsApp Messenger、WhatsApp Business 应用和 WhatsApp Business API，建议的解决方法是注销该号码或改用其他号码。弹窗会以用户的语言显示，因此用意大利语、西班牙语或葡萄牙语看到的拒绝提示，含义完全相同。 ### 为什么 Coexistence 注册也会遇到这个提示？ Coexistence 的用途是连接已在 WhatsApp Business 应用中注册的号码，所以“已注册”本身并不是问题。只有当流程没有走 Coexistence 路径，或注册类型不对时，才会出现此提示。 有三种情况会触发它。第一，号码在个人版 WhatsApp 上，而不是 WhatsApp Business 应用，Coexistence 无法连接这类号码。第二，所运行的是标准的新号码注册流程，而不是连接现有 WhatsApp Business 应用账户的选项，因此 Meta 把该号码当作需要全新注册的号码。第三，号码直接注册在 WhatsApp Business API 上，而不在应用中。 每种情况的解决方法各不相同，所以仅凭这条提示还不足以采取行动。 ### 如何释放号码并重试？ 请根据号码所在的位置选择对应的做法。 如果号码在个人版 WhatsApp 上，请先在手机上将其迁移到 WhatsApp Business 应用。如果号码已在 WhatsApp Business 应用中，但弹窗仍显示此提示，请确认流程是否提供了连接现有 WhatsApp Business 应用账户的选项；没有这个界面，说明走的是错误的流程。如果号码通过其他平台注册在 API 上，则必须在那个平台断开连接。 断开后，请按 Meta 的说明等待几分钟，再回到弹窗重新输入号码。如果弹窗已经关闭，请从头重新开始流程，而不要沿用旧窗口。 - 断开连接后立即用同一号码重试。Meta 表示号码可能需要最多 3 分钟才能可用。 - 为应用号码运行标准的新号码注册流程。Coexistence 需要使用提供连接现有 WhatsApp Business 应用账户选项的流程。 - 为消除错误而删除 WhatsApp Business 应用账户。这会删掉 Coexistence 要连接的那个注册本身。 **Meta 说的现有账户是指哪一个？** 弹窗不会说明。它指的是号码当前注册所在的位置：个人版 WhatsApp、走错路径的 WhatsApp Business 应用，或通过其他平台注册的 API。 **断开连接会丢失我的聊天记录吗？** 从某个平台断开连接，是在 WhatsApp Business 应用的 设置 > 账户 > Business Platform 中操作的。这与删除应用账户是两个不同的操作，而删除账户并不是解决办法。 **我看到的是意大利语提示，这是同一个错误吗？** 是的。弹窗会本地化，所以同一个拒绝提示会以会话所用的语言显示。 **提供商需要做什么吗？** 只有当号码是通过该提供商连接时才需要。此时必须先在那里断开连接，新的流程才能完成。 --- ## "Request code failed: Our servers are temporarily unavailable" https://easycoexistence.com/zh-hans/docs/coexistence-error-request-code-unavailable 在注册过程中为号码请求验证码，而 Meta 没有发送时，就会出现“Request code failed: Our servers are temporarily unavailable. Please wait 1 hour before trying again”。消息中的指示就是解决办法：停止请求验证码，等满 1 小时，然后从全新的流程重试一次。 ### 这是 Meta 服务中断吗？ 有可能，但与这条消息相关的官方记录指向别处。Meta 的 Embedded Signup 错误参考中没有列出这段确切的文字，却列出了一组行为相同的验证码拒绝消息：“You have requested your code too many times”，重复请求对应的代码 2494158 和 2388367，以及请求验证码时出错对应的 2593037。每一条都让用户稍后再来。 平台确实也可能出问题。在 API 方面，133004 表示服务器暂时不可用，Meta 在此的建议是先查看 WhatsApp Business Platform 状态页面，再重试。如果状态页面没有显示任何事故，请将这条消息视为该号码的验证码请求限制，并遵守它给出的 1 小时。 ### 为什么 Coexistence 号码会被要求验证码？ 在 Coexistence 路径上，号码已经在 WhatsApp Business 应用中注册，所以 Meta 告诉合作伙伴跳过号码注册步骤。Meta 记录的流程通过应用本身验证所有权：企业会在 WhatsApp Business 应用中收到来自官方 Facebook Business 账户的消息，点击 Connect，然后在应用中完成验证步骤。 因此，验证码请求一再失败，提示您应该检查弹窗走的是哪条路径。如果提供连接现有 WhatsApp Business 应用账户的画面从未出现，说明流程把该号码当作新注册，并要求短信或语音验证码，而这正是这些限制起作用的地方。 ### 如何重试才不会让情况更糟？ 按消息要求等满 1 小时，期间不要再请求验证码。Meta 表示，系统会限制在一定时间内可以请求验证码的次数，因此等待期间发出的请求反而对您不利。 1 小时过后，请关闭旧弹窗并重新开始流程，不要在一直开着的窗口里点击重新发送。选择连接现有 WhatsApp Business 应用账户的选项，让装有该号码的手机保持解锁并放在身边，消息一到就在应用中完成验证。 如果多次输入了错误的验证码，Meta 的指引则不同：系统只允许有限次数的验证尝试，并建议等待大约 12 小时后再重试。 - 在这 1 小时内反复点击重新发送。Meta 会限制一段时间内可以请求验证码的次数。 - 以为故障是永久性的而更换号码。消息说的是暂时等待。 - 为应用号码执行新号码注册。Coexistence 通过 WhatsApp Business 应用验证，而不是重新进行短信注册。 **等待超过 1 小时会有帮助吗？** 消息写明的是 1 小时。等得更久没有坏处，但在这 1 小时内请求验证码就有影响。 **我的服务提供商可以重置这个限制吗？** 不可以。验证码限制由 Meta 针对号码设置，任何服务提供商都无法清除。 **WhatsApp Business 应用会受影响吗？** 不会。应用在手机上继续正常使用。这次拒绝只涉及浏览器中的注册步骤。 **我如何知道这是不是真的服务中断？** 请查看 Meta 的 WhatsApp Business Platform 状态页面。如果没有显示任何事故，请将这条消息视为验证码请求限制。 --- ## 在 WhatsApp Business 应用中扫描 Coexistence 二维码失败 https://easycoexistence.com/zh-hans/docs/coexistence-error-qr-code-pairing-failed Coexistence 注册时扫码失败，需要检查的原因都在手机上：WhatsApp Business 应用版本过旧、用错了应用或设备扫描，或者扫码后出现的提示没有回应。解决方法是更新应用，在持有该号码的手机上用 WhatsApp Business 应用扫描，并完成每一个提示。 ### 手机上应该发生什么？ Meta 的文档将手机端分为四个动作。商家在 WhatsApp Business 应用内收到来自 Facebook Business 官方账户的消息，并点击“连接”。接着点击“连接到 Business Platform”。然后点击“确认”，在这一步选择是否共享聊天记录。最后完成验证码步骤，并返回浏览器完成流程。 浏览器中显示的二维码，是用来启动应用内这段对话的。因此，如果扫码后没有任何反应，或者手机在扫码的瞬间就显示错误，就说明其中某个动作无法开始。而浏览器中之前的所有步骤都已经成功。 ### 扫码为什么会失败？ 有四个原因值得按以下顺序检查。 应用版本过旧。Meta 要求 WhatsApp Business 应用版本为 2.24.17 或更新，并且有一个 Embedded Signup 错误 4563015，意思就是请将应用更新到最新版本。 用错了应用扫描。二维码必须由持有该号码、位于主手机上的 WhatsApp Business 应用来处理。普通 WhatsApp、手机的相机应用，或者 WhatsApp Web、桌面版这类已关联设备，都不是同一回事。 提示没有完成。扫码只是打开这一步；点击“连接”、“连接到 Business Platform”和“确认”才能让流程继续。 弹出窗口被关闭。如果浏览器窗口不在了，手机正在完成的流程也随之消失。 ### 如何干净地重试？ 请先从应用商店更新 WhatsApp Business 应用，并重新打开。确认手上的手机就是持有该号码的那一部，并且已解锁、已联网。 然后在浏览器中从头重新开始注册流程，选择连接现有 WhatsApp Business 应用账户的选项，并在手机上操作期间保持弹出窗口开启。在 WhatsApp Business 应用内处理二维码，逐个回应出现的提示，然后返回浏览器完成流程。 连接完成后，已关联设备会被登出，这是正常现象。号码连接到 API 时，Meta 会取消所有配套应用的关联，之后可以重新关联。 - 使用手机的相机应用扫描。二维码必须由持有该号码的 WhatsApp Business 应用来处理。 - 在手机上操作时关闭了浏览器弹出窗口。手机步骤需要启动它的那个流程。 - 把已关联设备被登出当作失败。Meta 会在连接时取消配套应用的关联，之后可以重新关联。 **别人可以替企业扫码吗？** 只有使用持有该号码的手机才行。这一步在该设备的 WhatsApp Business 应用中完成。 **可以用 WhatsApp Web 扫码吗？** 不可以。已关联设备只是账户的配套设备。手机步骤属于主手机上的 WhatsApp Business 应用。 **扫码失败会改变手机上的任何设置吗？** 不会。流程完成之前，号码尚未连接，应用会照常工作。 **我的应用显示已是最新版本，接下来怎么办？** 请确认版本号为 2.24.17 或更新，然后从头重新开始流程，并完成每一个提示。 --- ## Coexistence 注册被旧的 Business Portfolio 拦截 https://easycoexistence.com/zh-hans/docs/coexistence-error-inaccessible-business-portfolio 如果号码关联的 Meta Business Portfolio 与您在注册弹窗中选择的不是同一个，Meta 会拒绝该号码，并提示号码与您选择的商家没有关联。您必须在那个 Portfolio 内解除号码的绑定，这需要有该 Portfolio 管理员权限的人操作；或者改为在那个 Portfolio 内完成整个流程。 ### 出现这种情况时，Meta 是怎么说的？ Meta 的 Embedded Signup 错误参考列出了错误代码 3441041：“您输入的电话号码与您选择的商家没有关联。要继续，您需要将此电话号码与该商家解除关联，或输入其他号码。” 这里所说的“您选择的商家”，指的是在弹窗第一个界面选中的 Business Portfolio。这条消息的意思是：Meta 已经把该号码关联到了另一个 Portfolio。这个关联可能来自更早的设置：曾经连接过该号码的代理商、已离职员工的 Business Manager，或是为投放广告而创建的旧 WhatsApp 账户。今天运行流程的人往往完全不知道它的存在。 ### 如何把号码从另一个 Portfolio 中解除绑定？ Meta 文档中的解决办法分为两步，都要在当前持有该号码的 Portfolio 内完成。 第一步，移除与该号码关联的 WhatsApp 账户：Meta Business Suite，设置，账户，WhatsApp 账户，移除账户。第二步，在 WhatsApp Manager 的 Phone Numbers 标签页中删除该电话号码本身。 这两步都在那个 Portfolio 内进行，因此需要有该 Portfolio 管理员权限的人来操作。Meta 本来就要求管理员级别的权限，才能在 Portfolio 中创建 WhatsApp Business 账户。号码释放后，重新运行注册流程，并选择您能控制的 Portfolio。 ### 如果没有人能进入旧的 Portfolio 怎么办？ 那么现实可行的办法只剩两个。 第一，恢复访问权限。创建该 Portfolio 的人，或者仍留在其中的任何管理员，可以把现在的负责人添加为管理员。如果 Portfolio 由代理商持有，就需要请代理商授予访问权限，或由他们自己完成解除绑定。 第二，等访问权限恢复后，直接在那个旧的 Portfolio 内运行流程，而不是把号码迁出来。Coexistence 会把转换后的账户保留在客户自己的 Portfolio 下，所以流程在哪个 Portfolio 内运行，号码之后就归属于哪个 Portfolio。请选择一年后业务仍能掌控的那一个。 - 新建一个 Portfolio 再重试。号码仍然关联着旧的 Portfolio，同样的拒绝提示还会出现。 - 删除 WhatsApp Business 应用账户来断开关联。这个关联保存在 Meta 一侧，位于另一个 Portfolio 内。 - 把号码留在业务无法掌控的 Portfolio 里。谁管理该 Portfolio，谁就控制这个连接。 **Meta 支持团队可以帮我迁移号码吗？** Meta 文档中针对 3441041 的办法，是由有权限的人在另一个 Portfolio 内解除绑定。Meta 没有说明可以代您迁移号码。 **如何查出是哪个 Portfolio 持有该号码？** Meta 的消息不会给出名称。请检查业务中任何人用过的所有 Portfolio，包括代理商代为设置的。 **解除绑定会影响 WhatsApp Business 应用吗？** 这些步骤是在 Meta Business Suite 和 WhatsApp Manager 中，把 WhatsApp 账户和号码从该 Portfolio 移除，并不在手机应用里进行。 **这和号码连接在另一个提供商上是一回事吗？** 不是。那种情况是号码连接到了另一家合作伙伴的应用。而这里是号码属于另一个 Portfolio。 --- ## 未显示“连接现有 WhatsApp Business 应用”选项 https://easycoexistence.com/zh-hans/docs/coexistence-error-option-not-showing 只有当启动 Meta Embedded Signup 的平台在代码中启用了该设置，才会出现连接现有 WhatsApp Business 应用账户的选项。没有这项设置，弹窗会显示标准的账户选择界面，并把该号码当作新注册处理。企业自己无法开启，必须由平台来开启。 ### 选项是否出现，由谁控制？ 由启动弹窗的平台控制。Meta 的文档要求合作伙伴在启动 Embedded Signup 时添加 featureType 属性，并将其设置为 whatsapp_business_app_onboarding。Meta 也给出了检查方法：如果账户选择界面被替换为可连接现有 WhatsApp Business 账户的界面，就说明该功能已启用。 因此，如果企业看到的是普通界面，也就是选择或创建 WhatsApp Business 账户，再输入要注册的号码，说明弹窗启动时没有带上该设置。企业自己的 Meta 设置无法改变这一点。企业只能改用已启用该功能的平台提供的注册链接。 ### 平台为什么可能不提供该选项？ Meta 列出了启用前平台一侧必须满足的要求。平台必须已经是 Solution Partner 或 Tech Provider，必须懂得如何使用 Cloud API，必须有能够接收并处理 Webhook 的端点，并且必须在运行 Embedded Signup 时记录会话日志。 自托管工具，或基于非 Tech Provider 开发者应用构建的集成，第一项要求就无法满足。这种情况下，企业一侧修改配置无法让该选项重新出现。解决办法是改用已经完成这些工作的平台。 另一个缺口是版本。Embedded Signup v2 和 v3 将于 2026 年 10 月 15 日弃用，Meta 要求合作伙伴在此之前迁移到 v4。 ### 如果选项出现了，却无法选择账户怎么办？ 那是另一种拒绝，原因来自账户，而不是平台。 Meta 的错误参考中列有 3441047：该功能不适用于使用营销消息的账户，企业必须选择另一个 WhatsApp Business 账户。错误代码 3441042 表示该功能不适用于该地区的号码。此外，版本低于 2.24.17 的应用会被拒绝，并提示更新到最新版本。 以上每种情况，弹窗里都会有各自的提示消息。如果选项缺失而且没有任何提示，问题就出在流程的启动方式上。 - 在企业的 Meta 设置中寻找 Coexistence 开关。该选项由启动弹窗的一方设置。 - 仍然完成标准流程。没有该选项时，Meta 会把号码当作新注册处理，这不是 Coexistence。 - 以为旧版 Embedded Signup 集成仍然符合条件。Meta 将于 2026 年 10 月 15 日弃用 v2 和 v3。 **企业可以自己启用 Coexistence 吗？** 无法在弹窗中启用。该选项由启动 Embedded Signup 的平台通过 featureType 设置来决定。 **如何确认该选项已启用？** 按 Meta 自己的判断方法：账户选择界面被替换为可连接您现有 WhatsApp Business 账户的界面。 **企业需要已验证的 Business Portfolio 吗？** Meta 为该选项列出的要求都在启动平台一侧，企业一侧只要求应用版本为 2.24.17 或更高。 **这是地区限制吗？** 地区限制会以独立的提示消息出现，错误代码为 3441042。如果选项缺失而且没有任何提示，则是流程的启动方式有问题。 --- ## Coexistence 注册时提示“请更新您的 WhatsApp Business 应用” https://easycoexistence.com/zh-hans/docs/coexistence-error-business-app-outdated Coexistence 要求持有该号码的手机上，WhatsApp Business 应用版本为 2.24.17 或更高。低于此版本时，Meta 的注册弹窗会拒绝该号码，并要求将应用更新到最新版本。请在应用商店更新应用，然后从头重新运行流程，即可解决。 ### 提示信息是什么意思？ Meta 的 Embedded Signup 错误参考列出了错误代码 4563015，文本为 “Update your WhatsApp Business App to the latest version to use this phone number”，解决办法正是如此：将应用更新到最新版本。 背后的要求写在 Meta 的 Coexistence 接入文档中：企业客户必须使用 WhatsApp Business 应用 2.24.17 或更高版本。提示信息要求的是最新版本，而不是最低版本，更新到当前可用的最新版本即可同时满足两者。 ### 需要更新哪台设备？ 主手机：即在 WhatsApp Business 应用中注册该号码的设备。Meta 检查的正是这个应用，流程中的手机步骤也由它处理。 更新 WhatsApp Web、桌面应用或链接到该账户的平板电脑不起作用，因为它们是配套设备，而不是注册本身。Meta 的文档还说明，号码连接到 API 后，配套客户端会被取消链接，之后 WhatsApp for Windows 和 WhatsApp for WearOS 也不是受支持的配套客户端。 在代理商的工作方式下，在浏览器中运行流程的人往往并不持有这部手机，因此开始之前，请先与企业主确认这一步。 ### 如何检查版本并重试？ 请在持有该号码的手机上，查看 WhatsApp Business 应用的已安装版本，可以在应用自带的帮助信息中查看，也可以在手机应用商店的应用页面查看。如果版本低于 2.24.17，或应用商店提供更新，请进行安装。 更新后，请关闭并重新打开应用，确保运行的是新版本。然后在浏览器中从头重新启动注册流程，而不是继续使用已显示拒绝提示的弹窗，并选择连接现有 WhatsApp Business 应用账户的选项。 更新是在应用商店中完成的，而不是在注册弹窗中，因此这一步需要由持有手机的人来做。再次运行流程之前，请与对方确认新的版本号，不要想当然地认为更新已经成功。 - 更新了 WhatsApp Web 或桌面应用。Meta 检查的是主手机上的 WhatsApp Business 应用。 - 在同时安装两个应用的手机上更新了普通版 WhatsApp。Business 应用是单独安装的，有自己的版本。 - 更新后在同一个弹窗中重试。请重新开始流程，以便检查针对新版本运行。 **2.24.17 够用吗，还是必须更新到最新版本？** Meta 规定的最低版本是 2.24.17。错误文本要求的是最新版本，因此更新到最新版本即可同时满足两者。 **更新会丢失聊天记录吗？** 更新只是在同一注册下替换应用版本，与删除账户或重新注册号码不同，后者应当避免。 **连接之后，版本还重要吗？** Meta 的要求针对的是接入阶段。不过让应用保持最新仍然是明智的做法，因为这部手机依然是连接的一部分。 **这与号码不符合资格是同一回事吗？** 不是。资格问题涉及账户的活跃情况，而这个错误纯粹是手机上的应用版本问题。 --- ## Coexistence 错误：号码已连接到其他服务商 https://easycoexistence.com/zh-hans/docs/coexistence-error-number-on-another-provider 只要号码仍被另一个平台占用，Meta 的 Coexistence 流程就不会把这个 WhatsApp Business 应用号码连接到新平台。如果号码已连接到其他服务商，Meta 的注册弹窗会拒绝该号码，并提示此流程不支持更换合作伙伴。商家需要先在 WhatsApp Business 应用中断开当前平台，等待 15 分钟，再重新进行新的注册。 ### 哪些消息表示号码在其他服务商处？ 在 Meta 的 Embedded Signup 错误参考中，WhatsApp Business 应用用户接入一节列出了三条与此情况相关的消息。 - 2655093：该商家已与某个合作伙伴共享此 WhatsApp Business 账户，此流程不支持更换合作伙伴。 - 3441049：该号码已在该产品中注册，必须在 WhatsApp Business 应用中从当前账户断开。 - 2655094：请断开您的商业平台后继续，并在重试前等待 15 分钟。 ### 如何断开当前的服务商？ 在手机上的 WhatsApp Business 应用中操作。Meta 给出的路径是：设置、账户、Business Platform，然后选择已连接的平台并点按“断开连接”。Meta 还说明，对于同时用于应用和 Cloud API 的号码，不能使用 API 自带的取消注册调用，因此需要在应用中断开，而不是通过旧服务商的控制台。 商家断开连接时，Meta 会向前一个平台发送带有 PARTNER_REMOVED 事件的 account_update Webhook。旧服务商就是这样得知断开的。与该服务商之间的订阅是商家与对方之间的另一件事。 ### 断开之后会发生什么？ 请等待。Meta 针对 3441049 和 2655094 的消息都要求在重试前等待 15 分钟。 然后从头运行新平台的注册，并选择连接现有 WhatsApp Business 应用账户的选项。这是一次全新的接入：系统会再次提供聊天记录共享，新平台在接入后有 24 小时来同步联系人和历史记录。 有一种情况仍可能打断切换。Meta 指出，如果商家过去曾与某个合作伙伴合作，并且仍共享该合作伙伴的信用额度，那么在转到新合作伙伴时可能会看到错误，Meta 为此另有一份解决指南。 - 要求旧服务商取消注册该号码。Meta 表示，对于同时用于应用和 Cloud API 的号码，取消注册调用无效。 - 断开后几分钟内就重试。Meta 要求等待 15 分钟。 - 为了断开旧连接而删除 WhatsApp Business 应用账户。官方文档给出的方式是在设置中断开。 **一个号码可以同时连接两个服务商吗？** 通过此流程不行。Meta 的消息说明，如果不先断开当前服务商，就不支持更换合作伙伴。 **断开连接会删除我的聊天记录吗？** 断开只会移除平台连接。WhatsApp Business 应用仍保留在手机上，并可继续使用。 **新服务商可以替我断开旧服务商吗？** 不可以。断开操作必须由商家在 WhatsApp Business 应用中完成。 **换了新服务商后，历史记录会再次同步吗？** 新的接入会再次提供历史记录共享，新平台有 24 小时来完成同步。 --- ## Coexistence 注册后出现“此授权码已过期” https://easycoexistence.com/zh-hans/docs/coexistence-error-authorization-code-expired Meta 的 Embedded Signup 完成后，会向发起的平台返回一个短期有效的代码，平台必须在 30 秒内用它换取访问令牌。如果交换发生得太晚，或使用了之前那次尝试的代码，Meta 就会提示授权码已过期。重新运行流程即可获得新的代码。 ### 哪个代码已过期？ 企业完成 Embedded Signup 后，Meta 会把资产 ID 和一个可交换的令牌代码返回给打开弹窗的浏览器窗口。随后，平台会把该代码发送到自己的服务器，服务器携带应用 ID 和应用密钥调用 Meta 的 oauth access_token 端点，将其换成企业访问令牌。 Meta 的实施指南对时间要求写得很明确：可交换令牌代码的有效时间（TTL）为 30 秒，因此平台必须能在其过期前完成交换。超过这个时间再尝试交换会被拒绝，而“此授权码已过期”正是这次拒绝的提示。企业并没有做错什么，弹窗完成得慢并不是问题所在；计时从代码返回的那一刻就开始了。 ### 为什么弹窗完成得晚或重复完成时会出现这个错误？ 有几种情况会让交换超过这一时限。 一种是流程完成时，浏览器标签页被留在后台，或者笔记本电脑进入了休眠，导致代码在签发很久之后才到达平台的服务器。另一种是平台的服务器把交换排在其他任务之后，而没有立即执行。还有一种是用户打开了两次流程并且都完成了，而平台在第二个窗口完成之后，才去交换第一个窗口的代码。 在测试中还有第四种情况：从浏览器控制台复制代码，再用 cURL 或 Postman 手动交换。Meta 的指南正是针对这种做法给出了警告，并建议在开始之前先准备好交换请求。 ### 如何完成连接？ 请在单个窗口中从头重新运行流程，并在完成时让平台的页面保持在前台。每次完成都会返回新的代码，平台只需尽快交换该代码即可。 对于 Coexistence 号码，请尽快操作。企业完成流程时，Meta 会转换 WhatsApp Business 账户；平台完成客户接入后，有 24 小时的时间同步消息历史记录，超过后必须先将该企业取消接入，再让其重新完成流程。 在平台一侧，根本的解决办法是在代码到达的那一刻就在服务器上完成交换，并且排在所有其他接入步骤之前。 - 用同一个代码重试令牌交换。它在 30 秒后就已过期，不会再恢复有效。 - 同时在两个窗口中运行注册流程。只有正在被交换的那次尝试所返回的代码才有效。 - 在浏览器中交换代码。Meta 要求交换必须是携带应用密钥的服务器到服务器请求。 **企业到底有没有连接成功这个号码？** 企业已完成 Meta 的流程，但平台无法将代码换成可用的令牌，所以暂时还不能对该号码进行操作。重新运行流程即可获得新的代码。 **可以让代码的有效期更长吗？** 不能。30 秒的有效时间由 Meta 设定，任何平台都无法延长。 **WhatsApp Business 应用会受到影响吗？** 不会。在问题解决期间，该应用在手机上仍可正常使用。 **这与访问令牌过期是一回事吗？** 不是。这里指的是短期有效的注册代码。正常连接上的访问令牌过期时，会返回错误 190。 --- ## “您的应用缺少 Cloud API 配套配对所需的 Graph API 权限” https://easycoexistence.com/zh-hans/docs/coexistence-error-companion-pairing-permission 此消息表示发起注册的平台缺少 Meta 要求的 WhatsApp 权限，或这些权限未达到 Meta 要求的访问级别，因此无法将 WhatsApp Business 应用号码连接到 Cloud API。只有平台持有 Advanced access 的权限，Meta 才允许企业授予。企业无法解决此问题，必须由平台修复。 ### 这条消息是什么意思？ 完整内容为：“Your app is missing required Graph API permissions for Cloud API companion pairing. Please verify advanced WhatsApp Business permissions are granted, then try again.”（您的应用缺少 Cloud API 配套配对所需的 Graph API 权限。请确认已授予高级 WhatsApp Business 权限，然后重试。）Meta 的公开错误参考文档并未列出这句确切的措辞，但其中每一部分都对应 Meta 有文档记载的内容。 “Your app”指的是运行注册流程的平台所使用的 Meta 应用，而不是手机上的 WhatsApp Business 应用。Meta 没有公开定义 companion pairing；结合上下文来看，它描述的是 Cloud API 接入一个仍注册在 WhatsApp Business 应用中的号码，也就是 Coexistence 的运作方式。而“advanced”WhatsApp Business 权限指的是 Advanced access，即 Meta 通过应用审核授予的访问级别。 ### 涉及哪些权限？ Meta 的权限文档列出了 WhatsApp 集成通常需要的两项权限。whatsapp_business_management 涵盖账户元数据、消息模板、电话号码、分析数据和账户 Webhook。whatsapp_business_messaging 涵盖发送消息，以及接收消息和状态 Webhook。 对于客户使用其应用的合作伙伴，Meta 要求应用所需的每一项权限都通过应用审核并获得 Advanced access。Meta 直接说明了后果：如果某项权限没有 Advanced access，客户就无法通过 Embedded Signup 把该权限授予应用。在没有 Advanced access 的情况下，使用 whatsapp_business_management 对应用并不拥有的账户发起调用，会返回错误 200。 平台可以用 Meta 的 debug_token 端点检查访问令牌，以确认企业实际授予了哪些权限，已授予的权限会列在 scopes 下。 ### 企业可以做什么？ 企业自身能做的很少，也不应尝试修改自己的 Meta 设置来消除此错误。解决办法在平台一侧：平台需要是 Tech Provider 或 Solution Partner（Meta 将其列为接入 WhatsApp Business 应用用户的要求），并且需要让 WhatsApp 权限的 Advanced access 获得批准。 企业可以做的是，把确切的消息内容反馈给平台，待平台确认已获得访问权限后再重试，或者改用已经具备该资格的平台。在此之前，在同一平台重试相同的流程只会得到相同的结果，也不会影响手机上的 WhatsApp Business 应用。 - 在企业自己的 Meta 设置中授予更多权限。缺少的访问权限属于平台的应用。 - 在没有通过应用审核的开发者应用上自行托管工具。没有 Advanced access，企业就无法授予所需的权限。 - 在同一平台上反复重试。只有该平台的访问权限发生变化，结果才会改变。 **我的 WhatsApp Business 应用出问题了吗？** 没有。该消息指的是平台的 Meta 应用，而不是您手机上的应用，您的应用会继续正常使用。 **我可以自己授予这项权限吗？** 只有平台持有 Advanced access 的权限，才会出现在您的授权列表中。必须先为平台批准缺少的访问权限。 **平台如何获得 Advanced access？** 作为客户使用其应用的合作伙伴，针对应用所需的每一项权限，通过 Meta 应用审核获得。 **企业需要通过应用审核吗？** 不需要。Meta 表示，仅访问自己业务数据的直接开发者，既不需要应用审核，也不需要 Advanced access。 --- ## WhatsApp 错误 0：无法验证应用用户 https://easycoexistence.com/zh-hans/docs/whatsapp-error-0 错误代码 0 表示 Meta 无法验证访问令牌背后的应用用户。Meta 的说明是：“We were unable to authenticate the app user.”原因可能是令牌已过期、已失效，或用户屏蔽了所有应用访问其数据。解决办法是获取新的访问令牌，而不是重试。 ### WhatsApp 错误代码 0 是什么意思？ 它表示平台收到了请求，但无法将其对应到一个可信的应用用户。 Meta 在 Cloud API 错误参考的授权错误类别下列出了代码 0，详细说明为“We were unable to authenticate the app user.”其给出的可能原因都与令牌有关：令牌已过期、已失效，或授予令牌的用户更改了设置，禁止所有应用访问其数据。 这份清单中没有任何一项涉及电话号码、WhatsApp Business 账户或正在发送的消息。请求还没走到这些内容被检查的那一步。 ### 如何修复错误 0？ 获取新的访问令牌。这是 Meta 列出的补救办法，也是唯一有效的办法。 在替换之前，请先弄清是三种原因中的哪一种，因为忽略原因的话，问题还会再次出现。有效期较短的用户令牌会按时再次过期。已失效的令牌会一直失败，直到有人重新授予访问权限。如果用户完全关闭了应用访问，必须先重新开启，该用户的任何令牌才能使用。 对于服务器到服务器的发送，Meta 的访问令牌指南推荐使用 System User 令牌，并称其有效期长，适合无需用户参与的自动化服务。 ### 错误 0 和错误 190 是一回事吗？ 两者在实际中有重叠，但 Meta 将它们分开列出。 错误 190 的详细说明是“Your access token has expired.”错误 0 的范围更广：它涵盖令牌过期、令牌失效，以及用户完全屏蔽应用访问。两者位于同一张授权错误表中，解决办法也都是获取新令牌。 实际的区别在于诊断。收到 190，说明令牌已因时间而失效。收到 0，说明验证失败，原因需要您自己查明。这一步值得做，否则换上的新令牌可能一小时后以同样的方式失败。 - 重试同一个请求。未通过验证的令牌依然无法通过验证，每次重试都会再次返回代码 0。 - 重新连接号码。号码从未被检查过，再次为其办理接入只会让企业主白忙一场，毫无改变。 - 为后端任务签发新的短期用户令牌。它会按时过期，错误随之再次出现。 **错误 0 是否表示我的号码已断开连接？** 不是。Meta 给出的代码 0 的原因都与访问令牌有关，与号码以及手机上的 WhatsApp Business 应用无关。 **错误 0 记录在哪里？** 记录在 Meta 的 Cloud API 错误代码参考中的授权错误表里。Cloud API 基于 Graph API 构建，两者使用相同的错误格式。 **等一等，错误 0 会自行消失吗？** 不会。已过期或已失效的令牌不会自行恢复，必须换上新令牌。 **如何查看令牌可以做什么？** 使用 Meta 的访问令牌调试工具或 debug_token 端点。两者都会显示令牌是否有效、何时过期以及具有哪些权限。 --- ## WhatsApp 错误 3：功能或权限问题 https://easycoexistence.com/zh-hans/docs/whatsapp-error-3 错误代码 3 表示调用端点的应用缺少该端点所需的功能或权限。Meta 的描述是“Capability or permissions issue.”，Graph API 将其命名为 API Method。解决方法是用访问令牌调试器查看令牌已获授予的权限，再补上端点所需的那一项。 ### WhatsApp 错误代码 3 是什么意思？ 它表示请求已通过身份验证，但应用无权执行它所请求的操作。 Meta 在 Cloud API 参考文档中，把代码 3 列为授权类错误，详细说明为“Capability or permissions issue.”。Cloud API 沿用的 Graph API 错误处理指南，则把同一个代码称为 API Method，并提示要确认应用具备该调用所需的功能或权限。 也就是说，令牌本身是可用的。问题不在身份，这正是它与代码 0 和 190 的区别。问题出在令牌被允许访问哪些内容。 ### 如何查看令牌拥有哪些权限？ 使用访问令牌调试器，或使用 debug_token 端点，两者返回的信息相同。 响应的 scopes 属性中会列出已授予的权限。请把这份列表与失败端点的参考页面对照，因为每个端点的参考文档都会注明它所需的权限。 对于 WhatsApp，两项权限几乎涵盖所有场景。账户元数据、模板、号码列表、分析数据和账户 Webhook 需要 whatsapp_business_management。发送任何消息，以及接收消息和状态 Webhook，则需要 whatsapp_business_messaging。只持有其中一项的令牌，在需要另一项的调用上会失败。 ### 为什么合作伙伴应用会遇到错误 3，而直接开发者不会？ 因为为其他企业提供服务的合作伙伴，多了一道关卡。 Meta 的权限指南指出，如果合作伙伴的客户通过其应用访问自己的数据，该合作伙伴必须通过 App Review，并为应用所需的每项权限取得 Advanced 访问权限。只处理自家业务数据的直接开发者，则不需要 App Review 或 Advanced 访问权限。 因此，同一段代码在开发者自己的账户上可能运行正常，在客户的账户上却会失败。出现这种情况时，要问的不是令牌缺少哪项权限，而是应用是否已获批准，可以对不属于自己的资产使用该权限。 - 生成权限范围相同的新令牌。权限相同的新令牌，会在同一个地方失败。 - 在应用设置中查看权限名称，而不是查看令牌本身。真正起作用的是令牌被授予的权限。 - 只用自己的账户测试。合作伙伴应用必须先取得 Advanced 访问权限，客户账户才会接受调用。 **错误 3 是我的电话号码出了问题吗？** 不是。它涉及的是应用令牌被允许做什么。请求被拒绝之前，系统不会检查号码。 **错误 3 和错误 10 有什么区别？** 代码 3 表示功能或权限问题。代码 10 表示某项权限未被授予或已被移除。两者都通过检查令牌的权限范围来解决。 **发送消息需要哪项权限？** whatsapp_business_messaging。Meta 的权限指南指出，发送任何类型的消息都需要它。 **重试有用吗？** 没有用。令牌的权限不会在两次尝试之间改变，所以结果相同。 --- ## WhatsApp 错误 4：应用已达到 API 调用速率限制 https://easycoexistence.com/zh-hans/docs/whatsapp-error-4 错误代码 4 表示应用已达到 API 调用速率限制。Meta 的说明是“The app has reached its API call rate limit.”它统计的是应用在滚动 1 小时内发出的调用次数，而不是某个号码发送的消息数。请在应用控制台查看用量，等待一段时间，并减少应用调用 API 的频率。 ### WhatsApp 错误代码 4 是什么意思？ 它表示您的应用在当前窗口内发起了过多的 API 调用，在计数下降之前，后续调用都会被拒绝。 Meta 将错误代码 4 归入限流错误，详细文本为“The app has reached its API call rate limit.”Graph API 错误处理指南称其为 API Too Many Calls，并将其描述为临时性的限流问题。 它旁边还有两个容易与之混淆的限流代码。80007 表示 WhatsApp Business 账户达到了速率限制。130429 表示 Cloud API 的消息吞吐量。错误代码 4 与这两者都不同：它是应用自身的调用额度。 ### 应用的调用上限是如何计算的？ 对于使用应用访问令牌发出的请求，Meta 的 Graph API 速率限制指南给出了一个公式：1 小时内的调用次数等于 200 乘以用户数。 用户数以应用的每日唯一活跃用户为基础，当每日用量下降时，会参考每周和每月的数字。这是针对整个应用的限制，而不是按用户计算，因此少数活跃用户就可能用掉大部分额度。 指南还提到，用量会显示在应用控制台中，并且在调用达到一定数量后，响应中会出现 X-App-Usage 标头。借助这个标头，您可以在错误 4 出现之前就发现用量正在接近上限。 ### 出现错误 4 之后应该怎么做？ 先暂停调用一段时间，然后减少调用。 关于第一点，Meta 的速率限制指南说得很明确：达到上限后，请停止发起 API 调用，因为继续调用会增加调用计数，并延长调用恢复成功所需的时间。 第二点在于设计。请将请求均匀分散，而不是集中爆发；筛选响应内容，让一次调用就返回所需数据；避免调用获取重叠的数据。轮询通常是罪魁祸首。每隔几秒就查询同一个账户状态的集成，会把额度浪费在已经掌握的答案上。 - 在循环中重试。每多一次调用，计数就增加一次，恢复时间也会被推得更远。 - 把它当作发送限制。错误代码 4 统计的是应用的调用次数，消息吞吐量对应的是 130429。 - 以很短的间隔轮询状态端点。重复读取没有变化的数据会消耗每小时的额度。 **错误 4 与错误 130429 是一回事吗？** 不是。130429 是某个号码的消息吞吐量。错误 4 指的是您的应用已发起的 API 调用次数。 **错误 4 会持续多久？** 直到滚动 1 小时窗口内的调用次数降到上限以下。在此期间继续调用会延长持续时间。 **在哪里可以看到我的应用离上限还有多远？** 在应用控制台的 Application Rate Limit 部分，以及响应中返回的 X-App-Usage 标头里。 **错误 4 与错误 80007 是一回事吗？** 不是。Meta 在 WhatsApp Business 账户达到速率限制时使用 80007，而错误 4 统计的是应用自身的调用次数。 --- ## WhatsApp 错误 10：权限未授予或已被移除 https://easycoexistence.com/zh-hans/docs/whatsapp-error-10 错误代码 10 表示应用的访问令牌缺少该端点所需的权限，原因可能是从未授予，也可能是已被移除。Meta 的描述为“Permission is either not granted or has been removed.”。Meta 还列出两个与 WhatsApp 相关的原因：Flows with Endpoint 中的号码未加入许可名单，以及未满足某个 API 的资格要求。 ### WhatsApp 错误代码 10 是什么意思？ 它表示访问令牌已到达 Meta 并被识别，但该调用所需的权限不在令牌上。 Meta 的 Cloud API 参考为错误代码 10 给出的详情文本是“Permission is either not granted or has been removed.”。Graph API 错误处理指南称之为 API Permission Denied，并建议处理缺失的权限。 “已被移除”这一点很重要。权限可能在设置时授予，之后又被收回，例如有人在 Business Settings 中撤销了应用的访问权限。因此，一个运行了数月的集成，即使自身代码没有任何改动，也可能开始返回 10。 ### Meta 还列出了哪些导致错误 10 的原因？ 有两个原因专属于 WhatsApp，而且都很容易被忽略，因为它们与权限范围完全无关。 对于带 Endpoint 的 WhatsApp Flows，Meta 要求确认用于设置商家公钥的号码已加入许可名单。即使令牌具备所有权限，不在许可名单内的号码也会产生该错误代码。 Meta 还指出，如果账户不满足所调用 API 的资格要求，也会收到该错误代码。这种情况下，更换令牌无济于事，因为卡住的是账户的资格，而不是凭据。 ### 如何修复错误 10？ 先使用访问令牌调试工具，这是 Meta 指明的第一项检查。 如果 scopes 列表缺少该端点所需的权限，请让商家重新授予。对于合作伙伴应用，还需要确认该权限已获得 Advanced access，因为 Meta 的权限指南要求客户账户必须具备此级别。 如果 scopes 看起来完整，再排查这两个 WhatsApp 相关原因。对于 Flows 调用，请检查设置公钥的号码是否在许可名单中。对于其他调用，请先阅读所调用 API 的资格要求，确认账户已满足，再考虑更改任何凭据。 - 误以为是某次部署导致集成出错。在 Business Settings 中移除权限，即使代码完全没有改动，也会产生该错误代码。 - 在原因是资格问题时重建令牌。凭据无法让不符合资格的账户变得符合资格。 - 忽视 Flows 的许可名单。在 Flows with Endpoint 中，不在名单内的号码即使权限齐全也会返回 10。 **错误 10 与错误 131005 是一回事吗？** 两者在 Meta 参考文档中的描述相同。错误代码 10 是 Graph API 的代码，131005 属于 WhatsApp 的代码范围。两者的检查方法相同。 **昨天还正常的号码，今天会出现错误 10 吗？** 会。Meta 的描述包含已被移除的权限，因此先前授予的访问权限之后可能被收回。 **错误 10 是否表示我的访问令牌已过期？** 不是。令牌过期对应的是错误代码 190 或 0。错误代码 10 表示令牌有效，但缺少某项权限。 **如何查看已授予了哪些权限？** 调用 debug_token 或打开访问令牌调试工具。scopes 属性会列出令牌上的每一项权限。 --- ## WhatsApp 错误 200：未提供访问令牌 https://easycoexistence.com/zh-hans/docs/whatsapp-error-200 错误代码 200 表示请求到达 Meta 时没有携带访问令牌。Meta 的说明是“No access token was provided”，API 返回的消息为“Provide valid app ID”。它出现在某些 GET 端点上，例如 whatsapp_business_profile。200 至 299 的错误代码也涵盖未授予或已被移除的权限。 ### 为什么错误 200 显示“Provide valid app ID”？ 因为这是 API 返回的消息，而实际的问题是缺少令牌。 Meta 的错误参考文档说明，当请求未包含令牌时，错误代码 200 会出现在某些 GET 端点上，例如 whatsapp_business_profile，API 返回的消息为“Provide valid app ID”。同一份文档也指出，对于同样的遗漏，其他端点可能返回 190 或 104。 也就是说，措辞指向 app ID，而解决办法在令牌。请检查 Authorization 标头是否存在且拼写正确，并确认构建请求时，存放令牌的变量确实已被赋值。 ### 错误 200 什么时候表示缺少权限？ 当令牌存在，但应用缺少该调用所需的权限时。 Meta 将 200 至 299 的范围列为“Permission is either not granted or has been removed”，处理方法与错误代码 10 相同：在访问令牌调试工具中检查令牌。文档记录了两种具体情况。权限指南说明，应用在没有 Advanced access 的情况下，对其企业并不拥有的 WABA 使用 whatsapp_business_management，会收到错误 200。注册指南说明，在没有 whatsapp_business_management 的情况下注销号码，会返回错误 200。访问令牌指南还补充了第三种情况：System User 令牌所对应的用户无权访问被查询的资源时，请求会被以 200 拒绝。 请阅读消息文本来区分这些情况。缺少令牌时，消息为“Provide valid app ID”。 ### 错误 200 与错误 190 有何不同？ 错误 190 表示已发送令牌，但令牌已过期。错误 200 的第一种含义则是未发送令牌。 Meta 的参考文档直接说明了这一区别：200 的处理方法是确保请求包含有效的访问令牌，并称这种情况不同于 190，后者针对已过期或无效的令牌。 这会改变排查的方向。190 让您去查看令牌的有效期和续期。出现“Provide valid app ID”的 200 则让您去检查构建请求的代码，因为凭据根本没有离开您的系统。 - 去排查 app ID 的问题。消息虽然写着 app ID，但 Meta 文档记载的原因是请求没有携带令牌。 - 在令牌从未发送的情况下去续期令牌。请求仍然遗漏新令牌，就会产生同样的错误。 - 把每个 200 都当作缺少令牌。在令牌存在时，200 至 299 的范围表示缺少权限。 **错误 200 会出现在正常运行的号码上吗？** 会。它描述的是请求，而不是号码。即使号码状态完全正常，仍然会拒绝没有携带令牌的调用。 **为什么一个端点返回 200，另一个返回 190？** Meta 表示，对于缺少令牌的情况，某些 GET 端点返回 200，而其他端点可能返回 190 或 104。 **注销号码需要特殊权限吗？** 需要。Meta 的注册指南说明，在没有 whatsapp_business_management 的情况下注销号码，会返回错误 200。 **错误 200 与错误 10 有关吗？** 就权限这一含义而言，有关。两者的说明都是权限未被授予或已被移除。 --- ## WhatsApp 错误 130472：消息因实验而未发送 https://easycoexistence.com/zh-hans/docs/whatsapp-error-130472 错误 130472 表示营销消息模板未能发送，因为收件人处于 Meta 的营销消息实验中。Meta 的说明是“Message was not sent as part of an experiment.”。少部分 WhatsApp 用户不会收到营销模板，除非客户服务窗口或免费入口窗口处于开启状态。这类消息不会计费。 ### WhatsApp 错误 130472 是什么意思？ 它表示 Meta 拦截了一条营销模板，因为收件人属于某个实验组。 Meta 的实验说明页指出，WhatsApp 会持续开展实验，以衡量消息对用户体验的影响。在营销消息实验中，极小比例的 WhatsApp 用户不会收到任何企业发来的营销模板消息，除非与该企业之间的客户服务窗口或免费入口窗口处于开启状态。 当您向这类用户发送营销模板时，WhatsApp 不会发送该消息，也不会向您收费。您会收到一条状态 Webhook，其中 status 为 `failed`，错误代码为 130472。 ### 遇到错误 130472 时，如何联系到这位客户？ 让对方先给您发消息，这样就会开启客户服务窗口。 Meta 的实验说明页明确指出，重发模板会得到同样的错误。它建议的做法是通过其他非 WhatsApp 渠道联系用户，请对方给您发消息，然后在已开启的客户服务窗口内发送模板。 该实验只针对营销模板。无论由哪家企业发送，只要用户在实验组内就会受到影响，所以问题与您的账户、模板或号码无关，修改这些内容也没有帮助。 ### 集成系统应如何处理错误 130472？ 应把它视为该消息的最终状态，而不是需要重试的失败。 由于这个错误是通过状态 Webhook 送达的，而不仅仅出现在发送响应中，处理逻辑应放在 Webhook 处理程序里。将该消息标记为“被实验拦截”，不要加入重试队列，也不要计入失败率警报，以免它被误当成送达问题。 在报表中也值得单独列出。若一次营销活动中出现少量 130472，并不代表质量或触达因您的操作而下降。把它们与真正的失败混在一起统计，只会让数据更难解读。 - 重发模板。Meta 表示重发会返回同样的错误。 - 把它当成质量问题。该实验对所有企业一视同仁，针对的是一组用户。 - 只查看发送响应。130472 状态是通过消息 Webhook 送达的。 **被 130472 拦截的消息会收费吗？** 不会。Meta 的实验说明页指出，该消息不会发送，您也无需为此付费。 **我可以让我的企业退出这个实验吗？** 不可以。Meta 表示不提供任何例外或退出方式，而且实验没有固定的结束日期。 **错误 130472 会影响实用类模板吗？** Meta 将该实验描述为针对营销模板消息，并未列出其他类别。 **我还能怎样把消息送达？** 请通过其他渠道让客户给您发消息。在已开启的客户服务窗口内，即可发送模板。 --- ## WhatsApp 错误 131005：访问被拒绝，缺少权限 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131005 错误 131005 表示访问令牌缺少 WhatsApp 端点所需的某项权限，原因是该权限从未授予，或之后被移除。Meta 的说明是 “Permission is either not granted or has been removed.”。解决办法是先用访问令牌调试器检查令牌，再授予缺失的权限，或改用已具备该权限的令牌。 ### WhatsApp 错误 131005 是什么意思？ 这表示令牌被确认为真实有效，但不具备端点所检查的权限。 Meta 的 Cloud API 参考文档列出了 131005，详细说明为 “Permission is either not granted or has been removed.”。Graph API 错误 10 的说明与此完全相同。区别只在范围：10 是通用的 Graph API 代码，而 131005 属于以 131 开头的 WhatsApp 错误代码。 既然说明相同，诊断方法也相同。Meta 对两者给出的补救办法都是使用访问令牌调试器，确认应用拥有该端点所需的权限。 ### 通常缺少的是哪项权限？ 通常是两项 WhatsApp 权限之一，具体是哪一项取决于调用的用途。 Meta 的权限指南按用途做了划分。发送任何类型的消息，以及接收消息和状态 Webhook，需要 whatsapp_business_messaging。获取账户元数据、管理消息模板、列出电话号码、查看分析数据和接收账户 Webhook，需要 whatsapp_business_management。 只带管理权限生成的令牌可以读取账户并列出消息模板，但一尝试发送消息就会失败。在生成系统用户访问令牌时，Meta 的访问令牌指南要求您同时分配 business_management、whatsapp_business_management 和 whatsapp_business_messaging。 ### 如何修复错误 131005？ 先读取令牌，再只修改缺少的部分。 调用 debug_token 端点，或把令牌粘贴到访问令牌调试器中。scopes 属性会列出已授予的所有权限。将它与失败端点的参考页面逐项对照。 如果缺少某项权限，请生成包含该权限的新令牌；如果令牌来自合作伙伴流程，则请业务所有者重新授予。如果权限齐全但错误依旧，请检查令牌背后的系统用户是否已获准访问该特定的 WhatsApp Business Account，因为令牌的权限范围可以很完整，却仍未分配到该资产。 - 以为令牌已过期。令牌过期会返回 190 或 0。此代码表示令牌可用，但缺少某项权限。 - 只用管理权限生成令牌，却拿来发送消息。发送消息需要 whatsapp_business_messaging。 - 只检查 scopes 就停下来。系统用户还需要获准访问该特定的 WhatsApp Business Account。 **131005 与 10 是同一个错误吗？** 两者在 Meta 的参考文档中说明相同。131005 属于 WhatsApp 范围，10 属于 Graph API 范围。 **设置完成后权限还会被移除吗？** 会。Meta 的说明明确包含已被移除的权限，而不只是从未授予的权限。 **错误 131005 会影响手机上的 WhatsApp Business 应用吗？** 不会。它只涉及 API 访问令牌。手机上的应用照常使用。 **出现错误 131005 后应该重试吗？** 不应该。使用同一令牌重试只会得到相同的结果。请先修复权限。 --- ## WhatsApp 错误 131037：555 号码没有已批准的显示名称 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131037 错误 131037 表示消息是从显示名称尚未获批的 555 企业电话号码发出的。Meta 的说明是：“用于发送该请求的 555 企业电话号码没有已批准的显示名称。”在 Meta 批准显示名称之前，555 号码无法发送消息，因此解决办法是修改显示名称。 ### 什么是 555 企业电话号码？ 这是 Meta 通过 Embedded Signup 向符合条件的企业提供的一种号码。 Meta 的 Embedded Signup 概述指出，企业客户最多可以申领两个 555 号码。这类号码使用美国国家区号 +1 和 555 区号，会自动通过验证，不能迁移到其他 WhatsApp Business 账户，也不能在 WhatsApp Business Platform 之外使用。 除此之外，它们与标准企业号码一样，受定价规则和质量评级约束，只多了一个条件，这也正是此错误的由来：555 号码必须先通过显示名称审核，才能发送消息。 ### 如何修复错误 131037？ 让显示名称获得批准，实际操作就是把它改成能通过审核的名称。 Meta 给出的补救办法是修改 555 号码的显示名称，并指向其帮助中心中关于修改 WhatsApp Business 显示名称的文章。在 WhatsApp Manager 中，路径是账户工具，电话号码，进入该号码的资料选项卡，然后在显示名称部分点击编辑。请遵循 Meta 的显示名称指南，因为名称被拒绝后，您又会回到原点。 Meta 的显示名称指南还说明，名称修改获批后，您有 14 天时间重新注册该号码，而在获批之前重新注册不会有任何效果。 ### 如何查看显示名称是否已获批准？ 请求该电话号码 ID 的 name_status 字段。 Meta 的显示名称指南指出，verified_name 字段只保存送审的名称字符串，并不显示名称是否获批，而 name_status 字段可以。phone_number_name_update Webhook 也会报告审核结果，其中 decision 为 APPROVED 或 REJECTED。 名称被拒绝时，name_status 会设为 DECLINED。Meta 建议您查看指南并修改名称，或通过开发者支持提交申诉。在状态改变之前，该 555 号码的每次发送都会继续返回 131037。 - 把 verified_name 当作获批的依据。Meta 表示，只有 name_status 才能显示名称是否获批。 - 在获批前重新注册。Meta 表示，在新名称获批之前，重新注册没有任何效果。 - 没有阅读指南就反复修改名称。Meta 规定每 30 天最多可修改 10 次。 **错误 131037 会影响普通企业号码吗？** 不会。Meta 的说明明确针对的是没有已批准显示名称的 555 企业电话号码。 **我可以把 555 号码迁移到其他账户吗？** 不可以。Meta 表示，555 号码不能迁移到其他 WhatsApp Business 账户。 **我如何得知名称已获批准？** 您会收到一条 decision 为 APPROVED 的 phone_number_name_update Webhook，同时 name_status 会变为 APPROVED。 **显示名称被拒绝怎么办？** 请按照 Meta 的显示名称指南修改名称，或通过开发者支持提交申诉。 --- ## WhatsApp 错误 131057：业务账户处于维护模式 https://easycoexistence.com/zh-hans/docs/whatsapp-error-131057 错误 131057 表示 WhatsApp Business 账户处于维护模式，因此针对该账户的请求会在短时间内被拒绝。Meta 的说明是 “Business Account is in maintenance mode.”。Meta 给出的原因之一是吞吐量升级，最长需要 1 分钟。请等待后重试，不要修改请求。 ### WhatsApp 错误 131057 是什么意思？ 这表示 Meta 已将 WhatsApp Business 账户置于维护模式，此刻不接受针对该账户的请求。 Cloud API 参考文档列出的详情文本为 “Business Account is in maintenance mode”，并说明原因之一可能是账户上的吞吐量升级。“原因之一”这个措辞很重要：Meta 只是把升级列为可能的原因，并非唯一原因。 请求本身没有问题。维护结束后，原样重发同一调用预计即可成功，因此这是少数只需等待就能解决的错误代码之一。 ### 为什么吞吐量升级会导致错误 131057？ 因为号码在迁移到更高速率期间会短暂不可用。 Meta 的吞吐量指南指出，Cloud API 默认支持每秒最多 80 条消息，通过自动升级最高可达 1,000 条。升级过程最长可能需要 1 分钟，在此期间该号码无法在平台上使用，任何 API 请求都会返回 131057。首次升级之后，后续提升不会再有停机。 指南列出了资格条件：Business Portfolio 的消息上限为无限制，在滚动 24 小时内于客户服务窗口之外联系至少 100K 名唯一用户，且质量评级为 Medium 或更高。 ### 错误 131057 会出现在 Coexistence 号码上吗？ 任何号码都可能出现，但吞吐量的解释不太适用于 Coexistence 号码。 Meta 的吞吐量指南指出，同时在 WhatsApp Business 应用和 Cloud API 上使用的号码，吞吐量固定为每秒 20 条消息，以便与应用保持兼容。同一指南中所述升级到 1,000 的自动升级，适用于默认级别的号码。 因此在 Coexistence 号码上，请按字面含义理解 131057，即账户处于维护模式，并等待后再重试。如果持续超过几分钟，请携带响应中的 fbtrace_id 联系 Meta 支持，而不要重新连接号码。 - 修改请求。请求本身有效，账户处于维护模式时修改请求没有任何帮助。 - 不加延迟地重试。升级期间的这 1 分钟内，每次调用都会返回同一个错误代码。 - 重新连接号码。维护模式在 Meta 一侧，无需商家做任何操作即会结束。 **维护模式会持续多久？** Meta 表示吞吐量升级最长需要 1 分钟。对于其他维护原因，Meta 没有公布持续时间。 **升级完成后会通知我吗？** 会。号码升级完成后，Meta 会发送 phone_number_quality_update Webhook，其中 event 设置为 THROUGHPUT_UPGRADE。 **更高的吞吐量会更贵吗？** 不会。Meta 的吞吐量指南指出，升级是免费的，不影响定价。 **错误 131057 与 130429 有关吗？** 间接相关。130429 表示您发送的速度超过了吞吐量允许的范围，而 131057 可能出现在该吞吐量被提升的过程中。 --- ## WhatsApp 错误 132005：译文过长 https://easycoexistence.com/zh-hans/docs/whatsapp-error-132005 错误 132005 表示所发送的消息模板，其文本在所用语言版本中过长。Meta 的描述为“译文过长”。Meta 建议在 WhatsApp Manager 中检查该消息模板是否已翻译，然后查看模板状态。消息模板的正文最多 1,024 个字符，页脚文本最多 60 个字符。 ### WhatsApp 错误 132005 是什么意思？ 它表示消息模板发送失败，因为所发送语言版本的文本超出了平台允许的长度。 Meta 将 132005 列为模板错误之一，详细说明为“译文过长”。Meta 给出的处理方式是：在 WhatsApp Manager 中检查并确认该消息模板已翻译，同时参阅其模板质量文档，了解如何查看模板状态。 关键在于“译文”二字。消息模板按语言分别存在，失败的是与您发送请求中语言代码相对应的那个版本，它可能并不是您最初撰写并检查过的版本。 ### 如何修复错误 132005？ 在 WhatsApp Manager 中打开该消息模板，查看您正在发送的语言版本。 确认请求中的语言代码有对应的译文，且其状态允许发送。然后对照 Meta 的组件限制检查长度：正文最多 1,024 个字符，页脚最多 60 个字符。译文往往比原文更长，因此在一种语言中没有问题的消息模板，换成另一种语言可能就会超限。 如果某个译文过长，请在 WhatsApp Manager 中缩短该语言版本。不作修改就以同一语言再次发送同一消息模板，仍会以同样的方式失败。 ### 如何在多语言消息模板中避免错误 132005？ 提交之前，请对照限制检查每一个语言版本，而不只是第一个。 在您起草消息模板的工具中加入简单的长度检查，就能发现大多数问题：统计每个译文的正文和页脚字符数，并与 1,024 和 60 比较。如果正文含有变量，请留出余量，因为发送时填入的值也是客户收到的消息的一部分。 请让发送逻辑中的语言代码只对应确实存在的译文。如果请求的语言在该消息模板中不存在，则是另一个错误 132001，把两者区分开，日志会更易读。 - 只检查原文语言。失败的是与请求语言代码相对应的译文版本。 - 不作编辑就重发。文本长度在多次尝试之间不会改变。 - 与 132001 混淆。该代码表示消息模板在该语言下不存在或未获批准。 **错误 132005 是变量引起的吗？** Meta 的描述指的是译文过长。请先检查译文的长度，并为变量值留出空间。 **消息模板的正文上限是多少？** Meta 的模板组件参考规定，正文最多 1,024 个字符。 **在哪里检查译文？** 在 WhatsApp Manager 中打开该消息模板，查看与您请求相对应的语言版本。 **错误 132005 与 132001 相同吗？** 不同。Meta 将 132001 描述为消息模板在指定语言下不存在或尚未获批。 --- ## WhatsApp 错误 133000：之前的注销尝试失败 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133000 错误 133000 表示之前注销该电话号码的尝试失败，在问题解决之前，号码无法注册。Meta 的说明是“A previous deregistration attempt failed.”。Meta 给出的修复方法是先重新注销号码，再注册。这两个端点的限制都是每个号码在 72 小时滚动窗口内最多 10 次请求。 ### WhatsApp 错误 133000 是什么意思？ 这表示平台上仍记录着该号码一次未完成的注销，因此不会在其基础上再次注册该号码。 Meta 将 133000 列出，详情文本为“A previous deregistration attempt failed”，并给出一行补救方法：先重新注销号码，再注册。因此，这个错误通常出现在注册调用中，尽管原因在之前的注销调用。 注销是通过向该电话号码 ID 的 deregister 端点发送 POST 请求完成的。Meta 的注册指南提醒：注销后，该号码在重新注册之前无法通过 Cloud API 使用，但注销不会删除号码或其消息记录。 ### 如何修复错误 133000？ 重新执行注销，确认成功后再注册。 注销调用成功时，会返回 success 设为 true。只有收到这个响应之后，才应进行注册调用，并带上 messaging_product 字段和该号码的 6 位两步验证 PIN。 注销调用需要 whatsapp_business_management 权限。Meta 的注册指南指出，缺少该权限的注销请求会返回错误 200，容易被误认为是同类问题再次失败。如果注销调用本身一直失败，请先查看每个响应中的 details 值，再发送下一次请求，因为每次尝试都会计入下文所述的限制。 ### 为什么次数限制在这里很重要？ 因为修复这个错误本身就是一连串尝试，而 Meta 对次数设有上限。 注册指南规定，注册和注销两个端点都限制为每个商业号码在 72 小时滚动窗口内最多 10 次请求。超出后会返回错误 133016，该号码在接下来的 72 小时内将无法执行该操作。 如果脚本在失败后循环调用注销和注册，几秒钟就可能用完额度，让号码三天内无法使用。请有意识地逐次尝试，记录每个响应，并在失败两三次后停下来排查，而不是自动继续。 - 没有先注销就再次调用注册。Meta 的补救方法要求注销完成后才能注册。 - 自动循环调用注册和注销。72 小时内最多 10 次请求，超出会使号码被禁止。 - 在没有 whatsapp_business_management 权限的情况下注销。这会返回错误 200，掩盖号码的真实状态。 **注销会删除我的号码吗？** 不会。Meta 的注册指南指出，注销不会删除号码或其消息记录。 **可以用 API 注销 Coexistence 号码吗？** 不可以。Meta 表示，同时用于 Cloud API 和 WhatsApp Business 应用的号码，不能使用 deregister 端点。 **尝试 10 次之后会怎样？** API 会返回 133016，并在接下来的 72 小时内禁止该号码执行此操作。 **重新注册时需要 PIN 吗？** 需要。启用两步验证后，注册需要提供该号码的 6 位两步验证 PIN。 --- ## WhatsApp 错误 133004：服务器暂时不可用 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133004 错误 133004 表示处理该请求的服务器暂时不可用。Meta 的说明是“服务器暂时不可用”。问题不在请求本身。Meta 建议先查看 WhatsApp Business Platform 状态页面，并阅读响应中的 details 值，然后延迟一段时间再重试。 ### WhatsApp 错误 133004 是什么意思？ 它表示平台在当时无法处理该请求，因为有一台服务器不可用。 Meta 在 Cloud API 错误参考中列出了 133004，details 文本为“服务器暂时不可用”。关键在“暂时”二字。访问令牌、号码和消息都没有被拒绝，同一个请求可能在稍后就能成功。 它属于 133 系列错误代码，其中大多数与号码的注册和注销有关，因此常在注册调用中遇到。不过 Meta 并未将其限定在注册场景，所以无论它出现在哪里，都应将其视为服务器状况。 ### 重试之前应该检查什么？ 有两件事，都在 Meta 给出的处理建议中。 第一，查看 metastatus.com 上的 WhatsApp Business Platform 状态页面。如果 Meta 正在通报故障，在故障解除之前重试没有意义，而且这个页面比您自己的日志更快给出答案。 第二，查看响应中 error_data 内的 details 值。Meta 的错误参考说明，details 是该错误最可能的原因，有时还附带处理建议。对于这个错误代码，Meta 明确要求在重试之前先查看它。如果状态页面正常，details 也没有给出等待时间，请采用逐步加长的间隔重试，而不是立即重试。 ### 133004 与其他临时性错误有何不同？ Meta 列出了几个表示某项内容短暂不可用的错误代码，建议在日志中把它们区分开。 代码 1 被描述为无效请求或可能的服务器错误，代码 2 被描述为因停机或过载造成的临时错误，131016 则表示某项服务暂时不可用。133004 明确指向服务器。 它们的处理方式相似：确认平台状态，阅读 details 值，并在重试前退避等待。不过仍应记录确切的错误代码，因为在某个时段集中出现的同一个代码，比一句笼统的“API 宕机了”更能帮助 Meta 支持团队定位问题。 - 在紧凑的循环中立即反复重试。服务器宕机时，下一毫秒也依然宕机。 - 忽略 details 值。Meta 要求在重试前阅读它，其中可能写明了原因。 - 修改请求来绕过错误。错误并不是由请求引起的。 **错误 133004 是我的问题吗？** 不是。Meta 将其描述为服务器暂时不可用，并非由请求引起。 **WhatsApp Business Platform 状态页面在哪里？** Meta 在错误代码参考中提供了链接：metastatus.com/whatsapp-business-api。 **重试前应该等待多久？** Meta 没有给出固定时间。请先查看 details 值和状态页面，然后以逐步加长的间隔重试。 **如果问题持续，应该向 Meta 支持提供什么？** 错误响应中的 fbtrace_id。Meta 表示它可能有助于排查该错误。 --- ## WhatsApp 错误 133009：两步验证 PIN 输入过快 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133009 错误 133009 表示两步验证 PIN 的尝试到达 Meta 的速度超过了它能接受的范围。Meta 的描述是“两步验证 PIN 输入过快”。PIN 可能正确，也可能错误。再次尝试之前，请先查看响应中的 details 值，并在它所指示的等待时间过去后，再发送下一次尝试。 ### WhatsApp 错误 133009 是什么意思？ 它表示该号码的 PIN 尝试间隔过短，Meta 拒绝了最新的一次尝试，但并没有判断它是否正确。 Cloud API 参考文档为 133009 给出的 details 文本是“两步验证 PIN 输入过快”，并附有一条指示：再次尝试之前，请先查看响应中的 details 值。 这个错误代码与相邻的两个代码有所区别。133005 表示 PIN 不正确。133008 表示该号码的 PIN 猜测次数过多。133009 只关乎频率，所以当某个流程在短时间内连续发送 PIN 尝试时就会出现，例如对 `register` 请求进行重试的循环。 ### 如何修复错误 133009？ 放慢速度，不要再猜测。 下一次尝试之前，请先查看 error_data 中的 details 值。Meta 的参考文档将 details 描述为该错误最可能的原因，而对于这个代码，它也是 Meta 要求您首先检查的内容。 然后确保下一次尝试使用的是确实有人知道的 PIN。如果没有人知道，Meta 的两步验证指南介绍了在 WhatsApp Manager 中重置的方法：打开该电话号码的设置，选择两步验证，然后点击 Change PIN。设置一个已知的新 PIN，比反复猜测更快，因为猜测最终会触发 133008，等待时间也会更长。 ### PIN 会在哪些地方用到？ 在为 Cloud API 注册号码时，以及围绕它的一些账户操作中。 Meta 的两步验证指南指出，注册电话号码时，该设置要求提供 6 位数字的 PIN。启用两步验证后，注册请求也会把 PIN 作为必填字段。Meta 的电话号码指南还补充说，更改 PIN 或从平台删除号码时同样需要 PIN。 由于很少用到，它很容易被遗忘。请将它与企业的其他账户凭据一起保存，而不是只留在最初设置号码的那个人手中。 - 在循环中立即重试 `register` 请求。快速的 PIN 尝试正是这个代码所报告的情况。 - 在重试之间不断更换 PIN 来猜测。猜测次数过多会让您从 133009 升级为 133008。 - 忽略 details 值。Meta 明确指出，再次尝试之前应先检查它。 **错误 133009 是否表示我的 PIN 错了？** 不一定。它表示尝试来得太快。PIN 不正确时，报告的是 133005。 **遇到 133009 后应该等待多久？** Meta 没有公布固定的时间。再次尝试之前，请先查看响应中的 details 值。 **可以通过 API 停用两步验证吗？** 不可以。Meta 的两步验证指南指出，没有可用于停用它的端点。您可以改为设置一个新的 PIN。 **忘记 PIN 后如何重置？** 在 WhatsApp Manager 中，打开该电话号码的设置，选择两步验证，然后点击 Change PIN。 --- ## WhatsApp 错误 133015：号码刚被删除，删除尚未完成 https://easycoexistence.com/zh-hans/docs/whatsapp-error-133015 错误 133015 表示正在注册的电话号码刚被删除，而且删除操作尚未完成。Meta 的说明是：“您尝试注册的电话号码刚被删除，删除尚未完成。”官方文档给出的处理方式是：等待 5 分钟，再重试注册请求。 ### WhatsApp 错误 133015 是什么意思？ 这表示同一个号码仍在删除过程中时，收到了一个注册请求。 Meta 的参考文档给出了完整的详情文本：“您尝试注册的电话号码刚被删除，删除尚未完成。”处理方式同样明确：等待 5 分钟后再重试请求。 最常见的情况是迁移号码。有人在一个 WhatsApp Business 账户中删除号码后，立刻在另一个账户中注册；或者先删除再重新添加，想从头开始。第二步到达 Meta 时，第一步还没有在后台完成。 ### 如何删除商业电话号码？ 只能在 WhatsApp Manager 中删除，并且只能由 Business Portfolio 管理员操作。 Meta 的电话号码指南指出，商业电话号码无法通过 API 删除。删除操作需在 WhatsApp Manager 中进行；状态为 Connected 的号码需要输入两步验证 PIN 才能删除；过去 30 天内发送过付费消息的号码，要在最后一条付费消息的 30 天后才能删除。 删除与取消注册不同。Meta 的注册指南说明，取消注册只会让号码无法再用于 Cloud API，不会删除号码或其消息记录。错误 133015 针对的是删除。 ### 迁移号码时如何避免错误 133015？ 把等待时间写进操作流程，而不是等遇到错误再处理。 删除号码后，至少暂停 5 分钟再调用 register。如果调用仍返回 133015，请再等待，不要立即重试。 需要耐心的原因是注册次数限制。Meta 允许每个号码在 72 小时滚动窗口内向 register 端点发出 10 次请求，超出后 API 会返回 133016，并在接下来的 72 小时内阻止注册。如果重试循环每隔几秒就针对 133015 发出一次请求，可能在删除完成之前就用完这 10 次机会。 - 每隔几秒就重试一次 register 调用。每次调用都计入 72 小时内 10 次的限制。 - 把删除与取消注册混为一谈。取消注册不会删除号码，而这个代码针对的是删除。 - 试图通过 API 删除号码。Meta 只支持在 WhatsApp Manager 中删除。 **遇到错误 133015 后应该等多久？** Meta 要求等待 5 分钟，再重试注册请求。 **可以通过 API 删除商业电话号码吗？** 不可以。Meta 的电话号码指南说明，只能在 WhatsApp Manager 中删除。 **为什么我完全无法删除号码？** Meta 不允许删除过去 30 天内发送过付费消息的号码。您可以在最后一条付费消息的 30 天后删除。 **重试过于频繁会怎样？** 72 小时内发出 10 次 register 请求后，API 会返回 133016，并在 72 小时内阻止注册。 --- ## WhatsApp 错误 135000：请求参数出现未知错误 https://easycoexistence.com/zh-hans/docs/whatsapp-error-135000 错误 135000 表示消息因请求参数出现未知错误而发送失败。Meta 的描述是“消息因您的请求参数出现未知错误而发送失败”。Meta 建议对照端点参考文档检查语法是否正确，若该错误持续出现，请联系客户支持。 ### WhatsApp 错误 135000 是什么意思？ 这表示平台无法发送消息，也无法说明确切原因，但仍把问题归到您的请求参数上。 Meta 参考文档给 135000 的详细信息文本是“消息因您的请求参数出现未知错误而发送失败。”补救办法是查看端点的参考文档，确认您调用时的语法是否正确，若持续收到该错误代码，请联系客户支持。 这一点与 131000 不同：Meta 将 131000 描述为未指明参数的未知错误，其补救办法首先是重试。 ### 如何找出有问题的参数？ 把您发送的完整请求体与端点参考文档逐字段比对。 请连同错误一起记录完整的负载，因为引发错误的值往往因消息而异：格式异常的电话号码、本应是文本却为空的字符串，或字段位置错误的嵌套对象。然后查看 error_data 中的 details 值，Meta 称其为该错误最可能的原因。 如果某个以 135000 失败的负载在修改后成功，请保留两个版本。差异就是答案，它也告诉您下次发送前应验证什么。 ### 什么时候应该就错误 135000 联系 Meta 支持？ 当请求与参考文档一致，而该错误代码持续出现时。 Meta 将联系支持列为持续出现 135000 时的下一步。请附上错误响应中的 fbtrace_id（Meta 称它可能有助于调试该错误），以及时间戳、端点和已去除凭证的请求体。 提交工单前，请确认同一请求是否稳定失败。如果请求失败一次，一分钟后原样重发却成功，问题更可能出在平台而非参数，此时查看 Meta 的 WhatsApp Business Platform 状态页能更快确认。 - 反复重试完全相同的请求。Meta 把问题归到参数上，因此相同的负载往往会以同样的方式失败。 - 只记录错误。没有请求体，就无法找到出错的参数。 - 联系支持时不附上 fbtrace_id。Meta 指明它是有助于调试该错误的 ID。 **错误 135000 与 131000 相同吗？** 不相同。131000 是未给出原因的未知错误。135000 是 Meta 归因于您的请求参数的未知错误。 **错误 135000 与错误 100 相同吗？** 不相同。错误 100 指出参数不受支持或拼写错误。135000 表示参数导致了 Meta 无法识别的错误。 **遇到 135000 后应该重试吗？** 不要原样重试。请先对照端点参考文档检查请求。 **应该向 Meta 支持提供什么？** 响应中的 fbtrace_id、端点、时间，以及去除凭证的请求体。 --- ## EasyCoexistence 与 Z-API 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-z-api Z-API 是一款巴西的 WhatsApp API，按实例销售，通过扫描二维码连接号码，方式与 WhatsApp Web 关联设备相同。EasyCoexistence 通过 Coexistence 将号码连接到 Meta 官方 Cloud API，因此 WhatsApp Business 应用可继续使用，连接方式也不违反 WhatsApp 的条款。 ### 两者如何接入 WhatsApp 本页其余内容都源于这一差异，因此先说明这一点。 - Z-API:: 其文档表示，与 WhatsApp Web 一样，连接时需要扫描二维码或输入电话号码。其官网将官方 Cloud API 描述为另一条路径，并将自己定位为它的市场替代方案。 - EasyCoexistence:: 使用 Meta 的 Cloud API，凭据由 Meta 签发给企业自己的 WhatsApp Business 账户，并通过 Meta 的 Embedded Signup 连接。号码注册为 API 号码，WhatsApp Business 应用仍可在同一部手机上继续使用。 ### 每个号码的费用 两者都按号码收费，因此这是少数单位一致、可直接比较的项目之一。 - Z-API:: Ultimate 套餐每个实例每月 R$ 99,99；Partner 套餐每个实例 R$ 89,99，最少 10 个实例，价格均公布于其官网。试用期为两天。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起（1 至 5 个号码），分六档递减，随号码增加降至每个 US$ 1。前 3 天免费，Meta 的消息费用直接向企业收取，我们从不加价。 ### 如果 WhatsApp 采取行动，号码会怎样 这是按实例定价无法体现的风险。 - Z-API:: 关联设备会话并不是 WhatsApp 商业条款认可的自动化商业消息途径，通过这种方式接入的账户可能被限制或封禁。 - EasyCoexistence:: 这种连接是 Meta 自己的功能，通过 Meta 自己的流程，由独立的 Meta Tech Provider 完成。号码的连接方式没有任何地方可供 WhatsApp 加以处罚。 ### 继续使用手机 无论使用哪种产品，大多数小企业仍会用手机回复客户，这决定了日常工作如何进行。 - Z-API:: 该实例是 WhatsApp Web 意义上的关联会话，因此只在这条关联保持有效时才可用。其官网没有提到 Meta 的 Coexistence 功能。 - EasyCoexistence:: Coexistence 就是整个产品。团队继续使用 WhatsApp Business 应用，API 在同一号码上运行，并且连接受到监控，一旦中断（例如触发 Meta 的 14 天规则），会立即发出警报。 - 将二维码关联的实例与 Cloud API 视为同一产品的不同价位。两者通过不同的路径接入 WhatsApp。 - 在关联设备会话上运行企业的主号码。一旦被封禁，该号码在 WhatsApp 上的存在也随之消失。 - 忘记 Cloud API 会对模板收费。这部分费用由 Meta 向企业收取，不包含在任何一方的订阅费中。 **Z-API 是官方的 WhatsApp API 吗？** 不是。其官网将官方 Cloud API 描述为通过 Meta 的路径，将 Z-API 描述为市场替代方案，其文档也说明实例的连接方式与 WhatsApp Web 相同。 **哪个更便宜？** 是的，我们更便宜。Z-API 公布的价格为每个实例每月 R$ 99,99。我们每个已连接号码每月 US$ 9 起（最多 5 个号码），随号码增加降至 US$ 1。 **使用你们的服务需要模板审批吗？** 仅限在 24 小时窗口之外发起对话的消息，这是 Meta 对所有官方提供商的规定。窗口内的回复使用自由文本。 **我可以把号码从 Z-API 迁移到 EasyCoexistence 吗？** 可以。取消关联会话，继续使用 WhatsApp Business 应用，然后通过 Embedded Signup 连接号码。这需要应用版本 2.24.17 或更高，并且近期有真实的使用记录。 --- ## EasyCoexistence 对比 Blip https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-blip Blip 是一个巴西的对话平台，用于在 WhatsApp 及其他渠道构建聊天机器人并提供客户服务，付费方案需通过销售洽谈报价。EasyCoexistence 则是 WhatsApp 连接本身：通过 Coexistence 接入 Meta 的 Cloud API，按每个已连接号码收取公开的费用，手机上的 WhatsApp Business 应用仍可继续使用。 ### 两款产品各是什么 两者都使用 Meta 的官方 API，但在此之上销售的内容不同。 - Blip:: 一个用于构建机器人的平台，支持自定义流程和自然语言处理，并配有人工客服台，覆盖 WhatsApp、Instagram、Messenger 等渠道。其定价页面称自己是 Meta 官方的 Business Solution Provider。 - EasyCoexistence:: 把企业已在 WhatsApp Business 应用中使用的号码连接到 Meta 的 Cloud API，并持续监控该连接。消息会送达企业现有的任何系统：CRM、n8n、自有代码，或通过 MCP 接入的 AI 代理。 ### 费用是多少 区别在于：不与任何人交谈，能否先看到价格。 - Blip:: 提供最多 2 个坐席的免费方案，每月对话数量有限。付费方案在页面上没有标价，读者会被引导去了解详情，所以具体数字要通过销售洽谈才能得到。 - EasyCoexistence:: 1 至 5 个号码，每个已连接号码每月 US$ 9，随号码增加降至每个 US$ 1，前 3 天免费试用。Meta 的消息费用直接记入企业自己的账户，我们不加价。 ### 手机能否继续使用 对于用手机回复客户的小企业，这通常是第一个问题。 - Blip:: 其定价页面没有提到 Coexistence。请直接向对方确认，号码在连接后能否继续留在 WhatsApp Business 应用中，不要以本页为准。 - EasyCoexistence:: 可以，这是设计使然。Coexistence 让 WhatsApp Business 应用在同一号码上继续使用，近期聊天记录会同步，API 则并行运行。Coexistence 号码的吞吐量为每秒 20 条消息。 ### 机器人逻辑放在哪里 自动化总要在某处运行，这个选择决定您会被什么绑定。 - Blip:: 在 Blip 内部。流程、机器人和客服台都在其平台上构建和运行，而这个平台正是他们销售的产品。 - EasyCoexistence:: 在您原本就在使用的地方。Meta 会把消息 Webhook 直接发送到您自己的系统，对话内容绝不存放在我们这一侧，而且 MCP 服务器让 Claude、ChatGPT、Cursor 或 Codex 都能通过该号码发送消息。 - 把机器人平台的报价与连接费用逐项比较。前者包含构建工具和客服台。 - 以为所有 Meta 合作伙伴都能让 WhatsApp Business 应用继续使用。Coexistence 必须得到支持并启用。 - 忘了 Meta 自己的消息费用。无论选哪个产品，这部分都由 Meta 收取。 **Blip 会公布价格吗？** 只公布免费方案，最多 2 个坐席，对话数量有限。付费方案在其定价页面上没有标价。 **哪一个更便宜？** 我们的价格是公开的，对方的没有公开，所以只有我们的可以核实：每个已连接号码每月 US$ 9，随号码增加降至 US$ 1，不限坐席数量。 **我能用 EasyCoexistence 构建聊天机器人吗？** 可以，在您已经使用的工具中构建。消息会送达您的 Webhook、n8n、Make，或通过 MCP 接入的 AI 代理，逻辑就放在那里。 **EasyCoexistence 是 Meta 的产品吗？** 不是。我们是独立的 Meta Tech Provider，使用 Meta 官方的 Embedded Signup 和 Cloud API。 --- ## EasyCoexistence 与 Digisac 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-digisac Digisac 是一家巴西的多渠道客户服务平台，按定制方案报价，每月 R$ 197 起，通过 Gupshup 和 360dialog 运行官方 WhatsApp API，并借助它们支持 Coexistence。EasyCoexistence 是 Meta Tech Provider，直接连接号码本身，按号码收取公开费用，中间没有任何平台。 ### 价格如何确定 一个是方案报价，另一个是价目表，这决定了之后的一切。 - Digisac:: 没有固定套餐。其页面说明起价为 R$ 197，并随坐席数、渠道数、AI 模块等功能以及集成而变化，由销售团队汇总成一份方案。 - EasyCoexistence:: 每个已连接号码每月 US$ 9（1 至 5 个号码），分六档下降，随号码增加降至每个 US$ 1。无需计算坐席，也无需添加模块。前 3 天免费。 ### 您和 Meta 之间隔着谁 一个号码背后的公司链条，决定了出问题时由谁来修复。 - Digisac:: 该平台通过 Gupshup 和 360dialog 运行 API，它们都是 Meta 合作伙伴。其 Coexistence 文章称，激活需通过 360dialog 等官方提供商完成，Digisac 协助客户办理。 - EasyCoexistence:: 没有中间方。我们是独立的 Meta Tech Provider，企业通过 Meta 自己的 Embedded Signup，在自己的 WhatsApp Business 账户上注册，Meta 的 Webhook 直接发送到企业自己的系统。 ### 团队在什么环境中工作 服务平台和连接服务，对日常工作的改变并不相同。 - Digisac:: 一个集中处理 WhatsApp、Instagram、Telegram、Messenger、电子邮件和网页聊天的共享服务平台，带有对话分配、内部聊天和销售漏斗。团队在平台内工作。 - EasyCoexistence:: 无需登录任何新系统。团队继续使用 WhatsApp Business 应用，自动化、CRM 或 AI 代理则通过 API 在同一号码上运行。 ### 号码多久可以开始使用 小型企业往往仅凭这一点就能做出决定。 - Digisac:: 先有商务方案，再与提供商进行激活。其页面将 CNPJ、Meta Business Manager 和政策合规列为前提条件。 - EasyCoexistence:: 通常通过 Embedded Signup 在 2 分钟内完成：用 Facebook 登录，输入号码，在应用中扫描二维码。号码一连接，监控即开始。 - 把 Digisac 的起价与按号码收费的价格直接比较。其价格会随坐席、渠道和模块增长。 - 以为 Coexistence 是该平台的功能。它是 Meta 的功能，由提供商在 Meta 一侧启用。 - 预算中漏掉 Meta 的费用。无论选择哪种方案，这些费用都由 Meta 收取。 **Digisac 支持 Coexistence 吗？** 支持。其自己的文章称，需通过 360dialog 等官方提供商激活，Digisac 协助完成该流程。 **哪一个更便宜？** 单个号码的话，是我们：每月 US$ 9，而 Digisac 起价为 R$ 197，且会随坐席、渠道和模块增加。我们的价格则随号码增多而下降。 **使用贵司服务会失去共享收件箱吗？** 我们不出售共享收件箱。团队继续使用 WhatsApp Business 应用，其他功能由您选择的工具来运行。 **谁向 Meta 付费？** 由企业直接在自己的 WhatsApp Business 账户上支付。我们从不对 Meta 的费用加价。 --- ## EasyCoexistence 对比 Octadesk https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-octadesk Octadesk 是一家巴西的客户服务平台，集聊天机器人、AI 代理和服务台于一体，套餐每月 R$ 2.499 起，含 3,000 个对话，另需购买入门咨询服务。EasyCoexistence 通过 Coexistence，把您已在 WhatsApp Business 应用中使用的号码连接到 Meta 的 Cloud API，按号码收取公开的固定费用，不限对话数量，也无需设置费。 ### 月费买的是什么 计费单位不同，而且每多一位来信的客户，差距就更大。 - Octadesk:: 按对话数量划分的套餐：One 每月 R$ 2.499，含 3,000 个对话；Flow 为 R$ 4.399，含 5,500 个；Nexus 含 9,000 个，需询价。服务台用户另按人数收费，每个套餐都要求购买入门咨询服务，价格需询价。 - EasyCoexistence:: 每个已连接号码收取一笔费用：1 至 5 个号码每月 US$ 9，随号码增加降至每个 US$ 1。一个有一万次对话的月份，费用与清淡的月份相同。Meta 的消息费用由 Meta 直接向您收取。 ### 两者各是什么 两者都把号码接入官方 API，差别在于在其上构建了什么。 - Octadesk:: 一个服务生态：聊天机器人、AI 代理、带 SLA 和工单记录的服务台，以及 WhatsApp 群发功能，每个套餐含一个官方 WhatsApp API 号码。 - EasyCoexistence:: 连接本身及其监控。号码继续留在 WhatsApp Business 应用中，API 同时在同一号码上运行，消息会送达企业已在使用的工具，包括通过我们的 MCP 服务器接入的 AI 代理。 ### 添加第二个或第十个号码 代理商和拥有多家分店的企业，首先问的就是这个问题。 - Octadesk:: 每个套餐列明含一个官方 WhatsApp API 号码。其定价页面没有公布更多号码的价格。 - EasyCoexistence:: 每个账户的号码数量不限，每个号码按对应档位计价，号码越多单价越低：从第 6 个号码起每个 US$ 7，随号码增加降至 US$ 1。 ### 手机还能不能继续使用 这个问题决定了小团队是否必须改变工作方式。 - Octadesk:: 其定价页面没有提到 Coexistence。请向他们确认，号码接入其 API 后，是否仍可留在 WhatsApp Business 应用中。 - EasyCoexistence:: 可以。我们只做 Coexistence：应用保留原有聊天记录，约六个月的历史记录可同步，API 在同一号码上运行。连接受到监控，一旦中断会立即发出警报。 - 只比较套餐价格，却不计算对话数量。Octadesk 的套餐设有对话上限，而连接费用没有。 - 做预算时漏掉入门咨询服务。Octadesk 每个套餐都要求购买，价格需询价。 - 以为套餐会涵盖 Meta 的模板费用。这些费用由 Meta 直接向企业收取。 **哪一个更便宜？** 是的，对于需要这项连接的企业，我们便宜很多。Octadesk 每月 R$ 2.499 起，另加入门咨询费用；我们每个已连接号码每月收费 US$ 9。 **超过 3,000 个对话会怎样？** 在 Octadesk 的 One 套餐中，您需要升级到更高的套餐。在我们这里没有任何变化：任何价格下都没有对话数量限制。 **Octadesk 支持 Coexistence 吗？** 其定价页面没有说明。请直接向他们询问，不要只依赖本页内容。 **使用 EasyCoexistence 还能用 AI 吗？** 可以。我们的 MCP 服务器让 Claude、ChatGPT、Cursor、Claude Code 和 Codex 可以在该号码上发送消息和模板。 --- ## EasyCoexistence vs Huggy https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-huggy Huggy 是巴西的全渠道客服收件箱，按套餐和已连接用户数定价，WhatsApp 另按数量和类别单独收费。EasyCoexistence 就是 WhatsApp 连接本身：通过 Coexistence，在 WhatsApp Business 应用已在使用的号码上接入 Meta 的 Cloud API，每个已连接号码一个公开费用。 ### 月度账单买的是什么 Huggy 的账单随团队增长，我们的只随号码增长。 - Huggy:: 套餐含 1 位已连接用户，之后每增加 1 位用户另收费：Starter 为 R$ 69,90，Intermediate（月费 R$ 579 起）为 R$ 119,90，Custom（月费 R$ 989 起）为 R$ 189,90。WhatsApp 按数量和类别另行计价，实施服务为可选的 R$ 1.250。 - EasyCoexistence:: 1 至 5 个号码，每个已连接号码每月 US$ 9，随号码增加降至每个 US$ 1，完全不按用户数计费。前 3 天免费，Meta 的消息费用由 Meta 直接向企业收取。 ### 两款产品分别是什么 购买收件箱和购买连接，出于不同的原因。 - Huggy:: 一个集中处理 WhatsApp、Instagram、Messenger、Telegram、电子邮件、SMS 和语音的客服收件箱，带聊天机器人和报告。他们的页面称自己是 Meta 官方合作伙伴，可开通官方 API。 - EasyCoexistence:: WhatsApp Business 应用号码与 Meta Cloud API 之间的连接，持续监控。消息通过 Meta 的 Webhook 或我们的 MCP 服务器，送达企业已在使用的系统。 ### 团队的工作方式是否改变 老板在点头之前会问的问题。 - Huggy:: 客服人员登录 Huggy 收件箱，所有渠道的对话都在其中分配和回复。他们的定价页面没有提到与 WhatsApp Business 应用的 Coexistence。 - EasyCoexistence:: 没有人需要迁移。WhatsApp Business 应用继续在同一号码上使用，聊天记录都在，API 则并行运行，处理企业自动化的各项事务。 ### 对话保存在哪里 这个决定日后很难逆转。 - Huggy:: 保存在他们的平台上，收件箱要向打开对话的客服展示内容，就必须如此。 - EasyCoexistence:: 不在我们这边。我们从不存储对话内容，Meta 可以把收到的消息直接发送到企业自己的 Webhook。 - 给 Huggy 报价时漏掉 WhatsApp 这一项。它与套餐分开，按数量和类别单独收费。 - 只按现在的团队人数计算。收件箱套餐每增加 1 位用户，每月就多一笔费用。 - 为了在一个号码上使用 API 而购买收件箱。这只需要连接。 **哪一个更便宜？** 对于需要连接的企业，我们更便宜。Huggy 的 Intermediate 套餐月费 R$ 579 起，含 1 位用户，还不含 WhatsApp；我们是每个已连接号码每月 US$ 9。 **Huggy 使用官方 API 吗？** 他们的定价页面称自己是 Meta 官方合作伙伴，并开通 Meta 的官方 API。 **Huggy 支持 Coexistence 吗？** 他们的定价页面没有提到。请直接向他们确认，不要只依赖本页。 **EasyCoexistence 提供收件箱吗？** 没有。团队继续使用 WhatsApp Business 应用，这正是 Coexistence 的用途。 --- ## EasyCoexistence 对比 Umbler Talk https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-umbler-talk Umbler Talk 是巴西的 WhatsApp 收件箱、CRM 和聊天机器人，基于官方 API，按坐席计费，每位每月 R$ 99,90 起，至少两位坐席。EasyCoexistence 通过 Coexistence，把 WhatsApp Business 应用中已在使用的号码连接到 Meta 的 Cloud API，按已连接号码计费，账单不会因回复的人数而变化。 ### 月费买的是什么 Umbler Talk 按人数计费，EasyCoexistence 按号码计费。 - Umbler Talk:: 每位坐席每月：Essencial 套餐 R$ 99,90，至少两位坐席；Impulso 套餐 R$ 149,90，Escala 套餐 R$ 219,90，均至少三位坐席。最低账单是 Essencial 套餐两位坐席，每月 R$ 199,80。 - EasyCoexistence:: 1 至 5 个号码，每个号码每月 US$ 9，分六档递减，随号码增加每个降至 US$ 1。不限坐席数，也没有最低消费。前 3 天免费，Meta 直接向您收取消息费用。 ### 两款产品各是什么 两者都基于 Meta 的官方 API，Umbler Talk 在其页面上也明确说明了这一点。 - Umbler Talk:: 共享收件箱，配有可视化 CRM 销售管道、聊天机器人、AI 代理、知识库和网页聊天，高级套餐还提供 WhatsApp 营销活动。团队在其中工作。 - EasyCoexistence:: 连接及其监控。号码保留在 WhatsApp Business 应用中，API 同时在其上运行，消息可通过 MCP 送达您的 CRM、n8n、自己的代码或 AI 代理。 ### 可以接入多少个号码 对代理商和多门店企业来说，号码数量上限比套餐名称更重要。 - Umbler Talk:: Essencial 套餐 2 个 WhatsApp 号码，Impulso 套餐最多 3 个，Escala 套餐称为动态号码上限。号码更多，意味着每位坐席都要升级到更高套餐。 - EasyCoexistence:: 每个账户的号码数量不限，每个号码按所在档位计价，号码越多单价越低。第 20 个号码比第 1 个更便宜。 ### WhatsApp Business 应用是否继续可用 这是小团队首先会问的问题。 - Umbler Talk:: 其套餐页面没有提到 Coexistence。请向他们确认，号码连接后是否仍能在 WhatsApp Business 应用中使用。 - EasyCoexistence:: 可以。我们只连接 Coexistence，因此应用保留所有聊天记录，API 与其同时工作，并监控连接是否中断，例如 Meta 的 14 天规则。 - 把每位坐席的价格当成账单。最少需要两位坐席，更高套餐要求更多。 - 为了号码上限而选套餐，结果每位坐席都按更高价格付费。 - 预算中漏掉 Meta 的模板费用。Meta 直接向企业收取这些费用。 **哪个更便宜？** 是的，我们更便宜。Umbler Talk 的最低账单是两位坐席，每位 R$ 99,90，即每月 R$ 199,80；我们是每个已连接号码 US$ 9，无论谁来回复。 **Umbler Talk 使用官方 WhatsApp API 吗？** 是的。其页面表示 Umbler Talk 使用 WhatsApp 官方 API，并遵守平台规范。 **Umbler Talk 支持 Coexistence 吗？** 其套餐页面没有提到。请直接向他们确认，不要只依赖本页。 **EasyCoexistence 按坐席收费吗？** 不。费用按已连接号码计算，无论有多少人在该号码上回复，或通过 API 使用它。 --- ## EasyCoexistence 与 Whaticket 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-whaticket Whaticket 是面向 WhatsApp 及其他渠道的多客服收件箱，每月 US$ 49 起，最少三名用户和一条 WhatsApp 线路，可通过二维码连接，或通过官方 API 搭配 Coexistence 连接。EasyCoexistence 只提供官方连接：在 WhatsApp Business 应用所用的号码上接入 Meta 的 Cloud API，每个号码 US$ 9。 ### 两者如何连接号码 Whaticket 提供两种接入 WhatsApp 的方式，EasyCoexistence 只提供一种。 - Whaticket:: 可选 WhatsApp 二维码，即像 WhatsApp Web 一样扫码的会话，或搭配 Coexistence 的 WhatsApp API。其官网自己也提醒，使用 WhatsApp Business 群发消息可能触发封禁，并建议使用 API 以降低风险。 - EasyCoexistence:: 只使用 Meta 的 Cloud API，通过 Meta 的 Embedded Signup 配合 Coexistence 连接，因此 WhatsApp Business 应用可继续在同一号码上使用。没有二维码会话选项，也就没有非官方的退路。 ### 每月账单包含什么 两份账单由不同的部分构成。 - Whaticket:: Basic 套餐每月 US$ 49，含三名用户和一条线路，每增加一条线路每月 US$ 20，Pro 套餐为 US$ 109。通过二维码连接发送的群发活动会消耗额度，1,000 条消息 US$ 25 起；API 群发活动不消耗额度。 - EasyCoexistence:: 每个已连接号码每月 US$ 9（1 至 5 个号码），随号码增加降至每个 US$ 1。没有用户费用，也没有额度。Meta 的消息费用直接向企业收取，我们从不加价。前 3 天免费。 ### 两者分别是什么产品 一个是客服工作的地方，另一个是底层的通道。 - Whaticket:: 一个多客服收件箱，集中并自动化各消息渠道，并带有群发活动功能，团队在其平台内回复消息。 - EasyCoexistence:: 连接加 24/7 监控。团队继续使用 WhatsApp Business 应用，消息会送达您自己的 Webhook，AI 智能体则通过我们的 MCP 服务器操作该号码。 ### 第二个、第五个或第十个号码要多少钱 代理商和多门店企业会最先算这笔账。 - Whaticket:: 在套餐之外，每增加一条线路 US$ 20，因此 Basic 套餐下五条线路，三名用户每月共 US$ 129。 - EasyCoexistence:: 五个号码每月 US$ 45，而且每个号码的单价还会继续下降：从第六个起每个 US$ 7，随号码增加降至 US$ 1。 - 在二维码连接上运行企业号码。Whaticket 官网自己就提醒，在该方式下群发消息可能触发封禁。 - 忘记消息额度。通过二维码连接的群发活动，在套餐之外按每千条消息另行计费。 - 按套餐价格估算额外线路。每增加一条线路每月多 US$ 20。 **哪一个更便宜？** 是的，我们更便宜。Whaticket Basic 的一条线路每月 US$ 49，而在我们这里一个已连接号码是 US$ 9。五个号码则是 US$ 129 对 US$ 45。 **Whaticket 支持 Coexistence 吗？** 支持。其价格页将搭配 Coexistence 的 WhatsApp API 列为连接选项，与二维码连接并列。 **二维码连接是官方方式吗？** 不是。它像 WhatsApp Web 一样关联一个会话。Whaticket 官网自己也建议使用 API，以降低被封禁的风险。 **你们有像 Whaticket 那样的收件箱吗？** 没有。团队继续使用 WhatsApp Business 应用，您要自动化的内容则在您自己的工具中运行。 --- ## EasyCoexistence 与 Leadsales 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-leadsales Leadsales 是一款来自墨西哥的对话式 CRM，用于通过 WhatsApp、Facebook 和 Instagram 销售。其 Basic 套餐每月 US$ 97，通过网页会话连接 WhatsApp，而官方 API 要从 Professional 套餐起，每月 US$ 133。EasyCoexistence 通过 Coexistence 把号码连接到 Meta 的 Cloud API，每个号码 US$ 9。 ### 哪个套餐才能通过官方方式连接 WhatsApp 在 Leadsales，连接方式取决于套餐。在 EasyCoexistence，则与套餐无关。 - Leadsales:: Basic 通过 Messenger 和网页会话连接 WhatsApp，而不是 Business API。Professional 每月 US$ 133 或 MX$ 3,239.88，Advanced 每月 US$ 247，这两个套餐使用官方 API。 - EasyCoexistence:: 每个号码都使用 Meta 的 Cloud API，通过 Meta 自己的 Embedded Signup 以 Coexistence 方式连接，因此手机上的 WhatsApp Business 应用仍可正常使用。我们没有更便宜的非官方档位。 ### 每月账单买的是什么 Leadsales 按套餐限制用户数和对话数，EasyCoexistence 两者都不限制。 - Leadsales:: Basic 含 3 位用户和 5,000 个活跃对话，Professional 含 4 位用户和 20,000 个，Advanced 含 5 位用户和 50,000 个，年付最高可享 20% 折扣。 - EasyCoexistence:: 1 至 5 个号码，每个已连接号码每月 US$ 9，随号码增加最低降至每个 US$ 1。不限用户数，不限对话数，前 3 天免费，Meta 的消息费用直接向企业收取。 ### 两款产品各是什么 CRM 和连接解决的是不同的问题。 - Leadsales:: 这是一款销售 CRM，提供销售漏斗、共享工作区、按阶段群发消息，高级套餐还有 AI 代理。潜在客户都在 Leadsales 内部跟进。 - EasyCoexistence:: 我们提供的是连接及其监控。消息通过 Meta 的 Webhook 送达企业已在使用的任何 CRM 或工具，AI 代理则通过我们的 MCP 服务器对号码进行操作。 ### 使用网页会话的号码会怎样 这是较便宜的套餐所带来的风险。 - Leadsales:: Basic 套餐的号码通过网页会话接入 WhatsApp，而不是 Business API，WhatsApp 的商业条款并不认可这种方式用于自动化商业消息。 - EasyCoexistence:: 该连接不会招致任何处罚，因为它是 Meta 自家的 Coexistence 功能，通过 Meta 自家的流程完成，并且全天候受到监控。 - 因为价格选了 Basic 套餐，却以为它使用 API。实际上它通过网页会话连接。 - 只数了用户数，却忘了活跃对话数上限。每个套餐都设有上限。 - 以为套餐包含 Meta 的模板费用。这些费用由 Meta 直接向企业收取。 **哪个更便宜？** 是的，我们更便宜。Leadsales 含官方 API 的最低价套餐是每月 US$ 133，而在我们这里，一个已连接号码是 US$ 9。 **Leadsales 使用官方 WhatsApp API 吗？** Professional 和 Advanced 套餐使用。Basic 套餐则是通过 Messenger 和网页会话连接 WhatsApp。 **Leadsales 支持 Coexistence 吗？** 其定价页面说明，在某些情况下号码仍可在手机上使用，在另一些情况下则会完全转移到 API。在我们这里，号码始终保留在 WhatsApp Business 应用中。 **我可以保留现有 CRM 并使用 EasyCoexistence 吗？** 可以。Meta 会把消息送到您选定的 Webhook，因此任何支持 Webhook 的 CRM 都能接收这些消息。 --- ## EasyCoexistence 对比 Treble https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-treble Treble 是一个面向拉丁美洲的 WhatsApp Business API 平台，提供自动化流程、营销活动和 AI 客服，通过销售团队售卖，没有公开价格。EasyCoexistence 通过 Coexistence，让企业把已在 WhatsApp Business 应用中使用的号码接入 Meta 的 Cloud API，可自助开通，公开价格为每个已连接号码每月 US$ 9。 ### WhatsApp Business 应用会怎样 两款产品对手机的假设正好相反。 - Treble:: 其主页称 Treble 是基于 WhatsApp Business API 的方案，而不是基于免费的 WhatsApp Business 应用。页面没有提到 Coexistence，因此请直接询问对方，号码能否继续留在应用中。 - EasyCoexistence:: 应用照常保留。Coexistence 让 WhatsApp Business 应用在同一号码上继续使用，并同步约 6 个月的聊天记录，同时 Cloud API 并行运行，用于自动化。 ### 费用是多少 其中一个价格现在就能查到，另一个需要先洽谈。 - Treble:: 没有公开价格。主页不显示价格，价格页面要求输入密码，因此具体数字要向其销售团队询问。 - EasyCoexistence:: 1 至 5 个号码，每个已连接号码每月 US$ 9，分 6 个档位递减，号码越多越便宜，最低每个 US$ 1。Meta 直接向企业收取消息费用，我们不加价。 ### 各自是什么产品 两者都基于 Meta 的官方 API，但销售的是不同的层面。 - Treble:: 一个用于自动化聊天流程、批量营销活动和 AI 客户服务的平台，原生集成 HubSpot 和 Salesforce，并提供用于自定义连接的 API。 - EasyCoexistence:: 连接本身及其全天候监控。Meta 将 Webhook 直接发送到您的系统，对话内容绝不存储在我们这一侧，MCP 服务器还能让 AI 代理通过该号码发送消息。 ### 号码多久能上线 对小企业来说，这往往是决定性的问题。 - Treble:: 需要经过销售流程，因为套餐和价格要在开通前与其团队商定。 - EasyCoexistence:: 通常在 2 分钟内，通过 Meta 的 Embedded Signup 完成：用 Facebook 登录，输入号码，在应用中扫描二维码。要求应用版本为 2.24.17 或更高，并且近期有真实使用记录。 - 没有确认是否支持 Coexistence，就把使用频繁的应用号码迁到仅限 API 的方案。手机将不再是团队回复消息的地方。 - 把营销平台的报价与连接费用直接比较。前者包含流程和营销活动。 - 漏算 Meta 的消息模板费用。这些费用由 Meta 收取，而不是由任何一家服务商收取。 **Treble 公开价格吗？** 不公开。其主页没有标价，价格页面也需要密码才能访问。 **哪一个更便宜？** 我们的价格是公开的，对方的不是，所以只有我们的可以核实：每个已连接号码每月 US$ 9，随号码增加降至 US$ 1。 **Treble 支持 Coexistence 吗？** 其主页没有提到，并将 Treble 描述为基于 API，而不是基于 WhatsApp Business 应用。请直接询问对方。 **我可以用 EasyCoexistence 做营销活动吗？** 可以，通过 Cloud API 使用已获批准的消息模板，从您自己的系统或工具发送。Meta 会直接向您收取模板费用。 --- ## EasyCoexistence 与 Botmaker 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-botmaker Botmaker 是面向拉丁美洲的聊天机器人和客户服务平台，基于 WhatsApp Business Platform，每月 US$ 149 起，含 3,000 次对话，另收一次性 US$ 99 的 WhatsApp 账户开通费。它支持 Coexistence。EasyCoexistence 只提供 Coexistence 连接，每个已连接号码每月 US$ 9，没有对话套餐。 ### 每月账单买的是什么 Botmaker 卖的是对话。EasyCoexistence 卖的是连接。 - Botmaker:: Standard 方案 US$ 149，含 3,000 次对话；Scale 方案 US$ 249，含 5,000 次；Pro 方案 US$ 499，含 10,000 次。超出部分每次对话 US$ 0.07 至 US$ 0.05，开通 WhatsApp 账户另收 US$ 99。推送消息需支付 WhatsApp 费用外加 20% 的服务费。 - EasyCoexistence:: 1 至 5 个号码，每个已连接号码每月 US$ 9，号码越多，每个最低降至 US$ 1。没有套餐，没有超额费用，开通无需付费。Meta 直接向企业收取其费用，我们从不加价。 ### 两者的 Coexistence 如何运作 两者都让 WhatsApp Business 应用继续在该号码上使用。其余的设置则不同。 - Botmaker:: 他们的帮助中心说明，Coexistence 仅适用于新线路或新配置；当有人从手机回复时，机器人会暂停；平台也不支持群聊。 - EasyCoexistence:: Coexistence 就是我们的产品：通过 Meta 的 Embedded Signup 自助完成，约需 2 分钟，之后全天候 24/7 监控，因此像 Meta 的 14 天规则导致的断线，会在发生的当下就被标记。 ### 两种产品各是什么 机器人平台和连接是两种不同的购买。 - Botmaker:: 这是在 WhatsApp 上构建机器人并提供客服坐席服务的平台，依方案包含 10 至 50 个坐席。流程都保存在 Botmaker 内部。 - EasyCoexistence:: 这是连接本身。Meta 的 Webhook 会把事件送到您自己的系统，对话内容从不存储在我们这边，MCP 服务器则让 Claude、ChatGPT、Cursor、Claude Code 或 Codex 可以操作该号码。 ### 业务增长对账单的影响 业务越繁忙，这两种模式的走向正好相反。 - Botmaker:: 对话越多，就要按次支付超额费用，或升级到下一个方案，所以忙的月份比淡的月份花费更多。 - EasyCoexistence:: 消息量不计入价格。只有增加号码才会改变账单，而且号码越多，每个号码的单价越低。 - 只比较方案价格，却忘了 US$ 99 的账户开通费和推送消息 20% 的服务费。 - 按今天的对话量来选方案。超出套餐的部分按每次对话收取超额费用。 - 以为手机回复后机器人还会继续运行。在 Botmaker 上，手机回复时机器人会暂停。 **Botmaker 支持 Coexistence 吗？** 支持。他们的帮助中心有相关说明，适用于新线路或新配置。 **哪一个更便宜？** 是我们更便宜。Botmaker 每月 US$ 149 起，另加 US$ 99 开通账户；在我们这里，一个已连接号码每月 US$ 9，开通无需付费。 **你们会在 Meta 的费用上加收费用吗？** 不会。Meta 向企业自己的账户收取消息费用，我们从不加价。 **我可以用 EasyCoexistence 构建机器人吗？** 可以，可使用 n8n、Make、您自己的代码，或通过 MCP 使用 AI 代理。消息会通过 Meta 的 Webhook 送达您的系统。 --- ## EasyCoexistence 与 Gallabox 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-gallabox Gallabox 与 EasyCoexistence 解决的是不同的问题。Gallabox 是基于官方 WhatsApp Business API 的团队收件箱和自动化套件，按套餐销售，用户数固定。EasyCoexistence 是连接本身：让 Meta 的 Cloud API 与 WhatsApp Business 应用共用同一个号码，按号码计费，没有收件箱，也没有席位。 ### 每月账单买的是什么 两者的计费单位不同，而计费单位决定了账单如何增长。 - Gallabox:: 按月计费的套餐，团队规模固定。Basic 标价每月 ₹ 2,999，按季度结算，含 3 个用户，其页面称之为硬上限，更大的团队需要升级到 Essential 或 Advanced。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，随号码增加降至 US$ 1。没有用户数，也没有联系人数，因此增加员工或服务更多客户，发票上的金额都不会改变。 ### Coexistence 如何开通 两者都使用 Meta 的 Coexistence 功能，因此 WhatsApp Business 应用在手机上仍可正常使用。但开通的途径不同。 - Gallabox:: 其文档说明 Coexistence 默认未启用，开始之前必须联系 Gallabox 支持团队，先激活工作区。 - EasyCoexistence:: Coexistence 就是我们的产品。企业主自助完成 Meta 的 Embedded Signup 约需 2 分钟，前提是应用版本为 2.24.17 或更高，且该号码没有绑定到其他提供商。 ### 对话保存在哪里 对于自建界面或管理客户号码的人来说，这是最重要的区别。 - Gallabox:: 保存在其平台内。共享收件箱、聊天机器人构建器和群发工具需要把消息存储在其一侧，才能向客服人员显示。 - EasyCoexistence:: 我们不保存。Meta 会把 Webhook 直接发送到您指定的端点，对话从不存储在我们这一侧。数据会落在您的 CRM、您的应用或您的 AI 代理中。 ### 该选哪一个 如果您要买的是带聊天机器人和营销活动的团队收件箱，Gallabox 就是这类产品，这与购买一个连接是不同的采购。 如果您要买的是号码本身，即官方连接并保持在线，EasyCoexistence 范围更窄，价格也更低。它适合把客户号码接入自家系统的代理机构、已经有界面的开发者，或者希望实现自动化但不想让团队离开手机的企业主。连接会受到监控，包括 Meta 的 14 天规则，消息费用由 Meta 向您自己的账户收取，我们不加价。 - 直接比较套餐价格。一个包含收件箱和 AI 额度，另一个只是连接本身。 - 在提供商启用之前就开始 Coexistence 开通流程，然后对同一个号码反复重试。 - 为将由您自己的软件处理消息的号码购买有席位上限的收件箱。 **EasyCoexistence 比 Gallabox 便宜吗？** 就连接而言，是的。Gallabox Basic 每月 ₹ 2,999，按季度结算，含 3 个用户。EasyCoexistence 每个已连接号码每月 US$ 9，没有用户数限制，因此一个号码无论团队多大都是 US$ 9。 **Gallabox 支持 Coexistence 吗？** 支持。其文档对此有说明，并表示设置之前必须由支持团队在您的工作区上启用。 **EasyCoexistence 有像 Gallabox 那样的收件箱吗？** 没有。您的团队继续使用 WhatsApp Business 应用，软件则通过 Meta 发送到您自己系统的 Webhook 接收同样的消息。 **谁来支付 Meta 的消息费用？** 使用 EasyCoexistence 时由您支付，直接付给 Meta，记在您自己的 WhatsApp Business 账户上，我们不加任何费用。 --- ## EasyCoexistence 对比 TimelinesAI https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-timelinesai TimelinesAI 是与 CRM 同步的 WhatsApp 共享收件箱，按席位计费，可通过二维码、官方 WhatsApp Business API 或 Coexistence 连接号码。EasyCoexistence 只通过 Meta 的 Cloud API 并配合 Coexistence 连接号码，按号码计费，并把每条消息发送到您自己的系统，而不是收件箱。 ### 两者如何连接号码 连接方式决定号码面临的风险，所以先看这一点。 - TimelinesAI:: 每个套餐都提供三种方式：二维码链接（把号码作为关联设备接入）、官方 WhatsApp Business API，或 Coexistence（让 WhatsApp Business 应用与 API 同时运行）。 - EasyCoexistence:: 只有一种方式：通过 Meta 自己的 Embedded Signup，使用 Meta 的 Cloud API 并配合 Coexistence。我们没有二维码会话选项，因此经我们连接的号码都不依赖关联设备链路保持在线。 ### 每月账单付的是什么 按席位和按号码计费，费用增长的原因不同。 - TimelinesAI:: Starter 每个席位每月 $35，按年付款为 $28，Pro 每个席位 $49。他们的定价页说明，每位连接 WhatsApp 账户的用户都需要一个席位。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起，最多 5 个号码，随号码增加降至 US$ 1。我们完全不计人数，Meta 的消息费用由 Meta 直接向您收取。 ### 对话最终存放在哪里 收件箱和连接把数据放在不同的地方。 - TimelinesAI:: 存放在他们的共享收件箱，再同步到您选择的 CRM。收件箱就是产品本身，因此消息会经过并显示在他们的平台上。 - EasyCoexistence:: 直接送到您的端点。Meta 把 Webhook 发送到您指定的 URL，我们不会存储任何对话，客户数据因此始终留在您可控的系统内。 ### 该选哪一个 如果销售团队想在 CRM 中使用共享收件箱，那么要找的是收件箱，TimelinesAI 正是这样的产品。 如果企业想以官方方式连接号码，路径中没有二维码会话，也没有中间方存储数据，那么要找的是连接。EasyCoexistence 就是这样的连接，并提供读取 Meta 自身断开原因的连接状态监控、面向 AI 助手的 MCP 服务器，以及不论团队规模、按号码收取的固定费用。 - 因为二维码更快，就用它连接商业号码。关联设备会话不属于 Meta 的 Business Platform。 - 为由软件而非人工应答的号码计算席位。 - 在同一账户中混用二维码连接和 API 连接的号码，却不记录哪个是哪个。 **EasyCoexistence 比 TimelinesAI 便宜吗？** 就已连接号码而言，是的。TimelinesAI Starter 每个席位每月 $35。EasyCoexistence 每个已连接号码每月 US$ 9，而且不论多少人通过 WhatsApp Business 应用应答，都不会增加费用。 **TimelinesAI 支持 Coexistence 吗？** 支持。他们的定价页在每个套餐中都列出了 Coexistence、二维码和官方 API。 **我可以用 EasyCoexistence 通过二维码连接号码吗？** 不可以。每个号码都通过 Meta 的 Cloud API 并配合 Coexistence 连接，绝不作为关联设备。 **我还能在手机上使用 WhatsApp 吗？** 可以。Coexistence 让 WhatsApp Business 应用在同一号码上继续工作，API 则同时在旁运行。 --- ## EasyCoexistence 与 Periskope 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-periskope Periskope 通过在手机的“关联设备”界面扫描二维码来连接 WhatsApp 号码，其文档明确说明 WhatsApp API 号码无法关联。EasyCoexistence 走的是相反的路线：号码通过 Coexistence 注册到 Meta 的 Cloud API，因此 WhatsApp Business 应用可继续使用，连接本身也是官方连接。 ### 两者如何连接 WhatsApp 本页其余的差异，都源于连接方式的不同。 - Periskope:: 您在手机上打开 WhatsApp 设置，选择“关联设备”，然后扫描 Periskope 显示的二维码。号码以关联设备的身份接入，其官网主页也宣传这种方式无需 Business API。 - EasyCoexistence:: Meta 的 Embedded Signup 会使用 Meta 发给您自己 WhatsApp Business 账户的凭据，把号码注册到 Cloud API。Coexistence 让手机上的应用继续使用同一个号码。 ### 每月费用 两家都公开了价格，但计费的对象不同。 - Periskope:: Starter 标价为每位用户每月 $25，Pro 为 $35，包含第一部手机，之后每增加一部手机，都按套餐价格另算一份许可证。Enterprise 至少需要 50 位用户或手机。 - EasyCoexistence:: 每个已连接号码每月 US$ 9（1 至 5 个号码），分六档递减，随号码增加降至 US$ 1。没有用户许可证，Meta 的消息费用直接计入您的账户，我们不加价。 ### 连接面临的风险 WhatsApp 对关联设备会话和 API 注册的对待方式不同。 - Periskope:: 通过关联设备接入，运行在 Meta 的 Business Platform 之外。WhatsApp 的商业条款对自动化和第三方使用有约束，以这种方式接入的号码在 Meta 眼中没有 API 层面的地位。 - EasyCoexistence:: 每次调用都发往 Meta 的 Cloud API。连接中断时，我们会读取 Meta 给出的断开原因并向您发出警报，其中包括适用于 Coexistence 号码的 14 天应用活动规则。 ### 该选哪一个 关键在于这个号码有多重要，以及它必须在哪里运行。Periskope 的模式围绕把现有号码关联为设备而建，包括群组，而且完全不接受 API 号码。 如果号码是客户所依赖的，或是代理机构为客户负责的号码，官方路线才能始终遵守 Meta 的规则。EasyCoexistence 以每个号码固定费用提供这条路线，让 WhatsApp Business 应用继续使用，并把消息送达您自己的系统。 - 以为付费工具就代表 Meta 认可其接入方式。真正的认可来自 Meta 签发 API 凭据。 - 先把商业号码关联为设备，之后想转到 API 提供商时却没有先取消关联。 - 大部分消息将由自动化而非人工处理，却仍按用户数计费。 **EasyCoexistence 比 Periskope 便宜吗？** 是的。Periskope Starter 每位用户每月 $25，每多一部手机再加 $25。EasyCoexistence 每个已连接号码每月 US$ 9，不按用户收费。 **Periskope 使用官方的 WhatsApp API 吗？** 不是。其文档通过“关联设备”扫描二维码来连接号码，并说明 WhatsApp API 号码无法关联。 **我可以通过 EasyCoexistence 使用群组吗？** 不可以。群聊不在 Meta 的 Cloud API 范围内，这条规则适用于所有官方提供商。 **我的应用还能继续使用吗？** 可以。Coexistence 让 WhatsApp Business 应用继续在手机上使用，同时 Cloud API 在同一个号码上运行。 --- ## EasyCoexistence 与 Wassenger 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-wassenger Wassenger 是团队收件箱和 WhatsApp API 平台，提供两种连接方式：二维码会话，以及 Meta 的 Cloud API（API 一侧支持 Coexistence）。EasyCoexistence 只提供支持 Coexistence 的 Cloud API，没有收件箱，按每个已连接号码每月 US$ 9 起计费，而不是按固定坐席数的套餐收费。 ### 两者如何连接号码 Wassenger 自己的帮助中心对比了它的两种连接方式，从这里入手最清楚。 - Wassenger:: 二维码连接是通过一个工作进程服务建立的会话式连接，需要手机保持在线，并受 WhatsApp 反垃圾检测的约束；Cloud API 连接则由 Meta 验证身份。Coexistence 在 API 一侧提供。 - EasyCoexistence:: 只有 Meta 的 Cloud API，通过 Meta 的 Embedded Signup 配合 Coexistence 完成。产品中没有会话工作进程，也没有二维码连接，因此不会选错。 ### 每月账单付的是什么 坐席套餐和按号码收费，随不同的因素增长。 - Wassenger:: Professional 每月 €39.90，含 1 个号码和 3 个坐席；Business 为 €69.90，含 6 个坐席；Enterprise 为 €99.90，含 9 个坐席。Meta 设定的模板费用另按成本计收。 - EasyCoexistence:: 每个已连接号码每月 US$ 9，随号码增加逐步降至 US$ 1，不按坐席数计费。Meta 直接向您自己的 WhatsApp Business 账户收取消息费用，绝不经过我们。 ### 对话最终存放在哪里 收件箱会保存它所显示的内容，而连接只转发它收到的内容。 - Wassenger:: 存放在他们的共享团队收件箱中，坐席在其中被分配聊天、运行营销活动并使用 AI 助手。消息保存在他们的平台上，坐席才能处理。 - EasyCoexistence:: 存放在您自己的系统中。Meta 将 Webhook 直接发送到您设置的端点，对话绝不会存储在我们这边，团队仍可继续在 WhatsApp Business 应用中回复。 ### 该选哪一个 如果团队希望坐席登录共享收件箱工作，那您要买的是收件箱，而这正是 Wassenger 套餐的设计重点。 如果您只想让号码使用官方 API，别无他求，比如代理商为客户连接号码、开发者为现有应用提供数据，或者企业主想在不增加新工具的情况下加入自动化，那么 EasyCoexistence 是更精简的产品：只有一种连接类型，每个号码收取固定费用，在 Coexistence 连接失效前发出警告的监控，以及面向 Claude、ChatGPT 和 Cursor 的 MCP 服务器。 - 先用二维码连接做测试，运行正常后却把业务号码一直留在上面。 - 比较 €39.90 的套餐和按号码收费时，没有把套餐内含的坐席和收件箱算进去。 - 在不同连接方式之间迁移号码，却没有确认聊天记录是否会随之迁移。 **EasyCoexistence 比 Wassenger 便宜吗？** 就连接而言，是的。Wassenger Professional 每月 €39.90，含 1 个号码。EasyCoexistence 每个已连接号码每月 US$ 9，5 个号码总共 US$ 45。 **Wassenger 支持 Coexistence 吗？** 支持。Wassenger 发布了 Coexistence 页面和帮助文章，说明如何在同一号码上同时使用 WhatsApp Business 应用和它的 API 平台。 **Wassenger 的二维码连接是官方的吗？** Wassenger 将其描述为基于会话，并受 WhatsApp 反垃圾检测的约束。它的 Cloud API 连接才是由 Meta 验证身份的那一种。 **使用 EasyCoexistence 需要服务器吗？** 您需要一个接收 Webhook 的端点，或者通过 MCP 服务器连接的 AI 助手。连接本身的托管已包含在内。 --- ## EasyCoexistence 对比 WANotifier https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-wanotifier WANotifier 是基于官方 API 的 WhatsApp 营销和通知平台，按套餐和联系人档位计费，并设有每月消息上限。EasyCoexistence 本身就是官方连接，并支持 Coexistence，按已连接号码计费，没有联系人或消息上限。两者都按原价转收 Meta 的消息费用，不加价，所以差别在于订阅费用买到的是什么。 ### 每月账单买到的是什么 WANotifier 按受众规模定价。EasyCoexistence 按号码定价。 - WANotifier:: 在少于 1,000 个联系人的档位下，Essentials 每月 $69，Advanced 每月 $119，Premium 每月 $199（按月付费），每月发送上限分别为 4,000、8,000 和 12,000 条消息。联系人名单更大，就会进入更高的档位。 - EasyCoexistence:: 每个已连接号码每月 US$ 9 起（最多 5 个号码），随号码增加降至 US$ 1。拥有 5 万个联系人的名单，费用与拥有 50 个联系人的名单相同。 ### Coexistence 如何融入其中 两者都通过 Meta 的官方 API 连接，也都提供 Coexistence，因此 WhatsApp Business 应用仍可留在手机上。 - WANotifier:: 每个套餐都将 Coexistence 列为功能之一，另有营销活动、聊天机器人、滴灌式序列和团队共享收件箱。 - EasyCoexistence:: Coexistence 就是整个产品：自助式 Embedded Signup 约 2 分钟完成，持续的连接状态监控，以及根据 Meta 自身的断连原因发出的警报，包括 14 天应用活动规则。 ### 消息去向何处 营销活动工具替您处理消息，连接则把消息交给您。 - WANotifier:: 进入其控制台、收件箱和自动化构建器；Advanced 和 Premium 套餐提供 REST API 和 Webhook，用于集成。 - EasyCoexistence:: 直接发送到每个号码对应的端点，因为 Meta 会把 Webhook 路由到您指定的 URL。我们这边不存储任何内容，MCP 服务器还能让 Claude、ChatGPT 或 Cursor 操作该号码。 ### 该如何选择 想在一个控制台里使用群发、滴灌式序列和聊天机器人构建器的人，买的是营销活动工具，与连接是不同的产品。 已经有软件或正在开发软件的人，需要的是号码被正式连接并保持连接。这就是 EasyCoexistence，费用不随联系人或发送量变化，而 Meta 自己的消息费用在两种情况下都直接记入您的账户。 - 只按价格选择套餐，却没有核对该套餐附带的每月消息上限。 - 让联系人名单在月中越过档位界限，却没有为升档预留预算。 - 以为加价 0% 就意味着没有平台费用。订阅费和 Meta 的费用都要支付。 **EasyCoexistence 比 WANotifier 便宜吗？** 是的，就连接而言如此。WANotifier Essentials 在最小联系人档位下每月 $69。EasyCoexistence 每个已连接号码每月 US$ 9，没有联系人或消息上限。 **WANotifier 支持 Coexistence 吗？** 支持。其定价页面在每个套餐中都列出了 WhatsApp Coexistence。 **两者都按原价转收 Meta 的费用，不加价吗？** 是的。WANotifier 声明加价 0%，而使用 EasyCoexistence 时，Meta 直接向您自己的账户收费。 **我可以用 EasyCoexistence 发送营销活动吗？** 您可以从自己的系统或 AI 助手，通过 Cloud API 发送已获批准的模板。没有营销活动构建器。 --- ## EasyCoexistence 对比 Eazybe https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-eazybe Eazybe 是面向销售团队的 CRM 层，以 Chrome 扩展的形式安装在 WhatsApp Web 上，入门版 Starter 按用户计费，更高的套餐则增加 WhatsApp API 号码和 Coexistence。EasyCoexistence 只提供官方连接：Meta 的 Cloud API 加 Coexistence，按号码计费，并将消息直接送达您自己的系统。 ### 两者如何接入 WhatsApp 两款产品所处的位置不同：一个在销售代表的浏览器中，一个在 Meta 的 API 上。 - Eazybe:: 在每位销售代表已打开的 WhatsApp Web 会话之上添加 Chrome 扩展，提供标签、CRM 同步和定时发送。更高的套餐也列有 WhatsApp API 号码和 Coexistence。 - EasyCoexistence:: Meta 的 Cloud API，通过 Meta 的 Embedded Signup 配合 Coexistence 注册。浏览器标签页中不运行任何程序，因此无论是否有人打开 WhatsApp Web，消息都会正常流转。 ### 每月账单包含什么 Eazybe 以访客的本地货币显示价格，且各套餐之间的计费单位不同。 - Eazybe:: Starter 按每用户每月计费。Scaler、Basic AI 和 Pro AI 按每号码每月计费，含 3 或 5 个用户，额外用户另计，AI 回复则按每条回复计费。 - EasyCoexistence:: 每个已连接号码每月 US$ 9，随号码增加降至 US$ 1。没有用户数量限制，没有 AI 额度，Meta 直接向您自己的账户收取消息费用。 ### 对话最终去向何处 CRM 扩展把聊天复制到 CRM。连接则把消息转发到您选择的任何系统。 - Eazybe:: 通过其平台从 WhatsApp Web 同步到其集成的 CRM，例如 HubSpot、Zoho 和 Salesforce。 - EasyCoexistence:: 由 Meta 以 Webhook 的形式送达您指定的端点，绝不存储在我们这一侧。您的 CRM、应用、自动化工具，或通过 MCP 服务器连接的 AI 助手可直接接收。 ### 如何选择 如果销售团队希望在浏览器中每个聊天旁边看到 CRM 字段，那么购买的是 CRM 扩展，Eazybe 的 Starter 套餐正是如此。 如果企业希望每个号码都使用 Meta 的官方 API，且不依赖浏览器会话，则应购买连接服务。EasyCoexistence 以每个号码固定月费提供，持续监控连接状态，在 14 天应用活动规则失效前发出警报，并让团队继续使用他们已在用的 WhatsApp Business 应用。 - 把 WhatsApp Web 上的浏览器扩展当作 API 连接。它依赖标签页保持打开。 - 在没有计算每个号码由多少销售代表共用的情况下，就比较按用户套餐和按号码费用。 - 以为每个套餐都包含官方 API。在 Eazybe 上，它从 Scaler 起才出现。 **EasyCoexistence 比 Eazybe 便宜吗？** 对于由团队共用的号码，是的。Eazybe Starter 按用户收费，API 套餐按号码收费，额外用户另计。EasyCoexistence 无论团队规模，每个已连接号码每月 US$ 9。 **Eazybe 支持 Coexistence 吗？** Eazybe 发布了一个 Coexistence 页面，介绍同一号码上同时使用 WhatsApp Business 应用和官方 API。 **使用 EasyCoexistence 需要打开 WhatsApp Web 吗？** 不需要。Cloud API 运行在 Meta 的服务器上，团队继续在手机上使用 WhatsApp Business 应用。 **可以把消息同步到我的 CRM 吗？** 可以，将 Meta 的 Webhook 指向您的 CRM、n8n 或 Make 等自动化工具，或您自己的代码即可。 --- ## EasyCoexistence 对比 Superchat https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-superchat Superchat 是整合 WhatsApp、Instagram、电邮及其他渠道的统一收件箱，套餐至少签 12 个月合约，其 Coexistence 选项标注为 beta。EasyCoexistence 只做一件事：通过 Coexistence 把 WhatsApp 号码连接到 Meta 的 Cloud API，按每个已连接号码每月计费，消息直接送达您自己的系统。 ### 月费包含什么 Superchat 在套餐内计算账户和号码数量。EasyCoexistence 只计算号码数量。 - Superchat:: Basic 每月 $19、Professional 每月 $29、Advanced 每月 $69（净价），分别含 3、6、12 个账户和 1、2、4 个 WhatsApp 号码。每增加一个号码每月 $49，每增加一个登录 $19，最短合约期 12 个月。 - EasyCoexistence:: 每个已连接号码每月 US$ 9，随号码增加最低降至 US$ 1，无需计算账户或登录数。Meta 的消息费用由其直接向您收取。 ### Coexistence 的提供方式 两者都通过官方 API 连接，也都提供 Coexistence，因此 WhatsApp Business 应用可继续留在手机上。 - Superchat:: 四种连接方式之一，另外三种是新号码、完整迁移和从其他服务商转入。其帮助中心表示，Coexistence 方式目前处于 beta 阶段，功能可能有限制。 - EasyCoexistence:: 唯一的方式，通过 Meta 的 Embedded Signup 自助完成，约需 2 分钟，之后持续监控，在客户察觉之前发现失效的连接。 ### 对话最终去向哪里 收件箱为客服人员存放对话，连接则把对话转发出去。 - Superchat:: 在其统一收件箱内，由模板、标签、AI 代理和评价管理处理平台内的消息。 - EasyCoexistence:: 送达您指定的端点，因为 Meta 直接把 Webhook 路由到该处。我们不会存储任何对话，团队也继续使用 WhatsApp Business 应用。 ### 该选哪一个 想在一个收件箱里回复多个渠道的企业，购买的是多渠道收件箱，与 WhatsApp 连接是两种不同的产品。 想让 WhatsApp 号码接入官方 API 并保持在线，同时把消息送到自己的 CRM、应用或 AI 助手的企业，应选择 EasyCoexistence：每个号码收取固定费用，Coexistence 是产品的核心，而不是 beta 选项。 - 只看月费，却忽略了附带的最短合约期限。 - 需要更多号码时只算套餐价格。额外号码有各自的月费。 - 对已连接到其他 API 服务商的号码启动 Coexistence 接入。 **EasyCoexistence 比 Superchat 便宜吗？** 是的，就 WhatsApp 连接而言如此。Superchat Basic 每月 $19，最短合约期 12 个月。EasyCoexistence 每个已连接号码每月 US$ 9，任何规模的团队都可以通过 WhatsApp Business 应用回复消息。 **Superchat 支持 Coexistence 吗？** 支持，它是其连接选项之一，但其帮助中心将其标注为 beta。 **EasyCoexistence 涵盖 Instagram 或电邮吗？** 不涵盖。它只通过 Meta 的 Cloud API 连接 WhatsApp 号码，不做其他事情。 **谁来支付 Meta 的消息费用？** 由您在自己的 WhatsApp Business 账户上直接向 Meta 支付。EasyCoexistence 绝不加价。 --- ## EasyCoexistence 与 Sinch 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-sinch Sinch 是一个企业通信平台，除 WhatsApp 外还转售 SMS、语音等渠道，并按每位客户的协议，在 Meta 费用之上另收每条消息费。EasyCoexistence 通过 Coexistence 将 WhatsApp Business 应用号码连接到 Meta 的 Cloud API，自助完成，按号码收固定费用，消息费用由 Meta 直接向您计费。 ### 每条消息的成本 区别在于每条消息上是否还叠加了第二笔费用。 - Sinch:: 每条消息有两层费用：Meta 按类别和国家收取的费用，以及 Sinch 为平台接入和每条消息服务收取的费用。后者由您与 Sinch 的协议确定，没有公开价目表。 - EasyCoexistence:: 只有一层。Meta 将费用计入您自己的 WhatsApp Business 账户，我们绝不加价。我们的收费是每个已连接号码每月 US$ 9，随号码增加最低降至 US$ 1，与消息量无关。 ### 各自适用的号码 大多数小型企业已经在 WhatsApp Business 应用上回复客户。真正重要的就是这个号码。 - Sinch:: Sinch Engage Classic 的设置指南要求号码能接收国际短信或来电，并且未连接任何 WhatsApp 账户。其开通文章中没有介绍 Coexistence 的路径。 - EasyCoexistence:: 已在 WhatsApp Business 应用上使用的号码，通过 Coexistence 连接。聊天记录、历史消息和手机上的应用都会保留，Cloud API 在同一号码上运行。 ### 如何开始使用 一条路要经过销售协议，另一条只需一个注册页面。 - Sinch:: Sinch Build Dashboard 上的 Embedded Signup，按其说法，目前仅向直接企业客户开放，价格取决于您的协议。 - EasyCoexistence:: 通过 Meta 的 Embedded Signup 自助开通，约需 2 分钟，前 3 天免费。应用需为 2.24.17 或更高版本，并且近期有真实使用记录。 ### 该如何选择 企业若要在一份合同下按协商条款采购 SMS、语音和 WhatsApp，买的是 CPaaS，这与购买 WhatsApp 连接是两种不同的采购。 如果您的客户已经在给您的 WhatsApp Business 应用发消息，或者您是为客户连接这些号码的代理商，您需要的是 Coexistence、公开的价格，以及不在每条消息上叠加费用。EasyCoexistence 正是为此而建，Meta 会将 Webhook 直接路由到您自己的系统，并提供面向 AI 助手的 MCP 服务器。 - 只按 Meta 的价目表做预算，而忽略了服务商会在每条消息上另收自己的费用。 - 为 API 注册一个全新的号码，却让客户继续给应用上的旧号码发消息。 - 为了腾出号码而删除 WhatsApp Business 应用账户，而 Coexistence 本可以保留它。 **EasyCoexistence 比 Sinch 更便宜吗？** 是的，就我们能控制的部分而言。Sinch 按您的协议在每条消息上另收费用。EasyCoexistence 不收每条消息费，每个已连接号码每月收费 US$ 9。 **Sinch 支持 Coexistence 吗？** 本页查阅的 Sinch 开通文章没有提到这一点。请直接向 Sinch 确认，不要仅依据本页。 **Sinch 会公布其 WhatsApp 费用吗？** 其帮助中心表示 Sinch 的费用取决于您的协议，并未列出公开的每条消息费率。 **我需要与 EasyCoexistence 签合同吗？** 不需要。通过 Meta 的 Embedded Signup 自助注册即可，前 3 天免费。 --- ## EasyCoexistence 与 Vonage 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-vonage Vonage 是面向开发者的通信平台，其 Messages API 可在 SMS、RCS 等渠道之外发送 WhatsApp 消息，并在 Meta 的费用之上对每条消息加收 Vonage 平台费。EasyCoexistence 通过 Coexistence 将 WhatsApp Business 应用的号码连接到 Meta 的 Cloud API，按号码收取固定费用，消息费用由 Meta 直接向您收取。 ### 账单是如何构成的 随着消息量增长，按用量计费与固定费用的表现截然不同。 - Vonage:: Meta 按每条已送达消息收费，另加 Vonage 平台费，起价为每条消息 0.0001 欧元，并按用量和地区调整。通话另收 Vonage 费用，每分钟 $0.004。 - EasyCoexistence:: 每个已连接号码每月 US$ 9，随号码增加降至 US$ 1。Meta 向您自己的 WhatsApp Business Account 收取消息费用，我们不会在每条消息上另外加价。 ### 两者各自面向哪类号码 小型企业日常用来回复客户的号码，通常是 WhatsApp Business 应用的号码。 - Vonage:: 其 WhatsApp 定价页面以及面向合作伙伴的托管 Embedded Signup 指南都没有提到 Coexistence，也就是让应用在 API 号码上继续运行的 Meta 功能。 - EasyCoexistence:: 专为 Coexistence 号码而设。WhatsApp Business 应用保留聊天记录，并继续在手机上使用，同时 Cloud API 在同一号码上运行，吞吐量为 Meta 的 Coexistence 上限，每秒 20 条消息。 ### 您与 Meta 之间隔着什么 两者都是 API 产品，区别在于您调用的是谁的 API。 - Vonage:: Vonage Messages API，一个覆盖 WhatsApp 及其他渠道的统一接口。您的代码调用 Vonage，再由 Vonage 调用 Meta。 - EasyCoexistence:: Meta 公开文档中的 Cloud API，凭据签发给您自己的账户，Webhook 由 Meta 直接发送到您的端点。对话内容绝不会存储在我们这一侧。 ### 该如何选择 如果开发者想用一个 API 同时覆盖 SMS、RCS、电子邮件和 WhatsApp，那么购买的是多渠道 CPaaS，这与 WhatsApp 连接是不同的产品。 如果企业或代理商需要让 WhatsApp Business 应用的号码使用 Meta 自己的 API，既不想按每条消息付费，也不想更换新号码，就需要 Coexistence。EasyCoexistence 提供自助开通，约需 2 分钟，持续监控每个连接，并通过 MCP 服务器让 Claude、ChatGPT 或 Cursor 使用该号码。 - 只按每条消息的平台费来估算成本，却没有加上 Meta 自己的费用。 - 针对某个供应商的消息格式编写代码，而 Meta 的 Cloud API 有完整文档，也更便于迁移。 - 误以为 CPaaS 的开通流程会接受仍在应用上使用的号码。 **EasyCoexistence 比 Vonage 便宜吗？** 只要消息量稍有规模，答案就是肯定的，因为 Vonage 对每条消息加收平台费，而 EasyCoexistence 不加收。无论经过多少条消息，我们的费用都是每个已连接号码每月 US$ 9。 **Vonage 支持 Coexistence 吗？** 其 WhatsApp 定价页面和托管的 Embedded Signup 页面都没有提到。请直接向 Vonage 确认，不要仅凭本页判断。 **我可以保留现有的 WhatsApp 号码吗？** 可以。Coexistence 会连接已在 WhatsApp Business 应用上使用的号码，并保留其聊天记录。 **WhatsApp 消息费用由谁向我收取？** 由 Meta 直接向您自己的 WhatsApp Business Account 收取。EasyCoexistence 绝不会在这些费用上加价。 --- ## EasyCoexistence 与 Qontak 对比 https://easycoexistence.com/zh-hans/compare/easycoexistence-vs-qontak Mekari Qontak 是印度尼西亚的全渠道 CRM 与客户服务套件，基于官方 WhatsApp API，套餐最少 5 个用户起，Coexistence 还需另行订阅。EasyCoexistence 只负责连接：通过 Coexistence 把 WhatsApp Business 应用号码接入 Meta 的 Cloud API，按已连接号码计费，消息发送到您自己的系统。 ### 月费买到的是什么 Qontak 出售的是 CRM 套件，EasyCoexistence 出售的是连接。 - Qontak:: Service Suite 和 Sales Suite 的 Plus 档每月 Rp2.000.000 起，Ultimate 档 Rp3.000.000，Qontak 360 每月 Rp3.500.000 起，所有套餐最少 5 个用户起。 - EasyCoexistence:: 每个已连接号码每月 US$ 9，随号码增加降至 US$ 1。无论团队多大，一个号码在应用中回复，都是 US$ 9。 ### Coexistence 如何设置 两者都通过 Meta 的 Coexistence 流程连接，因此手机上的 WhatsApp Business 应用可继续使用。 - Qontak:: 其指南在集成前的要求中列出：有效的 META Coex 订阅、号码已活跃至少 30 天，以及已完成 Facebook 商业验证。 - EasyCoexistence:: Coexistence 本身就是产品，不另外收费。注册自助完成，约需 2 分钟，要求应用为 2.24.17 或更高版本，近期有真实活动，且号码未绑定其他服务商。 ### 对话最终去哪里 CRM 套件把对话留下来处理，连接则把对话交出去。 - Qontak:: 留在 Qontak 的全渠道收件箱和 CRM 中，与 WhatsApp Business 应用同步镜像，并可在其控制台中使用工单、聊天机器人和群发。 - EasyCoexistence:: 发送到您选择的端点，因为 Meta 直接把 Webhook 路由到那里。对话绝不存放在我们这边，MCP 服务器还可将号码连接到 AI 助手。 ### 该选哪一个 想在一个套件里管理销售管道、工单和多个渠道的公司，买的是 CRM，这与 WhatsApp 连接是不同的采购。 已经有 CRM 的企业，或者要把客户号码接入自家系统的代理机构，需要的是让号码接入官方 API 并保持连接。EasyCoexistence 按每个号码收固定费用，监控每个连接，并在 Meta 的 14 天应用活跃度规则失效前发出警报。 - 连接在普通 WhatsApp 应用中注册的号码。Coexistence 需要 WhatsApp Business 应用。 - 仅为集成而新建一个 Business Portfolio，Qontak 的指南也不建议这样做。 - 为了解决账户问题而重置应用。这不会重置历史记录，还可能断开连接。 **EasyCoexistence 比 Qontak 便宜吗？** 是的，就连接而言。Qontak 套餐每月 Rp2.000.000 起，最少 5 个用户，另加 Coexistence 订阅。EasyCoexistence 每个已连接号码每月 US$ 9，已包含 Coexistence。 **Qontak 支持 Coexistence 吗？** 支持。其帮助中心介绍了该集成，并将有效的 META Coex 订阅列为要求。 **EasyCoexistence 要求号码已使用 30 天吗？** 它要求 WhatsApp Business 应用近期有真实活动，这是 Meta 自己对 Coexistence 的资格检查。 **EasyCoexistence 包含 CRM 吗？** 不包含。消息通过 Meta 发送到您端点的 Webhook，送达您现有的 CRM 或应用。 --- ## 从 Coexistence 号码将 WhatsApp 消息记录到 HubSpot https://easycoexistence.com/zh-hans/integrations/hubspot HubSpot 有一个 Communications 对象，其渠道类型可以设为 WHATS_APP，专门用于记录发生在 HubSpot 之外的消息。把该号码的 Webhook 转发到 n8n 工作流，按电话查找或创建联系人，然后将每条消息 POST 到 /crm/v3/objects/communications。对话会出现在联系人时间线上，而团队仍然在 WhatsApp Business 应用中回复。 ### 一条 WhatsApp 消息如何出现在 HubSpot 联系人上？ 分三步。Meta 把消息发送到您为该号码设置的 Webhook 目标，这里是 n8n 的 Webhook 节点。工作流在 HubSpot 中按发送者的电话号码搜索联系人，没有匹配时就创建一个。然后创建一条包含消息文本的 communication 记录，并将它关联到该联系人。 HubSpot 正是为这种情况设计了 Communications 对象。它表示在 HubSpot 之外发送或接收的 WhatsApp、LinkedIn 或短信消息，并像已记录的通话或邮件一样显示在记录时间线上。必填属性包括渠道类型、设为 CRM 的 hs_communication_logged_from、正文、负责人和时间戳。 这一切都不需要 HubSpot 应用市场中的应用。n8n 的 HTTP Request 节点可以复用您为 HubSpot 节点配置好的 HubSpot 凭据，每条消息只需一次 POST 调用。 ### 在手机上输入的消息也会被记录吗？ 可以，这正是 Coexistence 号码带来的好处。当团队成员在 WhatsApp Business 应用中回复时，Meta 会把这条发出消息的回显发送到同一个 Webhook 目标。同时处理收到的消息和回显的工作流，会把对话的双方都写入时间线，因此销售人员在 HubSpot 中打开联系人时，能看到客户问了什么，以及店铺如何回复。 按 Webhook 字段分支处理。收到的消息出现在 messages 下，手机上的回复出现在 smb_message_echoes 下。把前者记为已接收，后者记为已发送，时间线就会按顺序呈现。 工作流自己通过 Cloud API 发送的回复，它本身就已知晓，所以在发送的那一刻直接记录，无需等待 Webhook。 ### HubSpot 自带的 WhatsApp 收件箱渠道又是怎么回事？ 那是另一种集成。HubSpot 的对话收件箱会把一个 WhatsApp 号码直接连接到 HubSpot 本身，其知识库说明该号码不能同时连接到其他 WhatsApp 集成。它适用于 Marketing Hub 或 Service Hub 的 Professional 和 Enterprise 版本。 通过 EasyCoexistence 连接的号码走的是另一条路：Meta 把 Webhook 发送到您自己拥有的 URL，HubSpot 则通过 API 接收记录。对话由手机或您的工作流回复，HubSpot 是记录系统，把历史保存在联系人、交易或工单名下。 发起调用的私有应用或凭据需要联系人写入权限范围，这与工作流本来就需要的、用于创建联系人的权限范围相同。 ### 工作流应该如何把发送者匹配到联系人？ 按电话号码匹配，并在搜索前先做标准化。Meta 发来的发送者号码只有数字，包含国家代码，没有加号，例如 14155550188。HubSpot 中的联系人是手动输入的，同一个人可能被存成 +1 415 555 0188 或 (415) 555-0188。 可靠的做法是保留一个专用的联系人属性，存放纯数字号码，在工作流创建联系人时填入，并按该属性搜索。直接搜索自由文本的电话字段，对工作流创建的联系人有效，却会漏掉许多人工创建的联系人，从而产生重复记录。 搜索没有结果时，就创建联系人：把 Webhook 负载中的资料名称作为名字，并在两个字段中都填入纯数字号码。之后可以由人工合并或改名，而对话已经关联在上面了。 - 只记录收到的消息。这样时间线上只有问题没有回答，因为在手机上输入的回复会以 smb_message_echoes 事件的形式到达。 - 没有设置 hs_communication_logged_from。通过 API 创建 communication 时，HubSpot 要求它的值为 CRM。 - 按原始电话字段搜索联系人。Meta 的纯数字格式很少与人工输入的内容一致，每次未命中都会产生一个重复联系人。 **我可以在 HubSpot 内直接回复客户吗？** 不能通过 Communications 对象，因为它只是记录。回复需要从 WhatsApp Business 应用发出，或由调用 Cloud API 的工作流发出，两种方式都会记录回联系人。 **工作流需要哪些 HubSpot 权限？** 联系人的读取和写入权限。HubSpot 将 crm.objects.contacts.read 或 crm.objects.contacts.write 列为 Communications API 的权限范围，而创建联系人本来就需要写入权限。 **同一个工作流也可以发送第一条消息吗？** 可以。单独的 n8n 分支可以使用该号码的 phone number id 和访问令牌，通过 Cloud API 发送已获批准的消息模板，然后把它作为发出的 communication 记录到联系人上。 **EasyCoexistence 会在中途存储消息内容吗？** 不会。Meta 直接把 Webhook 发送到您的 n8n URL。EasyCoexistence 从不存储对话内容。 --- ## 将 Coexistence 号码的 WhatsApp 对话发送到 Salesforce https://easycoexistence.com/zh-hans/integrations/salesforce 把号码的 Webhook 转发到 n8n 工作流，用 SOQL 按电话号码在 Salesforce 中查找发送者，没有匹配时创建潜在客户，再把每条消息记录为该记录上的任务或备注。n8n 的 Salesforce 节点可以完成这三个调用。团队继续在 WhatsApp Business 应用中回复，而 Salesforce 保存完整的历史记录。 ### n8n 工作流是什么样的？ 四个节点连成一条线，外加每个 Meta Webhook 都需要的验证分支。 Webhook 节点接收 Meta 为每条消息发送的 POST 请求。Salesforce 节点运行 SOQL 查询，查找电话号码与发送者匹配的潜在客户或联系人。IF 节点根据是否有结果分流：有结果时，工作流带着记录 ID 继续；没有结果时，由一个 Salesforce 节点用负载中的用户资料名称创建潜在客户。最后一个 Salesforce 节点在该记录上创建任务，把消息文本写入描述，并在主题中注明这是一条 WhatsApp 消息。 验证分支用 hub.challenge 的值作为纯文本响应体，回答 Meta 的 GET 请求。没有它，Meta 不会开始投递，工作流的其余部分只会闲置。 ### 消息应记录为任务还是备注？ 大多数团队选任务，因为任务会进入销售人员本来就在看的活动时间线，也可以用于报表。把状态设为已完成，这样它不会显示为待办事项；主题中写明渠道名称，这样筛选 WhatsApp 活动只需一个条件。 n8n 节点的添加备注操作适合另一种情况：记录摘要，而不是每条消息。有些团队让工作流按联系人汇总一天的消息，晚上写成一条备注，这样当客户发来二十条短消息时，时间线仍然清晰易读。 无论选哪种，都要把 WhatsApp 消息 ID 写入记录。Meta 会重试投递，而工作流在写入前先检查是否已有该 ID，就不会重复记录同一条消息。 ### 团队还能用手机回复吗？Salesforce 能看到吗？ 两者都可以。Coexistence 让 WhatsApp Business 应用继续在同一号码上使用，昨天回复客户的人今天照常回复。当他们从应用中回复时，Meta 会把发出消息的回显发送到同一个 Webhook 目标，字段为 smb_message_echoes。 在工作流中为这些回显增加第二条路径，并把它们记录为发出的任务。销售人员打开潜在客户时，就能按顺序看到问题和商家的回答，无需任何人手动复制聊天记录。 工作流自己通过 HTTP Request 节点调用 Cloud API 发送的回复，应在发送时就记录。此时工作流已经掌握了文本和记录 ID。 ### 如何避免重复的潜在客户？ 按规范化后的电话号码匹配，而不是按用户输入的原样字段匹配。Meta 发送的发送者号码只有数字，带国家代码，没有加号。Salesforce 的电话字段则保存创建记录的人输入的内容，可能带空格、括号和连字符。 可靠的做法是新增一个自定义文本字段，只存纯数字号码：工作流创建潜在客户时填写，现有记录用一次回填补齐。之后 SOQL 查询只需对该字段做相等比较，既快又精确。 联系人也要查。已转化的客户是联系人，如果工作流只搜索潜在客户，每个来信的老客户都会生成一条新的潜在客户。 - 只搜索 Lead 对象。老客户是 Contact，每个来信的老客户都会变成重复的潜在客户。 - 把消息记录为未完成的任务。销售人员会为客户的每一条消息收到待办事项，创建时应把状态设为已完成。 - 工作流中漏掉验证用的 GET 分支。Meta 无法确认目标地址，因此不会投递任何消息。 **这需要 Salesforce AppExchange 包吗？** 不需要。n8n 内置的 Salesforce 节点可以处理搜索、潜在客户和任务，它没有覆盖的部分可以用同一凭据通过 HTTP Request 节点完成。 **Make 也能做到同样的事吗？** 可以。Make 的自定义 Webhook 接收消息，Salesforce 模块写入记录。场景的结构与 n8n 工作流逐步对应。 **Salesforce 能向潜在客户发送 WhatsApp 消息模板吗？** 通过工作流可以。让 Salesforce 调用 n8n 的 Webhook，再由 n8n 使用号码的 phone number ID 和访问令牌，通过 Cloud API 发送已批准的消息模板。 **EasyCoexistence 会保存消息副本吗？** 不会。Meta 把每个 Webhook 直接投递到您的 n8n URL，EasyCoexistence 从不存储对话内容。 --- ## 在使用 Coexistence 的号码上将 WhatsApp 连接到 Zoho CRM https://easycoexistence.com/zh-hans/integrations/zoho-crm 将号码的 Webhook 转发到 n8n 工作流，用 phone 参数搜索 Zoho CRM（它会检查模块中的每个电话字段），无匹配时创建 Lead，并把每条消息作为备注添加到记录上。n8n 的 Zoho CRM 节点可处理 Lead 和 Contact，备注则使用同一凭据向 Zoho 的 Notes API 发起一次 HTTP 调用。 ### WhatsApp 消息如何变成 Zoho CRM 记录？ Meta 会把该号码上的每条消息发送到您设置的 Webhook 目标，这里是 n8n 的 Webhook 节点。工作流从 JSON 负载中取出发送者的号码，并以该号码作为 phone 参数调用 Zoho 的搜索端点，先搜索 Leads，再搜索 Contacts。Zoho 会检查模块中的每个电话字段，因此无论匹配的是 Mobile 还是 Phone 都算命中，您不必猜测销售人员用了哪个字段。 如果没有返回结果，n8n 的 Zoho CRM 节点会用 WhatsApp 个人资料名称和号码创建一个 Lead。无论哪种情况，工作流此时都有了记录 id，并通过 POST /Notes 把消息写成该记录的备注。备注只需要 Note_Content 和一个指明模块与记录的 Parent_Id。 ### n8n 凭据需要哪些 Zoho 权限？ 需要对您搜索和写入的模块具有读取和创建权限，另外还需要 Notes 的创建权限。Zoho 将备注范围命名为 ZohoCRM.modules.notes.CREATE，并要求同时具备父模块的创建范围。因此，如果凭据能创建 Lead，却从未获得备注范围，最后一步就会因授权错误而失败。 n8n 的 Zoho CRM 节点涵盖 Leads、Contacts、Accounts、Deals 和若干销售单据，支持 create、upsert、get、get all、update 和 delete。Notes 不在其资源之列，所以备注要通过 HTTP Request 节点发送。n8n 允许该节点复用您已连接的 Zoho 凭据，因此只需管理一份 OAuth 授权，而不是两份。 请把 API 域名设置为您的 Zoho 数据中心。在 EU 区域创建的凭据应调用 zohoapis.eu，而不是 zohoapis.com。 ### Zoho CRM 能承受多少条消息？ Zoho 按滚动 24 小时的额度来计量 API，额度取决于版本和用户数量。Free 版为 5,000。Standard 为 50,000 加每位用户 250，Professional 为 50,000 加每位用户 500，Enterprise 为 50,000 加每位用户 1,000，各版本均设有上限。 每条入站消息需要一次搜索和一次备注写入，首次发信的人还要多一次 Lead 创建。对小型企业的号码来说，这完全在付费版本的额度之内。最先遇到的上限通常是并发数：Free 允许 5 个同时调用，Standard 允许 10 个，所以群发后的集中回复可能会排队。如果看到 Zoho 返回限额错误，请把 n8n 工作流设置为一次只处理一个执行。 ### 从手机发出的回复会进入 Zoho CRM 吗？ 可以。在使用 Coexistence 的号码上，WhatsApp Business 应用仍可正常使用。有人从应用中回复时，Meta 会把这条外发消息的回显，以 smb_message_echoes 字段发送到同一个 Webhook 目标。 请为工作流增加一个处理回显的分支，并将它们记为标题为外发的备注。这样，销售人员在 Zoho 中打开该 Lead 时，就能看到对话的双方内容，无需再把截图粘贴到 CRM 中。 工作流自己通过 Cloud API 发送的消息，例如交易阶段变更后发送的已批准模板，最好在发送时记录，因为工作流此时已经掌握文本和记录 id。 - 只授予凭据 Lead 相关范围，却没有授予 ZohoCRM.modules.notes.CREATE。搜索和创建 Lead 都正常，但每条备注都会失败。 - 用位于其他 Zoho 数据中心的账户调用 zohoapis.com。请使用账户所在区域的 API 域名。 - 只搜索 Leads。已转化的客户属于 Contacts，每位来信的客户都会变成一个重复的新 Lead。 **这会取代 Zoho 自带的 WhatsApp 集成吗？** 这是另一条路径。号码通过 EasyCoexistence 保持连接，Zoho CRM 通过其 API 接收记录，团队可以在手机上或通过工作流回复。 **我可以用 Make 代替 n8n 吗？** 可以。Make 的自定义 Webhook 接收消息，再由 Zoho CRM 模块或 HTTP 模块完成搜索、创建 Lead 和写入备注。 **交易阶段变更可以发送 WhatsApp 模板吗？** 可以，通过工作流实现。让阶段变更调用 n8n 的 Webhook URL，n8n 再使用该号码的 phone number id 和令牌，通过 Cloud API 发送已批准的模板。 **EasyCoexistence 会存储消息吗？** 不会。Meta 会把 Webhook 直接发送到您的 n8n URL。EasyCoexistence 从不存储对话内容。 --- ## 在 Coexistence 号码上将 WhatsApp 连接到 Pipedrive https://easycoexistence.com/zh-hans/integrations/pipedrive 将号码的 Webhook 转发到 n8n 工作流，按电话号码搜索 Pipedrive 联系人；没有匹配时创建联系人和线索，再把每条消息写成联系人或交易上的备注。n8n 的 Pipedrive 节点可以完成全部这些操作。团队仍可继续在 WhatsApp Business 应用中回复，这些回复同样可以记录下来。 ### 一条 WhatsApp 消息如何到达 Pipedrive 联系人？ Meta 会把号码上的每条消息发送到您为它设置的 Webhook 目标地址，这里是 n8n 的 Webhook 节点。工作流用发送者的号码搜索 Pipedrive 联系人；Pipedrive 的联系人搜索涵盖电话字段，并支持精确匹配参数。找到联系人时，工作流直接使用其 id。没有找到时，工作流会用 WhatsApp 资料名称和号码创建联系人，再创建一条与其关联的线索，这样陌生人发来的第一条消息会出现在 Leads Inbox 中，等待同事跟进评估。 消息本身会成为一条备注。Pipedrive 备注只需要内容（支持 HTML），以及联系人、交易、组织或线索 id 中的至少一个。如果有进行中的交易，就挂在该交易上，否则挂在联系人上。 ### 为什么搜索步骤最先触及限制？ 因为 Pipedrive 为搜索单独设置了小得多的配额。一般 API 调用按用户在滚动的两秒窗口内限流：使用 API 令牌的 Lite 套餐为 20 个请求，Ultimate 套餐最高为 120 个。而 Search API 在所有套餐上都限制为每两秒 10 个请求。 号码平时很安静时不会察觉。但如果号码向几百位客户发送了模板，一分钟内收到 50 条回复，就会触发限制，因为每条回复都从一次搜索开始。此时工作流会收到 429 响应，如果没有重试，备注就会丢失。 有两个办法。一是在 Pipedrive 搜索节点上开启重试并设置等待；二是把电话号码到联系人 id 的映射缓存在 n8n 的工作流静态数据或一张小表中，这样客户连续发来六条消息，只需搜索一次，而不是六次。 ### 在手机上输入的回复也能被记录吗？ 可以。Coexistence 让 WhatsApp Business 应用继续在同一号码上使用，团队成员从应用中回复时，Meta 会在 smb_message_echoes 字段下，把这条发出消息的回显发送到同一个 Webhook 目标地址。 为这些回显增加一个分支，把它们记录为标记为外发的备注；如果您的团队按活动数量统计，也可以记录为已完成的活动。销售打开交易时，就能按顺序看到客户问了什么、店里答了什么。 对于工作流自己发送的消息，例如交易进入新阶段时发送的模板，请在发送的那一刻记录备注。工作流已经有文本和交易 id，没有理由再等待 Webhook。 ### 电话号码应该如何标准化？ 只保留带国家代码的数字，不含其他字符，因为 Meta 发送的就是这种格式。发送者会以 14155550188 的形式到达，而人工录入 Pipedrive 的联系人可能写成 +1 (415) 555-0188。 工作流创建联系人时，请以纯数字形式保存号码，这样它自己的记录始终可以匹配。对于人工创建的联系人，在 n8n 中做一次性清理，把现有电话值改写成同样的格式，第一周就能回本。否则，精确匹配搜索会漏掉团队手动录入的联系人，工作流会为每个人再创建一个重复项。 如果团队喜欢原来的显示格式，可以把它保存在第二个电话条目中。Pipedrive 联系人可以有多个电话。 - 每条消息都搜索一次且不做缓存。集中的回复会触及 Search API 每两秒 10 个请求的限制，备注随之丢失。 - 为每条消息创建线索，而不是为每位新联系人创建。Leads Inbox 会被同一位客户的重复线索塞满。 - 有交易进行中时只把备注挂在联系人上。负责该交易的销售永远看不到这段对话。 **这些消息会出现在 Pipedrive 的消息收件箱中吗？** 不会。这条路径通过 Pipedrive 的 API 写入备注和线索。对话在 WhatsApp Business 应用中或由工作流回复，并记录到联系人或交易上。 **我可以用 Make 或 Zapier 代替 n8n 吗？** 可以。自定义 Webhook 或 catch hook 接收消息，再用它们的 Pipedrive 步骤或 HTTP 步骤，按同样的顺序写入联系人、线索和备注。 **交易阶段变化可以发送 WhatsApp 模板吗？** 可以，通过工作流实现。阶段变化调用 n8n 的 Webhook URL 后，n8n 会使用该号码的号码 ID 和访问令牌，通过 Cloud API 发送已批准的模板。 **EasyCoexistence 会存储这些消息吗？** 不会。Meta 把每个 Webhook 直接发送到您的 n8n URL，EasyCoexistence 从不存储对话内容。 --- ## 在 Coexistence 号码上将 WhatsApp 连接到 Bitrix24 CRM https://easycoexistence.com/zh-hans/integrations/bitrix24 将号码的 Webhook 转发到 n8n 工作流，再让它通过入站 Webhook URL 调用 Bitrix24。crm.duplicate.findbycomm 查找持有发件人号码的线索、联系人或公司，无人持有时由 crm.lead.add 创建线索，crm.timeline.comment.add 则把消息写入该记录的时间线。团队仍然在 WhatsApp Business 应用中回复。 ### n8n 如何与 Bitrix24 通信？ 通过入站 Webhook。在 Bitrix24 中，它不是接收器，而是一份凭据。您在 Bitrix24 开发者资源中创建它，选择它可使用的权限范围，并得到一个 URL，其中包含您的门户地址、创建者的用户 id 和一个密钥。在该 URL 后追加方法名，就会以该用户的身份、按该用户的权限调用 REST API。 因此在 n8n 中，每个 Bitrix24 步骤都是一个 HTTP Request 节点，向该 URL 加上 crm.lead.add.json 之类的方法发送请求。无需完成 OAuth 流程，也无需发布应用。请只授予该 Webhook CRM 权限范围，并用权限覆盖工作流所需线索和联系人的用户来创建它，因为 Bitrix24 按该用户检查访问权限。 ### 工作流会调用哪些 Bitrix24 方法？ 共三个，在 n8n 的 Webhook 节点收到来自 Meta 的消息之后依次调用。 crm.duplicate.findbycomm 使用类型 PHONE 和发件人号码，返回持有该号码的所有线索、联系人和公司的 id。这是正确的查找方式，因为它一次搜索三类记录，并且专为按通信方式匹配而设计，而不是按文本字段匹配。 如果没有返回结果，crm.lead.add 会创建一条线索，以 WhatsApp 个人资料名称作为标题，并把号码填入电话字段。随后 crm.timeline.comment.add 把消息文本作为评论写入该记录，需要 ENTITY_TYPE、ENTITY_ID 和 COMMENT。评论与通话、电子邮件一起出现在记录的时间线中，也就是销售人员本来就会查看的地方。 ### 速率限制如何影响工作流设计？ Bitrix24 用漏桶机制计量 REST 调用。每个请求都会增加计数器，计数器每秒按固定速率下降，一旦超过阈值，下一个请求就会收到 503 和 QUERY_LIMIT_EXCEEDED。在 Enterprise 套餐上，计数器每秒下降 5，阈值为 250；在其他所有套餐上，每秒下降 2，阈值为 50。 每条入站消息需要两到三次调用，所以平稳的消息流远远达不到上限。突发流量则不同：50 位客户在一分钟内回复同一条消息模板，最多就是 150 次调用。请将 HTTP Request 节点设置为失败后短暂等待再重试，并让工作流的执行逐个运行，这样突发流量会被逐步消化进 Bitrix24，而不会被拒之门外。 ### 在手机上输入的回复会进入 Bitrix24 吗？ 可以。在 Coexistence 号码上，WhatsApp Business 应用继续可用，有人从应用中回复时，Meta 会把这条发出消息的回显发送到同一个 Webhook 目的地，字段为 smb_message_echoes。 工作流中的第二个分支用与入站消息相同的方式处理这些回显，并把评论标记为发出。这样记录中就能按顺序显示完整对话，既有客户的话，也有商家的回复。 工作流通过 Cloud API 自己发送的回复，在发出时就已经在工作流手中，所以请在那一刻记录它们，而不是等待 Webhook 回传。 - 把入站 Webhook URL 粘贴到客户端代码或共享文档中。其中的密钥拥有该 Webhook 被授予的全部权限范围。 - 用看不到全部线索的用户创建 Webhook。查找会漏掉记录，工作流随之创建重复项。 - 发送突发调用却不设置重试。Bitrix24 返回 503 QUERY_LIMIT_EXCEEDED，这些消息就永远到不了时间线。 **对话会显示在 Bitrix24 Open Channels 中吗？** 此工作流不会。它通过 CRM REST API 写入线索和时间线评论，对话则在 WhatsApp Business 应用中或由工作流来回复。 **我可以用 Make 代替 n8n 吗？** 可以。Make 的自定义 Webhook 接收消息，再由 HTTP 模块对入站 Webhook URL 调用同样的三个方法。 **工作流能根据 Bitrix24 的数据发送 WhatsApp 消息模板吗？** 可以。n8n 从 Bitrix24 读取所需数据，再用号码的 phone number id 和访问令牌，通过 Cloud API 发送已获批准的消息模板。 **EasyCoexistence 会存储这些消息吗？** 不会。Meta 把每个 Webhook 直接发送到您的 n8n URL。EasyCoexistence 从不存储对话内容。 --- ## 将 WhatsApp 联系人转化为 RD Station Marketing 转化 https://easycoexistence.com/zh-hans/integrations/rd-station 将号码的 Webhook 转发到 n8n 工作流，并针对每位发送者，用您的 API 密钥向 api.rd.services/platform/conversions 发送一个转化事件 POST 请求给 RD Station Marketing。RD Station 接受用电话号码代替电子邮件，因此没有电子邮件的 WhatsApp 联系人也能成为潜在客户，带上标签，随时可进入您的自动化流程。团队仍然在手机上回复消息。 ### WhatsApp 消息如何成为 RD Station 潜在客户？ Meta 会把号码上的每条消息发送到您设置的 Webhook 目标，这里是 n8n 的 Webhook 节点。工作流从负载中读取发送者的号码和个人资料名称，并向 RD Station Marketing 的转化端点发送一个 HTTP POST 请求，API 密钥放在查询字符串中。 请求体包含设为 CONVERSION 的 event_type、设为 CDP 的 event_family，以及一个负载，其中的 conversion_identifier 由您自行决定，例如 whatsapp-inbound。负载内放入 name、mobile_phone 和任何标签。若联系人是新的，RD Station 会创建该联系人，无论是否新建，都会记录这次转化，因此联系人的历史会显示对方通过 WhatsApp 进入以及进入的时间。 之后就和平常使用 RD Station 一样：按转化或标签进行细分，再交给您的自动化流程处理。 ### 每条消息都应该算作一次转化吗？ 不应该，这是最关键的设计决定。客户若连续发送八条短消息，就会登记八次转化，既夸大报表数据，也可能让同一个自动化流程触发八次。 请在某个号码的第一条消息时转化，或在您选定的间隔之后（例如三十天）的第一条消息时转化。n8n 可以把每个号码最近一次转化的日期保存在工作流的静态数据或一张小表中，日期较近时就跳过调用。 对于比首次联系更具体的情况，请使用不同的 conversion_identifier。对促销模板的回复、含有某个关键词的消息，或对交互式消息的按钮点击，都可以各自成为一种转化，让 RD Station 得到清晰的细分，而不是一股没有区分的数据流。 ### RD Station 能反过来触发 WhatsApp 消息吗？ 通过工作流可以。RD Station Marketing 可以在潜在客户完成转化或被标记为商机时触发 Webhook，接收端的 n8n Webhook 则可以通过 Cloud API 发送已获批准的 WhatsApp 模板，使用 EasyCoexistence 控制台中该号码的 phone number id 和访问令牌。 这里模板很重要，因为潜在客户可能在过去 24 小时内没有发过消息。超出这个窗口，只有 Meta 已批准的模板才能送达，自由文本会失败。在窗口内，普通文本回复即可。 手机上的 WhatsApp Business 应用同样会显示这些已发送的消息，因为 Coexistence 让应用和 API 使用同一个号码。销售人员在手机上接手对话时，能看到自动化已经说过的内容。 - 为每条消息都发送一次转化。一位话多的客户会登记同样多的转化，并重复触发同一个自动化流程。 - 在任何人都能读取的浏览器页面中提交 API 密钥。请把调用放在 n8n 工作流内，密钥才不会外泄。 - 在由 RD 触发的流程中，向 24 小时内没有发过消息的潜在客户发送自由文本。此时只有已批准的模板才能送达。 **这次 RD Station 调用需要 OAuth 吗？** 不需要。转化端点使用查询字符串中的 API 密钥进行验证，而发送转化事件正是该密钥的用途。 **如果 WhatsApp 联系人没有电子邮件怎么办？** 请发送电话号码。只有转化未提供电话号码时，RD Station 才要求提供电子邮件。 **我可以用 Make 或 Zapier 代替 n8n 吗？** 可以。任何能接收 Webhook 并发出 HTTP POST 请求的工具，都可以向 RD Station 发送同样的转化请求体。 **EasyCoexistence 会存储消息吗？** 不会。Meta 会把 Webhook 发送到您的 n8n URL，EasyCoexistence 从不存储对话内容。 --- ## 在 Coexistence 号码上将 WhatsApp 连接到 GoHighLevel 联系人 https://easycoexistence.com/zh-hans/integrations/gohighlevel 将号码的 Webhook 转发到 n8n 工作流，用 n8n 的 HighLevel 节点把发送者更新插入（upsert）为 HighLevel 联系人，再通过 POST /contacts/{contactId}/notes 将每条消息写为备注。使用子账户设置中的 Private Integration 令牌进行验证。只要把每个 phone number id 映射到对应的子账户，一个工作流就能服务所有客户。 ### WhatsApp 消息如何到达 HighLevel 联系人？ Meta 会把号码上的每条消息发送到您设置的 Webhook 目标，这里是 n8n 的 Webhook 节点。工作流将发送者的号码和 WhatsApp 个人资料名称交给 n8n 的 HighLevel 节点，其联系人资源提供创建或更新操作，因此新发送者会成为联系人，已有的发送者则会被找到而不是重复创建。 拿到联系人 id 后，由 HTTP Request 节点把消息正文发送到 /contacts/{contactId}/notes。备注会出现在联系人记录上，任何人打开记录都能看到客户写了什么。当消息需要跟进时，HighLevel 节点还可以直接在联系人上创建任务，或在销售管道中创建商机，这两项它都原生支持。 团队全程仍可继续在 WhatsApp Business 应用中回复。 ### 工作流应该使用哪种令牌？ 使用 Private Integration 令牌。HighLevel 的 API v2 可通过 OAuth 或这类令牌访问，而旧的 v1 API 密钥已终止支持。Private Integration 令牌在子账户的设置中创建，权限范围取决于您勾选的项目，并像任何访问令牌一样放在 Authorization 标头中发送。 它不会自动刷新，这很适合自动化：在有人轮换之前，它会一直有效。当您轮换时，HighLevel 会让新旧令牌同时有效 7 天，您可以在这段时间内把新令牌粘贴到 n8n，之后旧令牌才会失效。 只勾选工作流需要的权限范围：联系人、备注，以及（如果用到）商机和任务。如果在设置中找不到 Private Integrations，HighLevel 说明需要先在 Labs 中启用。 ### 一个工作流如何服务多个客户子账户？ 按接收号码进行路由。Meta 发送的每个 Webhook 都包含接收消息的商业号码的 phone_number_id。让所有客户的号码都指向同一个 n8n Webhook，维护一张小表，把每个 phone_number_id 对应到该客户的子账户及其令牌，并在每次运行开始时查出令牌。 这样所有客户只需维护一个工作流，对代理机构而言尤其重要。匹配逻辑或备注格式的一次修复，会同时对所有人生效。 速率限制按每个应用在每个子账户内计算，所以客户之间不会占用彼此的额度：每个子账户各有每 10 秒 100 个请求和每天 200,000 个请求的额度。 ### 在手机上输入的回复会同步到 HighLevel 吗？ 可以。在 Coexistence 号码上，WhatsApp Business 应用仍可继续使用，当有人从应用中回复时，Meta 会把这条发出消息的回显发送到同一个 Webhook 目标，字段为 smb_message_echoes。 为这些回显添加一个分支，并将它们写为标记为已发送的备注。这样联系人记录就按顺序保存了客户的消息和商家的回复，这正是客户打开 CRM 时期望看到的内容。 当工作流本身通过 Cloud API 发送消息时，例如预约成功后发送已获批准的消息模板，请在发送的同时写入备注。工作流已经掌握文本和联系人 id。 - 使用 v1 API 密钥。HighLevel 的 v1 API 已终止支持，API v2 需要 Private Integration 令牌或 OAuth。 - 在 7 天重叠期内没有更新 n8n 就轮换了 Private Integration 令牌。旧令牌失效后，所有调用都会失败。 - 用某一个子账户的令牌写入所有客户的消息。请先把 phone_number_id 映射到正确的子账户，否则记录会落到错误的客户名下。 **消息会出现在 HighLevel 的 Conversations 标签页中吗？** 此工作流不会。它通过 API 写入联系人、备注、任务和商机，对话则在 WhatsApp Business 应用中或由工作流来回复。 **我可以用 Make 或 Zapier 代替 n8n 吗？** 可以。用自定义 Webhook 或 catch hook 接收消息，再用 HTTP 步骤以同一个令牌调用 HighLevel 的 API v2。 **预约成功后可以发送 WhatsApp 确认消息吗？** 可以，通过工作流实现。当 HighLevel 调用 n8n 的 Webhook URL 时，n8n 会使用该号码的 phone number id 和访问令牌，通过 Cloud API 发送已获批准的消息模板。 **EasyCoexistence 会存储这些消息吗？** 不会。Meta 会把每个 Webhook 直接发送到您的 n8n URL，EasyCoexistence 从不存储对话内容。 --- ## 将 Coexistence 号码用作 Chatwoot WhatsApp Cloud 收件箱 https://easycoexistence.com/zh-hans/integrations/chatwoot Chatwoot 的 WhatsApp Cloud 收件箱需要三个值：WhatsApp Business Account ID、号码 ID 和访问令牌。Coexistence 号码三者都能提供。用它们创建收件箱，再把该号码的 Webhook 目标地址设为 Chatwoot 的 Webhook URL，并填入相同的验证令牌，团队就可以同时在 Chatwoot 和手机上回复消息。 ### 如何将 Coexistence 号码连接到 Chatwoot？ 分两步，按以下顺序进行。 先在 Chatwoot 中添加收件箱，选择 WhatsApp，再选择 WhatsApp Cloud 提供商并使用手动设置。填写号码、号码 ID、WhatsApp Business Account ID 和访问令牌。这些信息都可以在 EasyCoexistence 控制台的该连接页面中查看，助手也可以通过 get_api_credentials 获取。随后 Chatwoot 会为这个收件箱显示一个 Webhook URL 和一个 Webhook 验证令牌。 然后在 EasyCoexistence 中，把该号码的 Webhook 目标地址设为这个 URL，并填入相同的验证令牌。Meta 会向 Chatwoot 发送验证请求，Chatwoot 作出响应，此后发给该号码的每条消息都会进入收件箱。中间没有任何环节，因此也没有需要保持运行的工作流。 ### 从手机发出的回复会显示在 Chatwoot 中吗？ 会。在 Coexistence 号码上，于 WhatsApp Business 应用中输入的回复，会由 Meta 以 smb_message_echoes 事件的形式上报。Chatwoot 的 Webhook 任务能识别这个字段，并把该消息记为对应对话中的外发消息。其源代码直接描述了这种情形：企业同时在 Chatwoot 和应用中回复，消息同步到 Chatwoot。 这让分工在实际中行得通。店主可以继续在手机上回复老客户，团队则在电脑前处理共享收件箱，双方都能看到对方发出的内容，无需转发截图。 从 Chatwoot 发出的消息通过同一号码的 Cloud API 发送，所以手机上也会显示。 ### 为什么 Chatwoot 收件箱不应填写应用密钥？ 因为这些投递是用您没有的密钥签名的。Meta 用拥有该订阅的应用的应用密钥为每个 Webhook 签名，这个应用就是 EasyCoexistence 应用，而该密钥从不对外共享。 按 Chatwoot 当前的源代码，对于手动配置的 WhatsApp Cloud 渠道，只有在已存储应用密钥，或该渠道是通过 Chatwoot 自己的 Embedded Signup 创建时，才会校验 X-Hub-Signature-256 标头。没有应用密钥的手动收件箱会接受这些投递；只要填了任何应用密钥，就会把每一条都当作未授权而拒绝。 这里起保护作用的是验证令牌。请选一个足够长的随机值，因为 Chatwoot 正是靠它来区分 Meta 的验证请求和其他人的请求。 ### Chatwoot 在这个号码上做不到什么？ 无法同时在第二个位置接收 Webhook。Meta 只会把一个号码的 Webhook 发往一个目标地址，所以 Chatwoot 占用它时，n8n 工作流不会收到相同的事件。如果两者都需要，可以把目标地址指向您自己搭建的小型中继，由它把每次投递同时转发给 Chatwoot 和工作流。 Coexistence 的限制照常适用：API 每秒最多发送 20 条消息，自由文本只能在客户最后一条消息后的 24 小时内发出，超出之后需要使用消息模板。 WhatsApp Business 应用仍需至少每 14 天打开一次，EasyCoexistence 会为您监控这一点。 - 在 Chatwoot 收件箱中填写了应用密钥。投递是用 EasyCoexistence 应用的密钥签名的，因此 Chatwoot 会把每一条都当作未授权而拒绝。 - 在 EasyCoexistence 中使用了与 Chatwoot 显示的不同的验证令牌。Meta 的验证会失败，收件箱永远收不到消息。 - 选择了 Chatwoot 的 Embedded Signup，而不是手动流程。这会通过 Chatwoot 自己的 Meta 应用连接号码，属于另一个独立的连接。 **自托管的 Chatwoot 也适用吗？** 适用。Webhook URL 使用您自己的 Chatwoot 域名，而不是 app.chatwoot.com，其余设置完全相同。 **使用 Chatwoot 需要我自己的 Meta 应用吗？** 不需要。号码通过 EasyCoexistence 连接，由它提供凭据并转发 Webhook。Chatwoot 的指南之所以介绍创建 Meta 应用，只是因为它假定您没有应用。 **可以把多个号码接入 Chatwoot 吗？** 可以。为每个号码创建一个 WhatsApp Cloud 收件箱，并把每个号码的 Webhook 目标地址设为对应收件箱的 URL 和验证令牌。 **EasyCoexistence 能看到这些对话吗？** 不能。Meta 会把 Webhook 直接发送给 Chatwoot，EasyCoexistence 从不存储对话内容。 --- ## 将 WhatsApp 消息记录到 Airtable，并从 base 发送 https://easycoexistence.com/zh-hans/integrations/airtable Airtable 的传入 Webhook 触发器只接受 POST 请求，因此无法响应 Meta 的验证 GET 请求，也不能直接作为号码的 Webhook 目标地址。请将目标地址指向一个 n8n 工作流，由它把每条消息追加到表中。发送则可以在 Airtable 内完成：Run a script 自动化可以用 fetch 调用 Cloud API，号码的访问令牌则保存为密钥。 ### 为什么 Airtable 无法直接接收 WhatsApp Webhook？ 因为 Meta 在投递任何内容之前，会先检查目标地址。它会发送一个带有验证值（challenge）的 GET 请求，并期望响应正文原样返回该值。Airtable 的 When webhook received 触发器只接受 POST 请求，并且只返回自己固定的 JSON，所以验证无法通过，Meta 也就不会开始投递。 解决办法是在中间加一个环节。由 n8n 的 Webhook 节点处理验证并接收每条消息，再由 n8n 的 Airtable 节点追加一行，内容包括：发送者、资料名称、文本、消息 ID、时间戳和接收消息的 phone number id。在 Make 或 Zapier 中也可以用同样的结构。 这个中间环节还有一个好处。Airtable 的 Webhook 触发器每秒只允许 5 个请求，而工作流工具可以把突发的消息排队，否则这些请求会被拒绝。 ### 如何从 Airtable base 发送 WhatsApp 模板？ 使用动作为 Run a script 的自动化。触发条件可以是记录进入某个视图、某个字段发生变化，或者某个按钮被点击。脚本通过 input.config() 读取记录中的电话号码和字段，并用 fetch 调用 Cloud API 的 messages 端点。Airtable 自动化脚本在服务器端运行，因此不会受到浏览器限制的影响。 请把访问令牌保存为脚本编辑器中的密钥，而不是写在代码里。Airtable 会在控制台输出中隐藏密钥，并且只有能访问脚本全部密钥的人才能编辑该脚本。 对于客户在过去 24 小时内没有主动联系的情况，请使用模板，因为自由文本只能在该时间窗口内送达。脚本可以把返回的消息 ID 写回记录，从而将这次发送与对应的行关联起来。 ### 消息表应该是什么样的？ 每条消息一行，并把 WhatsApp 消息 ID 作为主字段。Meta 会重试它认为失败的投递，而工作流在追加之前先查找该 ID，就不会重复写入同一条消息。 保留一个方向字段，取值为 inbound 和 outbound。在 Coexistence 号码上，团队在 WhatsApp Business 应用中输入的回复，会作为 smb_message_echoes 事件到达同一个 Webhook。把它们记为 outbound 行，base 中就有完整的对话，而不是只有一方。 把每条消息关联到 Contacts 表，并以仅含数字的电话号码作为键，这正是 Meta 发送的格式。之后通过汇总（rollup）即可显示每个联系人最近一次的 inbound 时间，自动化只需要这一个字段，就能判断该用自由文本还是模板。 - 把 Airtable 的 Webhook URL 设为号码的目标地址。它只接受 POST，Meta 的验证 GET 会失败，因此什么都不会被投递。 - 把访问令牌直接粘贴到脚本正文中。请将其保存为脚本密钥，这样代码和日志中都不会出现它。 - 从记录自动化向 24 小时内没有来信的人发送自由文本。只有已获批准的模板才能送达。 **Airtable 免费方案可以使用 Run a script 吗？** Airtable 表示该动作适用于所有方案类型，但限制各不相同，并注明 Team 方案试用版不提供此功能。 **可以不用 n8n，改用 Make 或 Zapier 吗？** 可以。这三者中的任何一个都能接收 Webhook、响应验证并追加行。唯独 Airtable 本身不能作为目标地址。 **Airtable 按钮可以发送 WhatsApp 消息吗？** 可以。使用 When a button is clicked 触发器，配合调用 Cloud API 的 Run a script 动作，并用该行的数据填充模板。 **EasyCoexistence 会存储这些消息吗？** 不会。Meta 会把每个 Webhook 投递到您的 n8n URL，唯一的副本就是您的工作流写入 Airtable 的那一份。 --- ## 将 WhatsApp 消息记录到 Google Sheets，并从表格发送 https://easycoexistence.com/zh-hans/integrations/google-sheets 将号码的 Webhook 目标地址指向一个 n8n 工作流，由其中的 Google Sheets 节点为每条消息追加一行：发送者、姓名、文本、消息 ID 和时间。若要从表格发送，可以编写 Apps Script 函数，逐行循环并用 UrlFetchApp 调用 Cloud API，使用该号码的 phone number id 和访问令牌。团队仍可继续在 WhatsApp Business 应用中回复。 ### 每条 WhatsApp 消息如何变成一行数据？ Meta 会把号码上的每条消息发送到您设置的 Webhook 目标地址，这里是一个 n8n Webhook 节点，它同时负责响应 Meta 的验证请求。下一个节点是使用 Append Row 操作的 Google Sheets，把负载中的字段映射到各列：发送者号码、资料名称、文本、WhatsApp 消息 ID、时间戳，以及接收消息的 phone number id。 如果希望重试不产生副作用，请使用以消息 ID 为键的 Append or Update Row，而不是普通追加。Meta 认为投递失败时会重新投递消息，以 ID 为键后，第二次投递只会更新同一行。 在 Coexistence 号码上，您在 WhatsApp Business 应用中输入的回复，会以 smb_message_echoes 事件的形式到达同一个 Webhook。用一个方向列把它们记录下来，表格就同时包含双方的消息。 ### Sheets 的配额在哪里会成为限制？ 限制在每个用户的写入次数。Sheets API 允许每个项目每分钟 300 次写入请求，每个用户每个项目每分钟 60 次，而一个 n8n 凭据对应一个用户。因此，每条消息追加一行的工作流，持续运行时大约每秒只能处理一条消息。 对大多数商店号码来说，这已经足够。但在群发模板之后，几百位客户在几分钟内回复时就不够了。此时 API 会返回 429 Too Many Requests，如果没有重试，就会丢行。 有两种修复方法，任选其一即可。一是在 Google Sheets 节点上开启重试并设置等待时间，这与 Google 自己建议的指数退避一致。二是批量处理：让 n8n 收集三十秒内的消息，再用一次请求全部追加，把多次写入合并为一次。 ### 如何从表格发送模板？ 使用 Apps Script，从表格的 Extensions 菜单进入。函数读取尚未发送的行，对每一行用 UrlFetchApp 调用 Cloud API 的 messages 端点，并把返回的消息 ID 和时间写回该行。您可以用定时触发器每隔几分钟运行一次，也可以通过自定义菜单手动运行。 请把访问令牌存放在脚本属性中，而不是写进代码，这样能查看脚本的人也看不到它。 请留意配额。消费者 Google 账户每天有 20,000 次 URL Fetch 调用，Workspace 账户为 100,000 次，而且每次执行在六分钟后会停止。请分块处理各行，并在继续之前把每一行标记为已发送，这样中断的运行会从停止处继续，而不会重复发送。 - 追加时没有以消息 ID 为键。Meta 重试后，同一条消息会被写入两行。 - 在回复高峰期通过单一凭据每条消息写一行。每用户每分钟 60 次写入的限制会返回 429，导致丢行。 - 向 24 小时内没有联系过您的人从表格发送自由文本。只有已获批准的模板才能在该时间窗口之外送达。 **可以用 Make 或 Zapier 代替 n8n 吗？** 可以。Make 的自定义 Webhook 或 Zapier 的 catch hook 都能接收消息，再由其 Google Sheets 步骤添加一行。 **n8n 以哪个 Google 账户写入？** 以授权 n8n Google 凭据的那个账户。该账户需要有表格的编辑权限，工作流消耗的正是它的每用户写入配额。 **电话号码列的格式正确吗？** 请把号码存为纯文本，即带国家代码、不含加号的数字，这也是 Meta 发送的格式。否则 Sheets 会把它们当作数字处理，去掉开头的加号，还可能改变较长数值的显示格式。 **EasyCoexistence 会保存消息副本吗？** 不会。Meta 把每个 Webhook 直接投递到您的 n8n URL，表格是唯一的副本。 --- ## 在 Supabase Edge Function 中接收 WhatsApp Webhook https://easycoexistence.com/zh-hans/integrations/supabase Supabase Edge Function 可以直接作为号码的 Webhook 目的地。它用 hub.challenge 的值响应 Meta 的验证 GET 请求，把每条 POST 过来的消息写入 Postgres 表，并通过 Cloud API 回复。部署时请关闭 JWT 验证：Supabase 默认要求有效的 JWT，而 Meta 无法发送。 ### Edge Function 需要做什么？ 两件事，分别对应两种方法。 收到 GET 时，它负责响应 Meta 的验证。从查询字符串中读取 hub.mode、hub.verify_token 和 hub.challenge，将验证令牌与您在目的地中填写的验证令牌比对，然后以纯文本正文返回 challenge，状态码为 200。令牌不匹配时返回 403。 收到 POST 时，它负责接收事件。解析请求体，从 entry、changes 和 value 中取出消息，写入表中，并返回 200。响应必须快：Meta 会把缓慢或失败的响应视为投递失败并重试，同一条消息就会收到两次。 在 EasyCoexistence 中，把该函数的 URL 和同一个验证令牌设为号码的 Webhook 目的地，Meta 即开始投递。 ### 为什么函数对 Meta 返回 401？ 因为 JWT 验证处于开启状态。Supabase 会在 Edge Function 的处理程序运行之前，先验证 Authorization 标头中的 JWT，这是每个函数的默认行为。Meta 不会发送这样的标头，所以平台会拒绝验证 GET 请求和每一次投递，您的代码根本看不到它们。 只需为这个函数关闭它。可以用 supabase functions deploy whatsapp --no-verify-jwt 部署，或者在 supabase/config.toml 中该函数的配置段下设置 verify_jwt = false。Supabase 的文档描述的正是这种情况：由外部 Webhook 服务方调用的公开端点。 平台的检查关闭后，函数需要自己的检查。签名标头对您不可用，因为 Meta 使用拥有该订阅的应用的 app secret 签名。请在目的地 URL 中加入一个很长的随机密钥作为查询参数，并拒绝不带它的请求，示例在 POST 中就是这样做的。 ### 函数应如何存储和回复？ 先存储，后回复。以 WhatsApp 消息 id 为唯一约束执行 upsert，这样 Meta 的重试会落在同一行，而不会产生重复记录。如果有多个号码指向该函数，请在每一行中保存接收消息的 phone_number_id。 对于耗时的工作，例如回复前调用模型或其他 API，请把任务交给 EdgeRuntime.waitUntil，并立即返回响应。函数会一直运行到该 promise 完成，而 Meta 已经拿到了 200。Supabase 在空闲 150 秒后停止等待并返回 504，所以先做完所有工作再响应的处理程序，最容易引发重试。 回复发送到 Cloud API 的消息端点，使用该号码的 phone number id 和访问令牌，二者都保存为函数密钥。在客户最后一条消息后的 24 小时内可以发送自由文本；超出之后，只能发送已获批准的消息模板。 ### 从手机发出的消息会到达函数吗？ 会。在 Coexistence 号码上，WhatsApp Business 应用仍可正常使用，当有人从应用回复时，Meta 会把这条外发消息的回显投递到同一个目的地，字段为 smb_message_echoes，数据在 message_echoes 数组中，而不是 messages。 请扩展解析器，同时读取两者，并保存一个 direction 列。这样表中就有完整的对话，包括客户的消息和企业的回复，这正是大多数人之后想要查询的内容：响应时间、未回复的对话、每位联系人最后一次入站的时间。 最后这个值也是所有发送路径所需的输入，因为它决定回复可以用自由文本，还是必须用消息模板。您可以基于该表建立视图，按联系人提供这个值，供应用的其他部分使用。 - 部署时没有关闭 JWT 验证。Supabase 会在处理程序运行之前以 401 拒绝 Meta 的请求，一条消息也收不到。 - 把 challenge 包在 JSON 中返回。Meta 需要原始值作为正文，否则验证会悄无声息地失败。 - 在响应之前做耗时的工作。Meta 会重试它认为失败的请求，同一条消息会被处理两次。 - 关闭了 JWT 验证却没有任何自己的检查。任何人只要找到该 URL，就能向表中写入伪造的消息。 **Supabase 免费计划可以使用吗？** Edge Function 可在免费计划上运行，实际耗时上限为 150 秒，付费计划为 400 秒。响应迅速的 Webhook 处理程序远不会触及这两个上限。 **函数中应该使用 service role 密钥吗？** 只能在服务器端使用，像示例这样从函数的环境变量中读取。它会绕过行级安全策略，所以绝不能出现在浏览器中。 **一个函数可以服务多个号码吗？** 可以。把每个号码的 Webhook 目的地都指向它，并根据每个负载中的 phone_number_id 分支处理。 **EasyCoexistence 能看到这些消息吗？** 不能。Meta 会把每个 Webhook 直接投递到您的函数，EasyCoexistence 从不存储对话内容。 --- ## 在 Coexistence 号码上将 WhatsApp 连接到 Activepieces https://easycoexistence.com/zh-hans/integrations/activepieces Activepieces 有一个 WhatsApp Business piece，用访问令牌和 WhatsApp Business Account id 连接，而 Coexistence 号码正好提供这两项。它的 New Incoming Message 触发器会自行响应 Meta 的验证，所以触发器的 URL 可以直接作为号码的 Webhook 目的地。请将该 piece 可选的应用密钥留空，这样团队继续使用手机，流程会在每条消息到达时运行。 ### 如何将 Coexistence 号码连接到 Activepieces？ 在 Activepieces 中创建 WhatsApp Business 连接，需要两个值：访问令牌和 WhatsApp Business Account id。EasyCoexistence 控制台会显示该连接的这两项，助手也可以通过 get_api_credentials 获取。该 piece 的说明会谈到创建 Meta 应用和系统用户，因为它假定您两者都没有。这里号码已经连接好，直接粘贴这些值即可。 然后创建一个以 New Incoming Message 触发器开头的流程，在触发器上设置一个您自选的验证令牌，并发布该流程。把触发器的 Webhook URL 复制到 EasyCoexistence 中该号码的 Webhook 目的地，并填入相同的验证令牌。Meta 发出验证请求，触发器作出响应，此后发往该号码的每条消息都会启动一次运行。 ### 为什么应用密钥必须留空？ 因为为这些投递签名的密钥不属于您，无法粘贴。Meta 用拥有该订阅的应用的应用密钥为每个 Webhook 签名，而通过 EasyCoexistence 连接的号码，其应用就是 EasyCoexistence 应用，它的密钥从不对外共享。 该 piece 把这个字段视为可选。留空时，触发器会照常接受投递。若填入其他应用的应用密钥，每次投递都无法通过 X-Hub-Signature-256 校验并被静默忽略，看起来就像消息根本没有到达。 真正把陌生人挡在握手之外的是验证令牌。请选择一个足够长的随机值，并保持触发器 URL 私密，因为它就是启动您流程的地址。 ### 消息到达后，流程能做什么？ 触发器交给流程的是一条扁平化的消息：发送者、资料名称、消息 id、类型、文本、媒体 id（如有）、按钮和列表回复，以及接收消息的号码 id。此后它就是一个普通的 Activepieces 流程，可以接入其他 piece，例如 CRM、表格或 AI 步骤。 回复使用同一个 piece。Send Message 发送自由文本，只有在客户最后一条消息后的 24 小时内才能送达。Send Template Message 发送已批准的消息模板，超过该时间窗口后只有它能送达。交互式按钮、列表、媒体、位置和表情回应都是各自独立的操作。 Activepieces 自己的说明指出，Meta 每个应用只接受一个 Webhook URL。按号码设置目的地后，限制变为每个号码一个 URL，所以需要处理多种事件类型的流程，应在同一个流程内部分支。 ### 在手机上输入的回复会到达流程吗？ 它们会到达 Webhook，但不会触发这个触发器。在 Coexistence 号码上，Meta 会把在 WhatsApp Business 应用中输入的每条回复的回显，以 smb_message_echoes 字段发送到同一个目的地。该 piece 的 New Incoming Message 触发器只读取 messages 字段，其余一律丢弃。 如果流程需要手机上的回复，请改用 Activepieces 通用的 Webhook piece 来启动，它接受任何 HTTP 方法，并在其同步 URL 上用 Return Response 步骤响应验证用的 GET 请求。随后由您自行解析原始负载，两个字段都包含在内。 对大多数流程来说，该 piece 的触发器更简单：它只响应客户，而团队的回复仍可在手机上的应用中查看。 - 把应用密钥粘贴进 WhatsApp 连接。投递使用的是 EasyCoexistence 应用的密钥签名，因此每一条都会被忽略。 - 在发布流程之前就设置目的地。Meta 会立即验证，而未发布的流程无法响应。 - 以为 New Incoming Message 触发器能看到在手机上输入的回复。它只读取 messages 字段，不读取 smb_message_echoes。 **自托管的 Activepieces 能用吗？** 可以。该 piece 是开源的，可在 Activepieces 云端或自托管环境中运行，前提是该实例能通过 HTTPS 从互联网访问。 **流程用哪个号码发送消息？** 使用您在操作的号码字段中选择的号码，该列表显示连接所指向的 WhatsApp Business Account 下的号码。 **我还能在同一个号码上使用 n8n 或 Make 吗？** 不能同时使用。Meta 只会把一个号码的 Webhook 发往一个目的地，所以请选一个工具来接收，或从它转发给另一个。 **EasyCoexistence 会存储这些消息吗？** 不会。Meta 把每个 Webhook 直接投递到 Activepieces 触发器，EasyCoexistence 从不存储对话内容。 --- ## 借助 Coexistence 在 WhatsApp 上运行 Typebot 流程 https://easycoexistence.com/zh-hans/integrations/typebot Typebot 的 WhatsApp 渠道需要一个访问令牌、一个 WhatsApp Business Account id 和一个 phone number id，然后给出 Callback URL 和验证令牌。前三项取自已连接的号码，Typebot 可选的应用密钥留空，并把它的 Callback URL 和验证令牌设为该号码的 Webhook 目的地。 ### Typebot 的哪些字段取自已连接的号码？ Typebot 的 WhatsApp 向导位于机器人的 Share 标签页，需要四项内容：应用密钥、System User Token、WhatsApp Business Account ID 和 Phone number ID。 其中三项直接来自该连接。控制台会显示该号码的 WABA id、phone number id 和访问令牌；如果由助手代您获取，get_api_credentials 工具会返回相同的值。把它们粘贴到对应字段即可。 应用密钥需要留空。Typebot 对入站流量只用它做一件事：校验 Meta 在每次投递中附加的 X-Hub-Signature-256 请求头。对于通过 Tech Provider 连接的号码，Meta 使用提供方的应用密钥签名，而该密钥从不共享，因此您在此填写任何值，都会让 Typebot 拒绝每一条真实消息。字段留空时，Typebot 会跳过该校验并接受投递。 ### Typebot 的 Callback URL 和验证令牌填在哪里？ 填入该号码的 Webhook 目的地，而不是 Meta 应用的控制台。 Typebot 的向导会让您把 Callback URL 和 Verify Token 粘贴到您自己 Meta 应用的 WhatsApp 设置中。通过 EasyCoexistence 使用 Coexistence 时，不涉及您自己的应用：Meta 会把该号码的事件路由到连接上设置的目的地。因此请从 Typebot 的最后一步复制这两个值，并将它们设为目的地，可在控制台中设置，也可使用 set_webhook_destination。 随后 Meta 会向 Typebot 发送验证用的 GET 请求，Typebot 返回 challenge，此后发给该号码的每条消息都会到达机器人。Typebot 的验证令牌只能使用一次：验证成功的那一刻，它就会从 Typebot 的数据库中删除。之后如需再次设置目的地，请先重新运行向导，生成新的令牌。 ### 机器人如何处理 24 小时窗口？ Typebot 回复的是主动给它发消息的人，这使几乎所有消息都落在客户服务窗口之内。客户每次发来消息，Meta 都会开启一个 24 小时窗口，窗口内可以不用模板发送任何服务类消息。因此只负责应答的机器人属于最简单的情形。 问题出在会等待的流程。Wait 块，或客户沉默超过一天后恢复的会话，会尝试在窗口之外发送自由文本消息，Meta 会以错误 131047 拒绝。Typebot 的会话过期超时默认为 4 小时，最多可设为 48 小时，它决定的是回头的客户何时开始新的对话，而不是 Meta 是否接受这条消息。 由于使用的是 Coexistence，团队仍能在 WhatsApp Business 应用中看到每一段对话，只要机器人不该回答，随时可以在手机上接手。 - 把 Meta 应用密钥粘贴到 Typebot。消息使用 Tech Provider 的密钥签名，Typebot 会因签名无效而拒绝每一条消息。 - 重复使用旧的 Typebot 验证令牌。它在一次验证成功后即被删除，再次设置目的地需要从向导获取新的令牌。 - 分享 Callback URL。签名校验关闭后，知道该 URL 就能发起请求，因此请像对待密码一样保管它。 **使用 Typebot 需要自己的 Meta 应用吗？** 不需要。Typebot 的指南假定您有一个，因为大多数人是自己连接号码。通过 Tech Provider 使用 Coexistence 时，访问令牌和各项 id 来自该连接，Meta 会把 Webhook 路由到 Typebot。 **团队还能在手机上看到机器人发出的消息吗？** 可以。通过 Cloud API 发送的消息会出现在同一号码的 WhatsApp Business 应用中，因此员工可以查看对话并接手。 **Typebot 和 n8n 能同时接收同一号码的消息吗？** 不能。一个号码只有一个 Webhook 目的地。如果两者都需要这些事件，请把目的地指向 n8n，再由工作流把原始负载转发到 Typebot 的 Callback URL。 **Typebot 会存储对话内容吗？** Typebot 会保存自己的会话和结果数据，任何渠道都是如此。EasyCoexistence 从不存储消息内容：Meta 直接投递到您设置的目的地。 --- ## 通过 Coexistence 将 Botpress 机器人连接到 WhatsApp https://easycoexistence.com/zh-hans/integrations/botpress 在 Botpress 的 WhatsApp 集成中选择 Manual Configuration。粘贴已连接号码的访问令牌和号码 ID，自选一个验证令牌，App ID 和 Client Secret 留空。然后把 Botpress 的 Webhook URL 和该验证令牌设为此号码的 Webhook 目标，Meta 就会把每条消息送到机器人。 ### 哪种 Botpress 配置适用于 Coexistence 号码？ Manual Configuration。其他选项会通过 Botpress 自己的 Meta 应用来连接号码，这等于对号码重新做一次接入，而不是使用已经连接好的号码。 在 WhatsApp 集成中，打开 Configuration 下拉菜单并选择 Manual Configuration。它需要 Verify Token、Access Token、Default Bot Phone Number ID，另有可选的 App ID、Client Secret 和 WABA ID。 访问令牌、号码 ID 和 WABA ID 都来自该连接：控制台会显示它们，get_api_credentials 也会把它们返回给助手。验证令牌可以是您自选的任意字符串。App ID 和 Client Secret 保持为空。Botpress 的指南把密钥当作需要填写的字段，但其集成定义将它标为可选，并说明没有它就会跳过签名验证。这一点很重要，因为 Meta 用 Tech Provider 应用的密钥为每次投递签名，而任何客户都不持有这个密钥。 ### Botpress 的 Webhook 如何收到 Meta 的消息？ 通过号码的 Webhook 目标。Botpress 的指南要求您把它的 Webhook URL 和验证令牌粘贴到 Meta 应用的 WhatsApp 配置中。这里没有属于您的 Meta 应用：Meta 会把号码的事件路由到连接中指定的任何目标。因此，请复制 Botpress 为该集成显示的 Webhook URL，连同相同的验证令牌，在控制台或通过 set_webhook_destination 设为目标。 Meta 会发送一个验证 GET 请求，Botpress 作出响应，投递随即开始。Botpress 保存手动配置时，还会向 Graph 查询该令牌由哪个应用签发，以此检查令牌，因此无效或已撤销的令牌会在保存时失败，而不是等到第一条消息才出错。 Botpress 的处理程序也会处理 smb_message_echoes，这是有人从 WhatsApp Business 应用回复时 Meta 发送的事件。因此，机器人看得到手机上的回复，而不是对其一无所知。 ### 机器人需要了解 Coexistence 的哪些方面？ 首先要知道可能已经有真人在对话。WhatsApp Business 应用在该号码上继续可用，所以客户可能在同一分钟内既收到手机的回复，又收到机器人的回复。请在流程中决定收到回显事件时怎么做：多数团队会在一段时间内对该联系人暂停机器人，避免打断已经介入的人。 第二是时间。回复来信的机器人在 24 小时客户服务窗口内工作，窗口内允许发送自由文本。若流程在一天后才发送内容，例如跟进或提醒，就需要已批准的模板，在此发送自由文本会返回错误 131047。Botpress 的指南订阅了模板状态字段，正是为了这类主动消息。 另外，Coexistence 号码的吞吐量固定为每秒 20 条消息，远高于对话式机器人的发送量。 - 把您自己 Meta 应用的密钥填进 Client Secret。签名永远对不上，Botpress 会对每次投递返回 401。 - 选择 OAuth 或沙盒选项而不是 Manual Configuration。这些选项通过 Botpress 自己的应用连接号码，而不是使用已连接的号码。 - 忽略回显事件。如果没有针对手机回复的规则，机器人会盖过已经介入的真人。 **跳过签名检查安全吗？** 这会把保护转移到 URL 上。Botpress 为每个集成生成专属的 Webhook URL，所以请保密。媒体文件仍须凭令牌从 Meta 获取，伪造的事件做不到这一点。 **同一个号码还能同时供应 n8n 吗？** 一个号码只有一个 Webhook 目标。请把它指向其中一个系统，若还有系统需要这些事件，再由该系统转发。 **Botpress 需要我的 WABA ID 吗？** 其定义目前将它标为可选，并说明未来的主要版本会要求必填，所以请按连接中的信息填写。 **消息会经过 EasyCoexistence 吗？** 不会。Meta 直接投递到 Botpress 的 Webhook URL，内容从不存放在我们这一侧。 --- ## 用 Dify 应用回复 WhatsApp 消息 https://easycoexistence.com/zh-hans/integrations/dify 将号码的 Webhook 指向一个小型接收端，例如 n8n 工作流或您自己代码中的一个路由，由它把每条消息传给 Dify 的 Send Chat Message API，再通过 Cloud API 把答复发回。在 Dify 内，可以把 EasyCoexistence MCP 服务器添加为工具，让智能体直接操作该号码。 ### Meta 能直接把 WhatsApp 消息发给 Dify 吗？ 无法完成握手，所以不行。Meta 在投递任何内容之前，会先向目标地址发送 GET 请求，并期望响应正文原样返回 hub.challenge 的值。Dify 的 Webhook Trigger 每个触发器只接受一种 HTTP 方法，其文档说明非 JSON 的响应正文会被自动转换为 JSON，于是 OK 会变成一个消息对象返回。验证值永远无法原样回显，Meta 也就不会开始投递。 因此前面需要放一个小型接收端。n8n 的 Webhook 节点、Python 或 Node 中的一个路由，或者一个无服务器函数，负责应答 GET、接收 POST，并把文本交给 Dify。Webhook URL 中那段随机长密钥也在这里校验，因为 X-Hub-Signature-256 请求头是用 Tech Provider 的应用密钥签名的，客户无法自行验证。 ### 接收端如何与 Dify 应用通信？ 只需调用一次 Dify 的 Service API：POST /chat-messages，并使用该应用的 API 密钥进行认证。请求体包含 query（客户的文本）和 user（由您自定义的标识符）。请把发送者的 WhatsApp 号码用作 user，并保存 Dify 返回的 conversation_id，这样同一个人的下一条消息就会延续同一段对话。 response_mode 很关键。blocking 会在答案生成完毕后才返回，Dify 的文档提醒，在 Dify Cloud 上，较长的生成可能被边缘代理截断。Agent 应用只支持 streaming，向其发送 blocking 请求会返回 400 错误。更稳妥的做法是由接收端读取数据流，并在结束时只发送一条 WhatsApp 消息。 随后，答复会作为 Cloud API 文本消息发到同一号码。在客户消息开启的 24 小时窗口内发送，不收费。 ### MCP 服务器在 Dify 内能带来什么？ 让 Dify 智能体无需您逐个接线，就能直接操作该号码。Dify 通过 HTTP 连接 MCP 服务器，并默认通过 OAuth 动态客户端注册向服务器登记，而 EasyCoexistence MCP 服务器正支持这一方式。在“工具”下添加它并登录一次，智能体就能使用这些工具：列出号码、检查号码的连接状态、发送消息、发送已批准的模板、读取模板状态。 主动联系正适合放在这里：次日跟进的 Dify 工作流必须使用 send_template，因为窗口之外发送自由文本会返回错误 131047，工具说明中也已向模型写明这一点。 MCP 做不到的是在客户来信时唤醒 Dify。该协议是请求与响应模式，所以收到的消息仍然要经由 Webhook 和前面的接收端到达。 - 把 Dify Webhook Trigger 的 URL 用作 Webhook 目标地址。验证值会被包装成 JSON 返回，Meta 永远无法验证该端点。 - 向 Dify 的 Agent 应用发送 blocking 请求。Agent 应用只支持 streaming，调用会返回 400 错误。 - 每条消息都使用新的 user 值。Dify 按 user 划分对话，因此每条消息都会开启一段没有记忆的新对话。 **Dify 有 WhatsApp 渠道吗？** 其文档中没有。Dify 应用可通过 Service API 访问，因此 WhatsApp 需要借助调用该 API 的接收端来连接。 **可以用 n8n 作为接收端吗？** 可以。Webhook 节点负责接收，一个 HTTP Request 节点调用 Dify，另一个 HTTP Request 节点通过 Cloud API 发送答复。 **团队仍然可以用手机回复吗？** 可以。Coexistence 让 WhatsApp Business 应用继续在该号码上使用，从手机发出的回复会作为 echo 事件到达接收端。 **EasyCoexistence 能看到对话内容吗？** 不能。Meta 直接投递到您的接收端，我们不会存储消息内容。MCP 服务器只读取账户和号码的状态。 --- ## 用 Flowise Chatflow 回复 WhatsApp 消息 https://easycoexistence.com/zh-hans/integrations/flowise 将号码的 Webhook 目标设为一个小型接收器，例如 n8n 工作流或您自己代码中的一个路由。它把每条消息交给 Flowise 的 Prediction API，并以发送者的号码作为会话 ID，再用该号码的访问令牌和号码 ID，通过 Cloud API 把答复发回去。 ### 为什么 Flowise 前面需要一个接收器？ 因为 Meta 的 Webhook 与 Flowise 的 API 使用不同的数据结构。Meta 验证目标地址时会发送一个 GET 请求，必须把 hub.challenge 作为原始响应体返回，随后以嵌套的 JSON POST 投递每条消息。Flowise 的 Prediction API 则要求向 /api/v1/prediction/ 加上流程 ID 发送 POST 请求，并带有 question 字段。双方都不会迁就对方，所以需要接收器来转换。 接收器可以是 n8n 的 Webhook 节点、Python 或 Node 中的一个路由，或任何无服务器函数。它负责应答验证用的 GET 请求，检查放在 Webhook URL 中的一长串随机密钥，立即向 Meta 返回 200，然后再处理实际工作。URL 中的密钥是这里唯一可行的身份验证方式：Meta 使用 Tech Provider 应用的密钥为投递签名，而该密钥从不共享，因此您这一侧无法验证 X-Hub-Signature-256 请求头。 ### 接收器应如何调用 Prediction API？ 把客户的文本作为 question，把客户的 WhatsApp 号码作为会话。Flowise 在每次请求中都接受 overrideConfig，其中的 sessionId 能让记忆节点为每个人保留独立的对话，而不是把所有人混在同一个会话里。Webhook 负载中发送者的号码是稳定而自然的键。 如果 Chatflow 设有 API 密钥保护，接收器需要把它作为 Bearer 令牌发送。除非接收器能够拼接数据流，否则请把 streaming 设为 false，因为 WhatsApp 一次投递一条完整的消息，而不是逐个 token 显示。 答复会以 Cloud API 文本消息的形式，从同一号码发出。在客户消息开启的 24 小时窗口内，这是免费且允许的。流程之后想发送的任何内容，例如提醒，都必须使用已批准的消息模板。 ### Flowise 智能体可以使用 EasyCoexistence MCP 服务器吗？ 目前不行。Flowise 的 Custom MCP 通过 URL 和一组请求头连接 Streamable HTTP 服务器，通常使用保存在 Flowise 变量中的静态 Bearer 令牌。EasyCoexistence MCP 服务器采用 OAuth 验证，需要在浏览器中登录，并使用它自行签发的令牌，因此没有可以放进请求头的静态密钥。 可行的分工是：由流程决定，由接收器发送。流程返回要说的文本；如果客户已超过一天没有回复，则返回某个消息模板的名称。接收器再用该号码的访问令牌调用 Cloud API。这样访问令牌就不会存放在 Flowise 内部，而 24 小时规则由代码通过检查联系人最近一次发言的时间来执行，不必交给可能忘记它的模型。 无论发送采用哪种方式，收到的消息仍然只能通过 Webhook 到达。 - 遗漏 sessionId。所有客户会共用同一份记忆，一个人的资料可能出现在另一个人的答复中。 - 等 Flowise 处理完才答复 Meta。缓慢的 200 响应会被重试，同一条消息因此被处理两次。 - 让流程在一天后发送自由文本。窗口之外，Meta 会以错误代码 131047 拒绝。 **Flowise 有 WhatsApp 节点吗？** 文档中没有。它通过 Prediction API 接入，所以 Meta 与流程之间需要一个接收器。 **可以用 n8n 作为接收器吗？** 可以。用 Webhook 节点接收，用一个 HTTP Request 节点调用 Flowise，再用另一个 HTTP Request 节点通过 Cloud API 发送答复。 **有人从手机上回复时，如何让机器人停下？** 监听 echo 事件。从 WhatsApp Business 应用发出的回复会到达接收器，接收器即可为该联系人暂停流程。 **EasyCoexistence 会保存对话内容吗？** 不会。Meta 直接投递到您的接收器。Flowise 只保留其记忆节点被配置为保留的内容。 --- ## 给 LangChain 智能体配一个 WhatsApp 号码 https://easycoexistence.com/zh-hans/integrations/langchain LangChain 智能体接入 WhatsApp 分为两部分。收到的消息通过号码的 Webhook 送达您的 Web 路由，再由该路由调用智能体。要执行操作时，智能体可以通过 LangChain 的 MCPAdapter 并使用 OAuth 加载 EasyCoexistence MCP 工具，也可以用号码的访问令牌和 phone number id 直接调用 Cloud API。 ### LangChain 智能体如何加载 WhatsApp 工具？ 通过 MCPAdapter，即 LangChain 的 MCP 客户端。它会把 MCP 服务器的工具作为普通 LangChain 工具交给 create_agent。它要求 langchain[mcp] 版本为 1.4.0 或更高，目前标记为 beta。 身份验证交由 FastMCP 处理。在客户端传入 auth="oauth" 即可运行完整的 OAuth 2.1 流程：发现、动态客户端注册、浏览器重定向和令牌交换。EasyCoexistence MCP 服务器正是采用这种方式，因此无需创建或粘贴任何密钥。默认情况下，令牌保存在内存中，每次运行都要重复浏览器步骤；若使用带令牌存储的 FastMCP OAuth 提供方，则可在多次运行之间保留令牌。 加载完成后，智能体会看到这些工具及其说明：首先是 list_numbers，因为其他所有工具都需要从它获取 connection_id，然后是 send_message、send_template、list_templates、get_number_health 等。 ### 收到的 WhatsApp 消息如何送达智能体？ 通过 Webhook，因为 MCP 做不到。该协议是请求与响应模式，服务器无法在客户写来消息时唤醒客户端。 把号码的 Webhook 目的地设置为您自己应用中的一个路由，并在 URL 路径中加入一段较长的随机密钥。该路由用原始 challenge 响应 Meta 的验证 GET 请求，接收每个 POST，立即返回 200 并把任务放入队列。随后由工作进程从负载中取出发送者和文本，并以此调用智能体，同时把发送者的号码作为线程 id，让记忆按客户分开保存。 请校验 URL 中的密钥，而不是 X-Hub-Signature-256 标头。Meta 使用 Tech Provider 的应用密钥签名，而该密钥从不共享，因此客户无法验证这个标头。 ### 智能体应该通过 MCP 发送，还是通过 Cloud API 发送？ 两种方式都可行，区别在于规则由谁掌握。MCP 工具把 WhatsApp 规则写在说明里，例如 send_message 只能在 24 小时窗口内使用，而 send_template 用于联系尚未写来消息的人。模型读到这些说明后，大多数时候能选对工具，在智能体可自由决策的场景中，这一点很有帮助。 如果智能体的任务很窄，例如总是回复刚写来消息的那个人，那么自己写一个简单工具，用号码的访问令牌向 Cloud API 的 messages 端点发送，会更简单。这样窗口检查就放在您的代码里，而绝不能违反的规则本来就应该放在这里。窗口之外发送自由文本会返回错误 131047，客户什么也收不到。 - 指望 MCP 送达收到的消息。没有 Webhook 路由，智能体永远收不到客户的消息。 - 把 OAuth 令牌留在服务器内存中。每次重启都需要在浏览器重新登录，请用令牌存储保存它们。 - 所有客户共用一个线程。请以发送者的号码作为智能体记忆的键。 **只支持 Python 吗？** MCPAdapter 的示例是 Python。Webhook 和 Cloud API 都是普通 HTTP，因此 LangChain 支持的任何语言都能完成接收和发送。 **智能体每次都需要调用 list_numbers 吗？** 它需要 connection_id，而 list_numbers 是获取 connection_id 的唯一途径。只有一个号码时，智能体在开始时调用一次即可。 **团队仍然可以用手机回复吗？** 可以。Coexistence 让 WhatsApp Business 应用继续可用，手机上的回复会作为 echo 事件送达您的路由，智能体可以将其纳入考虑。 **EasyCoexistence 会读取对话内容吗？** 不会。Meta 直接把消息送达您的路由，我们这边从不存储消息内容。MCP 工具只读取账户和号码的状态。 --- ## 将 OpenAI Agents SDK 智能体接入 WhatsApp https://easycoexistence.com/zh-hans/integrations/openai-agents-sdk 将号码的 Webhook 目标设置为您的 Python 应用中的一个路由。每收到一条消息，就以发送者的号码作为会话键，用 Runner.run 运行智能体，然后用该号码的访问令牌和 phone number id，通过 Cloud API 把 result.final_output 发回去。WhatsApp Business 应用在同一号码上继续可用。 ### WhatsApp 消息如何变成一次智能体运行？ 通过您自己应用中的一个路由，由 Meta 来调用它。把号码的 Webhook 目标设置为该路由，并在路径中加入一段较长的随机密钥。该路由对 Meta 的验证 GET 请求，以纯文本返回 hub.challenge；对每个 POST 请求，立即响应 200 并把任务放入队列，因为 Meta 会重试响应过慢的请求，否则智能体会被运行两次。 随后由 worker 从负载中读取发送者和文本，并调用 Runner.run。传入一个会话，其 id 就是发送者的号码：SDK 会把对话存储在该 id 之下，所以同一位客户的下一条消息会接着上一条继续，而两位客户永远不会共用同一段历史。起步阶段用 SQLiteSession 就足够；若有多个 worker，SDK 也提供 Redis 和 SQLAlchemy 会话。 这里的验证靠的是 URL 中的密钥。Meta 使用 Tech Provider 的应用密钥对投递内容签名，因此客户无法验证签名标头。 ### 为什么应由您的代码而不是智能体来发送回复？ 因为必须绝不违反的那条规则是时间规则，而代码比提示词更能可靠地执行它。客户发来消息时，Meta 会开启一个 24 小时的客户服务窗口。窗口内可以发送自由文本；窗口外只能发送已批准的消息模板，自由文本会返回错误 131047。 回复刚刚收到的那条消息的 worker 始终处在窗口之内，所以把 result.final_output 作为文本发送，从结构上就是安全的。稍后才发生的工作，例如次日早上的跟进或提醒，应走另一条路径，发送消息模板，绝不发送自由文本。 智能体仍然可以使用工具。给它函数工具用于查询资料，例如订单或预约，而把 WhatsApp 的发送留在 worker 中。这样还能让访问令牌远离模型可以用任意参数调用的任何东西。 ### 智能体可以使用 EasyCoexistence MCP 服务器吗？ 可以，通过 MCPServerStreamableHttp，但设置比加一个标头要多一些。SDK 接受 Authorization 标头，或 params["auth"] 中的 httpx.Auth。EasyCoexistence MCP 服务器会在浏览器登录后签发自己的 OAuth 令牌，采用动态客户端注册和 PKCE，因此不存在静态密钥。MCP Python SDK 提供 OAuthClientProvider，这是一个 HTTP 验证处理器，负责执行该流程，包括 PKCE 和令牌刷新，把它放进 params["auth"] 即可。 当您希望智能体自行决策时，这样做是值得的：检查号码的连接状态、读取消息模板状态，或根据工具描述中的规则在 send_message 和 send_template 之间做选择。如果只是做一个只负责应答的前台，上面的 worker 方案更短，出错的地方也更少。 无论哪种方式，Webhook 都要保留。MCP 是请求与响应的模式，客户的消息只能通过 Meta 调用的那个路由到达智能体。 - 在向 Meta 返回 200 之前就运行智能体。响应过慢会被重试，客户会收到两次回答。 - 所有客户共用一个会话。请以发送者的号码作为键，否则历史会混在一起。 - 让延迟的跟进发送自由文本。超过 24 小时后会以 131047 失败，请改为发送消息模板。 **这需要 OpenAI Responses API 的托管 MCP 工具吗？** 不需要。worker 用 Runner.run 在本地运行智能体，WhatsApp 一侧只是您的代码发起的一次普通 HTTPS 调用。 **我应该使用哪个 Graph API 版本？** Meta 当前的示例使用 v25.0。请在代码中的一处固定版本号，这样升级只需改一行。 **可以由真人在手机上接管吗？** 可以。Coexistence 让 WhatsApp Business 应用保持可用，您在手机上的回复会以 echo 事件的形式到达您的路由，worker 可据此暂停智能体。 **EasyCoexistence 会存储对话吗？** 不会。Meta 直接投递到您的路由。会话所存储的内容都保存在您自己的数据库中。 --- ## 使用 Vercel AI SDK 构建 WhatsApp 智能体 https://easycoexistence.com/zh-hans/integrations/vercel-ai-sdk 传入的消息会送达设为该号码 Webhook 目标的路由处理器。处理器调用 generateText，并通过 Cloud API 发送答复。对于需要操作该号码的工具，来自 @ai-sdk/mcp 的 createMCPClient 通过 HTTP 连接 EasyCoexistence MCP 服务器，并借助 authProvider 以 OAuth 登录。 ### 路由处理器如何接收 WhatsApp 消息？ 在同一路由上实现两个方法，并将其设为该号码的 Webhook 目标，路径中带有一段较长的随机密钥。 GET 用于应答 Meta 的验证。从查询中读取 hub.mode、hub.verify_token 和 hub.challenge，比对令牌，然后以纯文本返回 challenge。通过 JSON 辅助函数返回是典型的错误：响应体会带上引号，Meta 就不会开始投递。 POST 用于接收事件。请尽快返回 200，之后再调用模型，因为 Meta 会重试响应较慢的请求，而在冷启动时同步运行模型，可能会对同一条消息回复两次。在响应发出后即结束函数的平台上，请把工作交给队列，或使用平台提供的响应后处理机制。 路径中的密钥就是身份验证。Meta 使用 Tech Provider 应用的密钥为每次投递签名，因此您这一侧无法校验 X-Hub-Signature-256 标头。 ### AI SDK 如何加载 WhatsApp 工具？ 使用来自 @ai-sdk/mcp 的 createMCPClient 和 HTTP 传输，AI SDK 文档推荐在生产环境中使用这种方式。该传输接受服务器 URL 和 authProvider，EasyCoexistence MCP 服务器正是通过 authProvider 的 OAuth 完成授权：它发布 OAuth 元数据，支持动态客户端注册和 PKCE，并在登录后签发自己的令牌。无需在标头中放置 API 密钥。 客户端的工具可直接传入 generateText 或 streamText。随后模型会看到 list_numbers、send_message、send_template、get_number_health 等工具，其描述中注明了 24 小时窗口。调用结束后请关闭客户端：流式调用在 onEnd 回调中关闭，其他情况在 finally 块中关闭，这也是 AI SDK 文档的要求。 适用于需要由模型自行决定的场景。若只是回复刚收到的消息，在处理器中直接调用 Cloud API 更简短。 ### 号码使用 Coexistence 后有什么变化？ 有两点代码需要知道。第一，可能已有真人在对话中。WhatsApp Business 应用在该号码上仍可使用，在手机上输入的每条回复都会以回显事件的形式送达路由。处理器在收到回显后，对该联系人暂停调用模型，就能避免模型盖过真人的回复。 第二，该号码的发送速率固定上限为每秒 20 条消息。对话型智能体远不会触及这个上限，但用 Promise.all 遍历联系人列表编写的群发循环会触及，所以请分批发送。 其余都是普通的 Cloud API。客户最后一条消息后的 24 小时内，允许发送自由文本。超过之后，只有已获批准的模板才能发出，自由文本会返回错误 131047，而客户不会看到任何内容。 - 用 JSON 响应辅助函数返回 challenge。外层的引号会导致 Meta 的验证失败。 - 在响应 Meta 之前就运行 generateText。冷启动时，重试会产生第二条答复。 - 忘记关闭 MCP 客户端。每个请求都会留下一个未关闭的连接，直到平台将其终止。 **这只能在 Vercel 上运行吗？** 不是。AI SDK 是 TypeScript 库，路由可以运行在任何提供 HTTPS、并能应答 GET 和 POST 的主机上。 **我一定要用 MCP 客户端吗？** 回复消息不需要。使用该号码的令牌向 Cloud API 的消息端点发起 fetch 即可。当由模型选择要做什么时，MCP 才体现价值。 **模型可以用哪家服务商？** AI SDK 支持的都可以。WhatsApp 这一侧与模型无关，所以更换服务商不会影响路由或 Cloud API 调用。 **EasyCoexistence 能看到这些消息吗？** 不能。Meta 直接投递到您的路由，消息内容绝不会存储在我们这边。 --- ## 从 Shopify 发送 WhatsApp 订单消息 https://easycoexistence.com/zh-hans/integrations/shopify 创建订单时，Shopify Flow 的 Send HTTP request 操作可以向 Cloud API 发送一条已获批准的模板，使用已连接号码的 phone number id，以及保存为 Flow 密钥的令牌。如果您的套餐没有该操作，可以让 Shopify 管理后台的 Webhook 把订单发到接收端（例如 n8n），由它发起同样的调用。 ### Shopify Flow 如何发送 WhatsApp 消息？ 使用 Send HTTP request 操作。它可以向任意 URL 发送请求，请求头和请求体中可以使用触发器提供的 Liquid 变量。 以订单创建为触发器建立工作流，然后添加 Send HTTP request。URL 是已连接号码的 phone number id 对应的 Cloud API 消息端点。添加一个 Authorization 请求头，值为 Bearer 加上该号码的访问令牌，令牌保存为 Flow 密钥，并以密钥变量的方式引用。密钥值不会显示在 Flow 界面中，也会在运行日志里被隐去，令牌正应该放在这里。请求体是一条模板消息，to 字段填客户的电话号码，订单详情作为模板的参数。 Flow 把 2XX 或 3XX 响应视为成功。Meta 对有效请求会返回消息 id，因此运行成功就意味着 Meta 已接受这条消息。 ### 为什么订单消息必须使用模板？ 因为是店铺先发起对话。Meta 的 24 小时客户服务窗口只有在客户给该号码发消息后才会打开。订单确认、发货更新或弃单提醒都发生在此之前，所以自由文本会被拒绝，只有预先获批的模板才能发出。 请先创建一次模板，类别选择用于订单和发货更新的 utility，并在获批后再启用工作流。请求体中的名称和语言必须与已获批的模板完全一致，参数数量也必须与占位符数量一致。 此外还有同意的问题。Meta 要求企业在通过 WhatsApp 向某人发送消息之前先获得 opt-in：对方提供了号码，并同意接收该企业的消息。通常的做法是在结账页加一个勾选框来收集同意，工作流在发送前应先检查它。 ### 如果店铺的套餐不包含 Send HTTP request 怎么办？ 改用 Shopify 管理后台的 Webhook。在“设置”、“通知”、“Webhook”下，商家可以针对订单创建等事件创建 Webhook，格式为 JSON，发送到指定 URL。把它指向一个接收端：可以是 n8n 的 Webhook 节点，也可以是用 PHP、Python 或 Node 写的路由。接收端读取订单、检查同意状态，然后向 Cloud API 发起同样的模板调用。 无论走哪条路径，回复的处理方式都一样。客户回复订单消息后，回复会进入店铺手机上的 WhatsApp Business 应用，因为该号码使用了 Coexistence，此时 24 小时窗口已经打开，可以发送自由文本。如果已设置该号码的 Webhook 目标，回复也会送达您的系统。订单消息本身同样会显示在应用中，回复客户的人可以看到客户是在回应什么。 - 在订单创建时发送自由文本。客户还没有发过消息，Meta 会拒绝，必须使用已获批的模板。 - 对 4XX 响应仍把错误处理设为 Retry。Flow 最多会在 24 小时内反复重试一个 Meta 永远不会接受的请求。 - 把令牌以明文放进请求头。请把它保存为 Flow 密钥，这样它不会出现在界面和日志中。 **模板消息的费用由谁支付？** Meta 直接向企业在其自己的 WhatsApp Business 账户上收取消息费用。EasyCoexistence 不会加价。 **团队还能用手机回复客户吗？** 可以。这正是 Coexistence 保留的功能：WhatsApp Business 应用可以继续使用店铺发送消息的同一个号码。 **这需要安装 Shopify 应用吗？** 不需要。Flow 的 Send HTTP request，或者发往接收端的管理后台 Webhook 就足够了。Cloud API 只是一次 HTTPS 调用。 **to 字段需要什么电话号码格式？** 国际格式，包含国家代码，只保留数字。发送前请先清理结账页的电话字段，因为客户可能会输入空格和符号。 --- ## 从 WooCommerce 发送 WhatsApp 订单更新 https://easycoexistence.com/zh-hans/integrations/woocommerce 为订单事件创建一个 WooCommerce Webhook，指向一个接收端，例如 n8n 工作流或一个小型 PHP 路由。接收端验证 WooCommerce 的签名，确认客户同意接收 WhatsApp 消息，然后使用已连接号码的号码 ID 和访问令牌，通过 Cloud API 发送已获批准的模板。 ### WooCommerce 订单如何触发 WhatsApp 消息？ 通过 WooCommerce Webhook 和一个接收端。在 WooCommerce 中依次进入“设置”“高级”“Webhook”，添加一个 Webhook，选择订单主题（如订单已创建或订单已更新），并填写投递 URL 和密钥。此后每当事件发生，WooCommerce 就会把订单以 JSON 形式发送到该 URL。 负载是固定的，因此无法直接指向 Cloud API。中间需要一个接收端：n8n 的 Webhook 节点、店铺自有 PHP 中的一个路由，或任何小型服务。它读取订单，取出客户的电话号码和消息所需的信息，然后向已连接号码的 Cloud API 消息端点发出一次 HTTPS 请求，并以该号码的访问令牌作为 Bearer 凭证。 order.updated 主题并不对应某一个状态，因此接收端应读取订单的 status 字段，并在每次出现它关心的状态转换时只发送一次。WooCommerce 默认通过 wp-cron 在后台投递，所以消息可能比订单晚一小段时间到达。 ### 接收端如何确认请求来自店铺？ 靠 WooCommerce 的签名。每次投递都带有 X-WC-Webhook-Signature 请求头，其值是用您在 Webhook 上设置的密钥，对原始负载计算出的 HMAC-SHA256，并经 base64 编码。接收端对收到的请求体计算同样的哈希并比对，不匹配的一律拒绝。 这是店铺自己的密钥，因此与 Meta 对传入 WhatsApp 消息的签名不同，它可以被验证。请以恒定时间比较，并且要在任何框架解析之前对原始请求体做哈希，因为重新编码的 JSON 会产生不同的哈希。 请尽快返回 2xx。WooCommerce 会把不是 2xx、301 或 302 的任何响应记为失败，连续失败超过五次后就会停用该 Webhook。接收端因部署而停机，或因等待 Meta 响应而过慢，都可能在无人察觉的情况下让店铺的消息停发。 ### 店铺可以发送什么，何时发送？ 只要是店铺先发起，就必须使用已获批准的模板。Meta 的 24 小时客户服务窗口只会在客户给该号码发消息时开启，所以订单确认或发货更新属于商家发起，自由文本会被拒绝。请为每种更新创建一个 Utility 类模板，等待批准，然后按名称和语言发送，并把订单号等详细信息作为参数。 Meta 还要求取得同意：客户提供了号码，并同意通过 WhatsApp 接收该商家的消息。在结账时勾选并记录于订单的复选框是最简单的凭证，接收端应在发送前检查它。 客户一旦回复，对话就是普通的 Coexistence。回复会出现在店铺手机的 WhatsApp Business 应用中，窗口对自由文本开放，团队照常在应用中回复。 - 先调用 Cloud API，再响应 WooCommerce。发送缓慢或失败都会计入该 Webhook 的失败次数，超过五次就会被停用。 - 对解析后的 JSON 做哈希，而不是对原始请求体做哈希。签名永远对不上，每一次真实的投递都会被拒绝。 - 每次收到 order.updated 投递都发送。该主题并不对应某一个状态，如果不记录哪次状态转换已发过消息，客户就会收到重复的消息。 **我需要为此安装 WordPress 插件吗？** 不需要。WooCommerce 内置的 Webhook 加一个接收端就够了，接收端可以是同一个 PHP 应用中的一个路由。 **订单消息的费用由谁支付？** Meta 直接向商家在其自己的 WhatsApp Business 账户上收取消息费用，EasyCoexistence 绝不加价。 **团队还能继续使用手机吗？** 可以。Coexistence 让 WhatsApp Business 应用在店铺的号码上继续工作，店铺发送的模板也会显示在对话中。 **如果 Webhook 被停用了怎么办？** 先修复接收端，然后在 WooCommerce 中把该 Webhook 的状态改回“启用”。它停用期间创建的订单不会触发消息。 --- ## 用 PHP 和 Laravel 收发 WhatsApp 消息 https://easycoexistence.com/zh-hans/integrations/php-laravel 接收消息靠一个 Laravel 路由：它应答 Meta 的验证 GET 请求并接受 POST 请求，参数要读作 hub_mode、hub_verify_token 和 hub_challenge，因为 PHP 会把点号转成下划线。发送则是向 Cloud API 的 messages 端点发一次 Http::withToken() POST 请求，带上该号码的 phone number id 和访问令牌。无需 SDK。 ### 如何在 Laravel 中接收 WhatsApp 消息？ 在 routes/api.php 中为同一路径定义一个 GET 和一个 POST。如果该文件不存在，请先运行 php artisan install:api。API 路由是无状态的，且不在 web 组内，所以 Meta 的 POST 请求不会因缺少 CSRF 令牌而被拒绝，而放在 routes/web.php 中的路由就会出现这种情况。 GET 用于应答 Meta 的验证。Meta 发送 hub.mode、hub.verify_token 和 hub.challenge，但 PHP 会把传入变量名中的点号改写成下划线，所以 Laravel 看到的是 hub_mode、hub_verify_token 和 hub_challenge。如果代码读取带点号的名称，得到的只会是 null，验证永远无法通过。请以纯文本返回 challenge，不要使用 response()->json()。 POST 把负载交给队列任务处理，并立即返回 200。请在路径中放入一个足够长的随机密钥，并在两个路由上都校验它：Meta 使用 Tech Provider 的应用密钥对推送签名，因此您这边无法验证签名头。 ### 如何从 Laravel 发送 WhatsApp 消息？ 使用 Laravel 的 HTTP 客户端：向该 phone number id 对应的 messages 端点发一次 POST 请求，并把访问令牌作为 Bearer 令牌。这两个值都来自该连接，可在控制台中查看，也可通过 get_api_credentials 获取，应放在 config/services.php 中并由环境变量提供，而不是写进代码。 请求体的形式取决于时间。在客户最后一条消息后的 24 小时内，可以使用 text 对象，如下所示。超出这个窗口，Meta 只接受指明已批准消息模板及其语言的 template 对象，发送自由文本会失败并返回错误 131047。要排查问题就看响应：失败的调用会返回一个 error 对象，其中的 code 说明了出错原因，请记录下来，不要丢弃。 请求中没有任何内容是 EasyCoexistence 特有的。它就是 Meta 官方文档中的那个调用，因此任何 PHP HTTP 客户端，无论是 Guzzle 还是原生 cURL，用法都一样。 ### 除此之外，生产环境的 Laravel 处理程序还需要什么？ 需要真正的队列、去重和窗口检查。 队列之所以重要，是因为 Meta 会重试响应过慢的请求。只有当队列连接是真实的连接且有 worker 在运行时，HandleWhatsAppEvent::dispatch() 才会很快返回。使用 sync 驱动时，任务会在请求内部运行，一次缓慢的模型调用或数据库写入就会变成重复推送。 请按消息 id 去重，也就是每条消息中的 wamid，因为重试是常态，而不是例外。为该列建立唯一索引，或使用以它为键的缓存锁，就足够了。 还要记录每位联系人最后一次发来消息的时间。有了这个时间戳，发送流程就能自行选择 text 还是 template，而不必等客户已经在等待时才从错误 131047 得知。在手机上的 WhatsApp Business 应用中输入的回复，会以 echo 事件的形式到达同一个路由，因此处理程序也能看出何时有人接管了对话。 - 读取 hub.challenge 时带了点号。PHP 已将其改名为 hub_challenge，处理程序因此返回空响应体，Meta 永远无法完成验证。 - 把 Webhook 放在 routes/web.php 中。Meta 的 POST 请求没有 CSRF 令牌，会被以 419 拒绝。 - 把任务派发到 sync 队列。任务在返回 200 之前就运行了，处理缓慢会触发重试，消息因此被处理两次。 - 用 response()->json() 返回 challenge。值两侧的引号会导致 Meta 的检查失败。 **有 PHP SDK 吗？** 我们没有提供，也无需 SDK。该 API 由 Meta 提供并由 Meta 撰写文档，Laravel 的 HTTP 客户端或 Guzzle 可以直接调用。 **不用 Laravel 也行吗？** 可以。在原生 PHP 中读取 $_GET['hub_challenge']，以 text/plain 输出，并用 cURL 发送。下划线规则适用于所有 PHP 框架。 **为什么 URL 的路径中需要一个密钥？** 因为这是唯一行之有效的身份验证。Meta 的签名使用 Tech Provider 的应用密钥，该密钥绝不会共享，所以 URL 中的密钥才能防止陌生人发送伪造事件。 **团队还能继续使用手机吗？** 可以。Coexistence 让 WhatsApp Business 应用继续在该号码上使用，从手机发出的消息会以 echo 事件的形式到达您的路由。 --- ## 巴西的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-brazil Coexistence 在巴西可用：Meta 面向 WhatsApp Business 应用用户的接入文档没有设置地域限制。发送到 +55 号码的消息按 Meta 的巴西费率表计费。自 2026 年 10 月 1 日起，每条营销模板收费 USD 0.0625，每条实用或验证模板收费 USD 0.0068，同时公布了 BRL 费率。 ### WhatsApp Coexistence 在巴西可用吗？ 可用。Meta 目前关于接入 WhatsApp Business 应用用户的文档列出了号码必须满足的条件，其中没有任何一条涉及国家。巴西号码与其他号码适用相同条件：号码已在 WhatsApp Business 应用上使用，应用版本为 2.24.17 或更新，并且通过 Tech Provider 或 Solution Partner 使用 Embedded Signup 完成接入。 连接成功后，手机上的应用照常使用，同一个 +55 号码还能获得 Cloud API 访问权限。为了与应用保持兼容，Meta 将这类号码的吞吐量固定为每秒 20 条消息。 ### Meta 在巴西每条消息收费多少？ Meta 按已送达的消息收费，依据消息类别和收件人的国家或地区电话区号。巴西（+55）在费率表上是单独列出的市场，因此发送到巴西号码的消息按巴西自己的费率计费，而不是区域平均价。以下是自 2026 年 10 月 1 日起生效的标准费率，来自 Meta 的 USD 和 BRL 费率表。实用和验证类费率还可能随每月用量分级进一步下降，Meta 按市场和类别分别应用这些分级。 ### 哪些消息仍然免费？ 有三类消息不收费。第一，在手机上的 WhatsApp Business 应用中输入的消息，接入后仍然免费，因为 Meta 只对通过 API 发送的内容适用 Cloud API 定价。第二，每个企业电话号码每月有 1,000 条免费服务消息，即在 24 小时客户服务窗口内发送的非模板回复。第三，客户通过 Click to WhatsApp 广告进入时开启的免费入口窗口内发送的所有消息，最长 7 天免费。 2026 年 10 月 1 日起有两项变化：每月前 1,000 条之后的服务消息开始收费，在客户服务窗口内发送的实用模板也开始收费。 ### Meta 会以雷亚尔向巴西企业开具账单吗？ 现在会了。Meta 自 2026 年 7 月 1 日起对巴西实行账单本地化。在 Billing Hub 中 Sold-To 国家为巴西的 Solution Provider 和直接集成的企业，可以创建以 BRL 计价的 Messaging 账户，这些账户的费用由 Meta 的本地实体 Facebook Brasil 以 BRL 开具发票。 这项变更有截止日期。符合条件的客户必须在 2027 年 6 月 30 日前，将其业务组合中的所有 Messaging 账户迁移到 BRL，因为自 2027 年 7 月 1 日起，Meta 将停止送达其非 BRL 账户发出的消息。Meta 提供 Currency Migration API 用于迁移，因为账户创建时选定的币种在其他情况下无法更改。 1. Check the number: Confirm the +55 number is on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Set up billing: Add a payment method in Billing Hub, in BRL if your Sold-To country is Brazil. 3. Run Embedded Signup: Log in with Facebook, choose the portfolio and the number, and confirm the connection in the app. - Sold-To 国家为巴西时，在 2027 年 6 月 30 日之后仍保留 USD 的 Messaging 账户。自 2027 年 7 月 1 日起，Meta 将停止送达该账户发出的消息。 - 把所有回复都当作免费。自 2026 年 10 月 1 日起，每个号码每月超过 1,000 条的服务消息要收费。 - 按企业所在地做预算。Meta 按收件人的电话区号定价，因此发送到葡萄牙号码的消息按 Rest of Western Europe 费率计费。 **使用 Coexistence 需要巴西公司吗？** 不需要。Meta 的要求针对的是号码和应用，而不是公司的注册地。公司所在地只影响由哪个币种和哪个 Meta 实体向您开具账单。 **BRL 费率与 USD 费率相同吗？** Meta 为每种币种分别发布费率表。巴西 2026 年 10 月 1 日的费率表列出：营销为 BRL 0.3217，实用和验证为 BRL 0.035。 **我从手机上发送的消息要付费吗？** 不用。Meta 的文档说明，通过 WhatsApp Business 应用发送的消息在接入后仍然免费。只有通过 API 发送的消息才适用 Cloud API 定价。 **如果我的账户没有付款方式会怎样？** 在 1,000 条免费额度内，Meta 仍会送达服务消息，但额度用完后就会停止送达。发送任何 Meta 收费的消息之前，请先在 Billing Hub 中添加付款方式。 --- ## 墨西哥的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-mexico Coexistence 在墨西哥可用，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有设置地域限制。发送至 +52 号码的消息按 Meta 的墨西哥费率表计价：自 2026 年 10 月 1 日起，每条营销模板 USD 0.0397，每条实用或验证模板 USD 0.0085；比索费率表则为 MXN 0.7298 和 MXN 0.1565。 ### 墨西哥的企业可以使用 WhatsApp Coexistence 吗？ 可以。Meta 接入 WhatsApp Business 应用用户的文档所列的要求只涉及号码和应用，与国家无关：号码已在 WhatsApp Business 应用中启用，应用版本为 2.24.17 或更高，并由 Tech Provider 或 Solution Partner 通过 Embedded Signup 完成连接。 满足这些条件的 +52 号码可以继续在手机上的应用中使用，同时在同一号码上获得 Cloud API 访问权限。Meta 将这类共享号码的 API 吞吐量上限设为每秒 20 条消息。 ### Meta 在墨西哥每条消息收费多少？ Meta 按已送达的消息收费，费率取决于两点：消息类别，以及收件人的国家区号。墨西哥（+52）在费率表中有单独一行。以下为 2026 年 10 月 1 日起生效的标准费率，这一天 Meta 也上调了墨西哥的营销费率。每月消息量更高时，可通过 Meta 的阶梯用量折扣获得更低的实用和验证费率。 ### 哪些消息不收费？ 在手机上的 WhatsApp Business 应用中直接输入发送的消息。Meta 的文档说明，号码接入后这类消息仍然免费。只有通过 Cloud API 发送的消息才按 Cloud API 的价格计费。 在 API 方面，每个商业号码每月有 1,000 条免费服务消息，即在 24 小时客户服务窗口内发送的非模板回复，额度每月重置，不会累计到下月。客户通过 Click to WhatsApp 广告进入后，会开启最长 7 天的免费入口窗口，期间 Meta 对营销、实用、验证和服务消息均不收费。 ### Meta 可以用比索向墨西哥账户计费吗？ 可以。MXN 是 Meta 在 WhatsApp Business Platform 上开放的 16 种货币之一，于 2026 年 1 月 1 日推出，Meta 也同步发布了完整的 MXN 费率表和 USD 费率表。 货币在创建消息账户时选定，之后不能直接切换。Meta 提供 Currency Migration API，用于日后迁移到其他货币。与巴西和印度不同，Meta 的定价页面没有说明墨西哥必须迁移到本地计费，因此选择 MXN 还是 USD 由企业自行决定。 1. Check the number: Make sure the +52 number runs the WhatsApp Business app, version 2.24.17 or newer, and is not attached to another provider. 2. Pick the currency: Choose MXN or USD when the account is created, and add a payment method in Billing Hub. 3. Connect: Run Embedded Signup, select the portfolio and the number, and confirm the connection from the app. - 本想用比索计费却以 USD 创建了账户。货币在创建时即已固定，更改需要使用 Meta 的 Currency Migration API。 - 沿用 2026 年 10 月 1 日之前的费率数字。Meta 在这一天上调了墨西哥的营销费率。 - 以为回复一定免费。每个号码每月超过 1,000 条服务消息后，Meta 会收费。 **+52 1 开头的手机号码会被区别对待吗？** Meta 将整个 +52 区号对应墨西哥市场，因此每位墨西哥收件人都按该消息类别的墨西哥费率计费。 **墨西哥的费率最近有变化吗？** 有。Meta 在 2026 年 10 月 1 日的更新中上调了墨西哥的营销费率。实用和验证费率不在这次调整之列。 **给美国客户发消息的费用相同吗？** 不同。美国号码属于 Meta 的北美区域，该区域有自己的费率。价格由收件人的国家区号决定。 **连接 API 后我会失去应用吗？** 不会。号码仍留在 WhatsApp Business 应用上，手机照常收发消息。 --- ## WhatsApp Coexistence 在哥伦比亚：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-colombia Coexistence 在哥伦比亚可用：Meta 针对 WhatsApp Business 应用用户的接入文档没有任何国家限制。发送至 +57 号码的消息适用 Meta 的哥伦比亚费率表。自 2026 年 10 月 1 日起，每条营销模板为 USD 0.0125，每条实用或验证模板为 USD 0.0008；按比索费率表计价则分别为 COP 46.0227 和 COP 2.9455。 ### WhatsApp Coexistence 适用于哥伦比亚号码吗？ 适用。Meta 针对 WhatsApp Business 应用用户接入的文档列出了号码必须满足的条件，其中没有任何一项与地域有关。+57 号码只要已在 WhatsApp Business 应用上使用，应用版本为 2.24.17 或更高，并通过 Tech Provider 或 Solution Partner 运行的 Embedded Signup 完成接入，即符合条件。 接入后，手机上的应用和所有聊天照常使用，同一号码同时通过 Cloud API 应答。共享号码在 API 一侧的吞吐量固定为每秒 20 条消息。 ### Meta 对哥伦比亚的单条消息费率是多少？ Meta 按消息类别和收件人的国家拨号代码，为每条已送达的消息定价。哥伦比亚（+57）是单独列出的市场。在 2026 年 10 月 1 日的费率表上，它的营销和实用费率是 Meta 所列拉丁美洲市场中最低的，包括拉丁美洲其他地区。下文数字为标价费率；月发送量很高时，实用和验证费率还可通过阶梯定价进一步降低。 ### 在哥伦比亚，哪些消息是免费的？ 与其他地方相同，因为 Meta 的免费情形适用于全球，而不是按市场划分。 号码连接后，从手机上的 WhatsApp Business 应用发送的消息仍然免费；Cloud API 的定价只适用于通过 API 发送的消息。每个企业电话号码每月有 1,000 条免费的服务消息，用于在 24 小时客户服务窗口内发送非模板回复。由 Click to WhatsApp 广告发起的对话会开启最长 7 天的免费入口窗口，除 Meta Business Agent 消息外，任何类别均不收费。 自 2026 年 10 月 1 日起，在已开启的客户服务窗口内发送的实用模板需要收费。 ### 哥伦比亚企业可以用比索向 Meta 付款吗？ 可以。COP 是 Meta 在 2026 年新增的货币之一，自 2026 年 4 月 1 日起提供，并有单独发布的费率表。Meta 的 COP 费率表以比索为所有市场计价，因此哥伦比亚企业向墨西哥或西班牙的客户发送消息时，这些费用同样以 COP 显示。 货币在创建消息账户时确定，之后不能更改。日后如需变更，须使用 Meta 的 Currency Migration API。Meta 的定价页面只说明了巴西和印度的强制本地结算迁移，因此对哥伦比亚而言，COP 是可选项，而不是要求。 1. Check the number: The +57 number must be on the WhatsApp Business app, version 2.24.17 or newer, and free of any other provider. 2. Choose COP or USD: Pick the currency at account creation and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm in the app. - 把哥伦比亚的费率套用于所有客户。发送至秘鲁或智利号码的消息按该市场的费率计费，在 2026 年 10 月的费率表上高出数倍。 - 随意选择结算货币。账户创建后，更改货币需要使用 Meta 的 Currency Migration API。 - 账户未设置付款方式。当月 1,000 条免费服务消息用完后，服务消息将无法送达。 **为什么哥伦比亚的费率比邻国低这么多？** Meta 按市场定价，也不解释个别数字。2026 年 10 月 1 日的费率表只是把哥伦比亚列得比其他拉丁美洲市场更低。 **验证消息的定价与实用消息不同吗？** 哥伦比亚没有区别。在 2026 年 10 月 1 日的费率表上两者均为 USD 0.0008，也不适用国际验证费率。 **客户发给我的消息，我需要付费吗？** 不需要。Meta 不对用户发给企业的消息收费，只对企业发送并送达的消息收费。 **应用会保留我的聊天记录吗？** 会。号码连接到 API 后，手机上的 WhatsApp Business 应用仍可继续使用，聊天记录也都保留。 --- ## 阿根廷的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-argentina Coexistence 在阿根廷可用，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有设定任何地域限制。发送到 +54 号码的消息按阿根廷自己的费率计费：自 2026 年 10 月 1 日起，每条营销类消息模板为 USD 0.0618，每条实用类或身份验证类消息模板为 USD 0.026；在 Meta 的比索费率表上则分别为 ARS 89.562 和 ARS 37.6798。 ### 阿根廷号码可以使用 Coexistence 吗？ 可以。Meta 面向 WhatsApp Business 应用用户的接入文档中，没有任何内容取决于国家。Meta 检查的是号码和应用：该 +54 号码已在 WhatsApp Business 应用上使用，应用版本为 2.24.17 或更新，并由 Tech Provider 或 Solution Partner 通过 Embedded Signup 完成连接。 结果是同一个号码有两种用法。员工继续在手机上回复，软件则通过 Cloud API 收发消息；当号码与应用共用时，Meta 将其限制为每秒 20 条消息。 ### Meta 对阿根廷的每条消息收费多少？ 每条已送达的消息按类别计费，费率取决于收件人区号所属的市场。阿根廷（+54）在 Meta 的费率表上是独立市场。以下是自 2026 年 10 月 1 日起生效的标准费率，取自 Meta 的 USD 和 ARS 费率表。对于实用类和身份验证类消息，当业务组合每月向阿根廷发送足够多的消息后，Meta 的月度用量阶梯会降低费率。 ### 阿根廷企业可以免费发送什么？ 在手机上输入的回复不收费：Meta 的文档说明，通过 WhatsApp Business 应用发送的消息在接入后仍然免费，只有通过 API 发送的消息才按 Cloud API 定价。 通过 API 发送时，每个企业电话号码每月有 1,000 条免费服务消息额度，指的是 24 小时客户服务窗口内的非模板回复。额度每月重置，未用完的消息不会结转。通过 Click to WhatsApp 广告联系您的客户，会开启最长 7 天的免费入口窗口，期间营销类、实用类、身份验证类和服务消息均不收费。 ### Meta 可以用比索向阿根廷账户收费吗？ ARS 于 2026 年 4 月 1 日成为 WhatsApp Business Platform 的可用币种，Meta 在 USD 费率表旁公布了完整的 ARS 费率表。比索费率表以 ARS 列出所有市场的费率，而不仅限于阿根廷。 币种在创建消息账户时确定，之后不能随意切换；Meta 为此提供了 Currency Migration API。Meta 的定价页面只对巴西和印度描述了强制本地计费，因此在阿根廷，选择 ARS 还是 USD 由企业自行决定。 1. Check the number: The +54 number must run the WhatsApp Business app at version 2.24.17 or newer and not be connected to another provider. 2. Set the currency and payment: Choose ARS or USD when the account is created and add a payment method in Billing Hub. 3. Connect the number: Complete Embedded Signup with the portfolio and number, then confirm the link in the app. - 误以为适用拉丁美洲的区域统一费率。阿根廷在 Meta 的费率表上有单独一行，数字与拉丁美洲其他地区不同。 - 把实用类消息模板当作回复发送，并以为免费。自 2026 年 10 月 1 日起，Meta 对客户服务窗口内的实用类消息模板收费。 - 阅读费率表时不看日期。Meta 公布的费率表带有生效日期，这里的数字是 2026 年 10 月 1 日的版本。 **Meta 会对客户发给我的消息收费吗？** 不会。Meta 只对企业送达给用户的消息收费，从不对用户发给企业的消息收费。 **ARS 的数字会随汇率变动吗？** Meta 为每种币种公布带生效日期的费率表，并按自己的日程更新费率。请查看当前的 ARS 费率表，不要自行换算 USD 费率表。 **阿根廷的身份验证费率与实用类相同吗？** 相同。在 2026 年 10 月 1 日的费率表上两者都是 USD 0.026，Meta 没有为阿根廷列出国际身份验证费率。 **连接之后我还能继续使用应用吗？** 可以。WhatsApp Business 应用仍可在手机上正常使用，同一个号码还能获得 API 访问权限。 --- ## 智利的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-chile Coexistence 适用于智利：Meta 面向 WhatsApp Business 应用用户的接入文档没有设置任何地域条件。发送到 +56 号码的消息按 Meta 的智利费率表计费，自 2026 年 10 月 1 日起，每条营销模板收费 USD 0.0889，每条实用或验证模板收费 USD 0.02；在比索费率表上则分别为 CLP 78.4917 和 CLP 17.6584。 ### 智利企业可以使用 WhatsApp Coexistence 吗？ 可以。Meta 关于接入 WhatsApp Business 应用用户的文档列出了对号码、应用和合作伙伴的条件，没有任何关于国家的条件。+56 号码只要正在 WhatsApp Business 应用上使用，应用版本为 2.24.17 或更高，并由 Tech Provider 或 Solution Partner 通过 Embedded Signup 完成连接，即符合资格。 手机照常使用，聊天记录保留，号码同时获得 Cloud API 访问权限，速率固定为每秒 20 条消息，这是 Meta 对与应用共用的号码设定的上限。 ### Meta 在智利每条消息收费多少？ Meta 按已送达的消息、分类别、依收件人所在市场的费率收费。智利（+56）是单独列出的市场，其在 2026 年 10 月 1 日费率表上的营销费率是所有拉丁美洲条目中最高的，甚至高于“拉丁美洲其他地区”。实用和验证类别为 USD 0.02，对于向智利大量发送消息的组合，Meta 的月度用量阶梯可以降低这两类费率。 ### 智利的哪些消息 Meta 不收费？ 从 WhatsApp Business 应用本身发送的任何消息。Meta 的文档说明，接入之后应用消息仍然免费，只有通过 Cloud API 发送的消息才计费。 在 API 上，Meta 对每个企业电话号码每月前 1,000 条服务消息不收费，也就是在 24 小时客户服务窗口内发送的非模板回复。此外，由 Click to WhatsApp 广告发起的对话会开启最长 7 天的免费入口窗口，期间除 Meta Business Agent 消息外，其他类别均不收费。 鉴于智利的营销费率，免费入口窗口是在当地发送促销消息成本最低的途径。 ### Meta 提供智利比索计费吗？ 提供，可自行选择。CLP 于 2026 年 4 月 1 日启用，是 Meta 当年新增的货币之一，Meta 还发布了涵盖所有市场的 CLP 费率表，因此发往海外客户的消息也会以比索显示。 计费货币在创建 Messaging 账户时选定，之后不可更改，除非企业使用 Meta 的 Currency Migration API。Meta 的定价页面只说明巴西和印度必须使用当地货币计费；智利企业可自行选择 CLP 或 USD。 1. Check the number: The +56 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not connected to another provider. 2. Choose CLP or USD: Set the currency at account creation and add a payment method in Billing Hub. 3. Connect: Run Embedded Signup, pick the portfolio and the number, and confirm from the app. - 每次跟进都默认使用营销模板。在智利，这意味着每条 USD 0.0889，而分类正确的实用模板只需 USD 0.02。 - 以为服务消息额度可以累积。每月 1,000 条免费服务消息会重置，未用完的不会结转。 - 用“拉丁美洲其他地区”的数字为智利的营销活动估价。智利是单独列出的市场，有自己的费率。 **智利的营销费率比阿根廷低吗？** 不低。按 2026 年 10 月 1 日的费率表，智利的营销费率为 USD 0.0889，阿根廷为 USD 0.0618。 **Meta 可以重新归类我的模板吗？** 可以。Meta 会审核模板类别，并可能更改模板的类别，这会改变该模板的收费费率。 **收到的消息要收费吗？** 不收费。Meta 只对企业送达的消息收费，不对客户发送的消息收费。 **号码在应用中还能继续使用吗？** 可以。号码连接到 API 之后，WhatsApp Business 应用在手机上仍然保持启用。 --- ## 秘鲁的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-peru Coexistence 在秘鲁可用，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有任何国家限制。发送到 +51 号码的消息按秘鲁费率表计费：自 2026 年 10 月 1 日起，每条营销模板 USD 0.0703，每条实用或身份验证模板 USD 0.03；按 Meta 的 PEN 费率表则分别为 PEN 0.2339 和 PEN 0.0998。 ### WhatsApp Coexistence 在秘鲁可用吗？ 可用。Meta 面向 WhatsApp Business 应用用户的接入文档，要求针对的是号码和应用，而不是国家。+51 号码只要满足以下条件即可：号码已在 WhatsApp Business 应用上启用，应用版本为 2.24.17 或更新，并通过 Tech Provider 或 Solution Partner 的 Embedded Signup 完成接入。 连接之后，手机仍可正常收发消息，同一号码也可通过 Cloud API 使用。Meta 将与应用共用的号码的 API 吞吐量固定为每秒 20 条消息。 ### Meta 在秘鲁每条消息收费多少？ Meta 按已送达的消息计费，价格取决于消息类别和收件人拨号代码所属的市场。秘鲁（+51）有单独的一行费率。2026 年 10 月 1 日，Meta 上调了秘鲁的实用和身份验证费率，现为 USD 0.03，是费率表上拉丁美洲市场中最高的实用费率。以上为标准费率；月发送量很大时，阶梯定价可降低实用和身份验证的费用。 ### 秘鲁企业有哪些消息免费？ 在手机上通过 WhatsApp Business 应用发送的消息。Meta 的文档说明，这些消息在接入后仍然免费，只有通过 Cloud API 发送的消息才会计费。 通过 API 发送时，Meta 为每个企业号码每月提供 1,000 条免费服务消息，即在 24 小时客户服务窗口开启期间发送的非模板回复，每月重置。客户通过 Click to WhatsApp 广告进入时，会开启最长 7 天的免费入口窗口，期间 Meta 对营销、实用、身份验证或服务消息均不收费。 自 2026 年 10 月 1 日起，在客户服务窗口内发送的实用模板也开始计费。 ### Meta 可以用索尔向秘鲁账户计费吗？ 可以。PEN 于 2026 年 4 月 1 日上线，属于 Meta 当年新增的币种之一，Meta 还发布了涵盖其所有定价市场的 PEN 费率表。 币种在创建消息账户时选定，此后不能更改，除非通过 Meta 的 Currency Migration API。Meta 的定价页面只说明巴西和印度必须迁移到本地计费，因此秘鲁企业可以自行在 PEN 和 USD 之间选择。 1. Check the number: Confirm the +51 number is on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Choose PEN or USD: Pick the currency when the account is created and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm the connection in the app. - 仍按 2026 年 10 月 1 日之前的数字来预算实用消息。Meta 已在该日期上调了秘鲁的实用和身份验证费率。 - 依赖实用模板来回复客户。在窗口开启期间，免费的服务消息可以完成同样的工作，每个号码每月最多 1,000 条。 - 以为邻近市场的价格相同。同一费率表上，哥伦比亚的实用费率是 USD 0.0008。 **为什么我的实用消息成本在 2026 年 10 月上涨了？** Meta 于 2026 年 10 月 1 日上调了秘鲁的实用和身份验证费率，并从同一天起对在客户服务窗口内发送的实用模板收费。 **客户发给我的消息，Meta 会收费吗？** 不会。只有企业发送并送达的消息才会计费。 **秘鲁有国际身份验证费率吗？** 没有。2026 年 10 月 1 日的费率表没有列出秘鲁的该项费率，因此身份验证按 USD 0.03 计费。 **手机上的应用还能继续使用吗？** 可以。号码连接到 API 之后，WhatsApp Business 应用仍会在手机上继续运行。 --- ## 哥斯达黎加的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-costa-rica Coexistence 在哥斯达黎加可用，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有设置任何地域限制。哥斯达黎加在 Meta 费率表上没有单独一行：+506 号码按拉丁美洲其他地区的费率计费，自 2026 年 10 月 1 日起，每条营销消息模板为 USD 0.074，每条实用类或验证类消息模板为 USD 0.0113。 ### 哥斯达黎加的号码可以使用 WhatsApp Coexistence 吗？ 可以。Meta 面向 WhatsApp Business 应用用户的接入文档对号码和应用设有条件，对国家没有任何限制。+506 号码只要已在 WhatsApp Business 应用上使用，应用版本为 2.24.17 或更新，并由 Tech Provider 或 Solution Partner 通过 Embedded Signup 完成连接，就符合条件。 手机仍可照常使用，原有聊天记录保留，号码同时获得 Cloud API 访问权限。对于应用与 API 共用的号码，Meta 将吞吐量固定为每秒 20 条消息。 ### 为什么哥斯达黎加按拉丁美洲其他地区计费？ Meta 的费率表列出了 39 个单独的国家，其余国家归入 8 个区域。哥斯达黎加（+506）是拉丁美洲其他地区中 15 个市场之一，同一区域还有巴拿马、危地马拉、厄瓜多尔和乌拉圭等国家。发送到这些市场任一号码的消息，都按该区域的费率计费。 该区域对实用类和验证类的用量阶梯也有影响。阶梯按市场和类别分别计算，因此发往拉丁美洲其他地区各国的消息，都计入同一个区域阶梯，而不是哥斯达黎加自己的阶梯。 ### 哥斯达黎加的企业有哪些消息是免费的？ 在手机上的 WhatsApp Business 应用中输入的所有消息都免费。Meta 的文档说明，接入之后应用消息仍然免费，Cloud API 定价只涵盖通过 API 发送的消息。 在 API 一侧，每个企业号码每月有 1,000 条免费服务消息，即 24 小时客户服务窗口内的非模板回复，未用完的额度不会结转。由 Click to WhatsApp 广告发起的对话，会开启最长 7 天的免费入口窗口，期间 Meta 不对营销、实用、验证或服务消息收费。自 2026 年 10 月 1 日起，在客户服务窗口内发送的实用类消息模板需要收费。 ### Meta 以哪种币种向哥斯达黎加的账户收费？ Meta 在 WhatsApp Business Platform 上启用了 16 种计费币种，其中不包括哥斯达黎加科朗。哥斯达黎加的企业在创建消息账户时，从已公布的币种中选择一种，例如 USD，Meta 会在每种币种的费率表中公布拉丁美洲其他地区的费率。 账户创建后，币种不能随意更改。Meta 提供 Currency Migration API 用于切换。Meta 的定价页面没有列出适用于哥斯达黎加的本地计费方案。 1. Check the number: The +506 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Set up billing: Choose one of Meta's supported currencies, such as USD, and add a payment method in Billing Hub. 3. Connect: Complete Embedded Signup with the portfolio and the number, and confirm the link from the app. - 在费率表中查找哥斯达黎加这一行。其实没有：+506 按拉丁美洲其他地区计费。 - 以为中美洲邻国与墨西哥的费率相同。墨西哥是单独列出的市场，营销费率低于该区域。 - 用实用类消息模板来做回复。开启的窗口内发送服务消息，每个号码每月 1,000 条以内免费。 **给哥斯达黎加发消息比墨西哥便宜吗？** 营销消息并不便宜。按 2026 年 10 月 1 日的费率表，拉丁美洲其他地区每条营销消息模板为 USD 0.074，墨西哥为 USD 0.0397。 **我可以用科朗向 Meta 付款吗？** 不可以。科朗不在 Meta 为 WhatsApp Business Platform 启用的 16 种币种之内。 **客户发给我的消息要收费吗？** 不要。Meta 只对企业发送的消息收费。 **连接 API 会让应用停止工作吗？** 不会。WhatsApp Business 应用仍可在手机上使用，聊天记录也都保留。 --- ## 西班牙的 WhatsApp Coexistence：可用性与 Meta 费率 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-spain Coexistence 在西班牙可用：Meta 面向 WhatsApp Business 应用用户的接入文档没有任何地域限制，欧盟也包括在内。发送到 +34 号码的消息使用西班牙专属的费率表，自 2026 年 10 月 1 日起，每条营销模板为 EUR 0.0585，每条实用或验证模板为 EUR 0.0166，换算为美元分别是 USD 0.0707 和 USD 0.02。 ### WhatsApp Coexistence 在西班牙和欧盟可用吗？ 可用。Meta 当前关于接入 WhatsApp Business 应用用户的文档，对号码、应用和合作伙伴列出了要求，但没有任何地域限制。+34 号码只要已在 WhatsApp Business 应用上使用，版本为 2.24.17 或更新，并由 Tech Provider 或 Solution Partner 通过 Embedded Signup 连接，就符合条件。 早期推出阶段把欧盟排除在外的名单仍在流传，但 Meta 的文档已不再支持这些说法。接入之后手机照常使用，号码通过 Cloud API 以固定的每秒 20 条消息的速率应答。 ### Meta 在西班牙每条消息收费多少？ Meta 按已送达的消息收费，依据消息类别和收件人国家区号所属的市场。西班牙（+34）是单独列出的市场，与涵盖葡萄牙、爱尔兰等国的 Rest of Western Europe 地区分开。下列为自 2026 年 10 月 1 日起生效的标准费率，营销费率上一次上调是在 2026 年 7 月 1 日。对于发往西班牙月消息量较大的业务组合，阶梯式批量折扣可以降低实用和验证模板的费率。 ### 西班牙企业有哪些消息是免费的？ 在手机上通过 WhatsApp Business 应用发送的消息。Meta 的文档说明，接入之后这些消息仍然免费，Cloud API 的定价只适用于通过 API 发送的内容。 通过 API 发送时，Meta 为每个企业电话号码每月提供 1,000 条免费服务消息，即在 24 小时客户服务窗口内发送的非模板回复，每月重置。客户通过 Click to WhatsApp 广告进入后，会开启最长 7 天的免费入口窗口，期间营销、实用、验证和服务消息均不收费。 自 2026 年 10 月 1 日起，在已开启的客户服务窗口内发送的实用模板会收费。 ### Meta 可以用欧元向西班牙企业收费吗？ 可以。在 Meta 于 2026 年新增十种货币之前，EUR 就已经是 WhatsApp Business Platform 支持的货币。Meta 公布了完整的 EUR 费率表，其中每个市场（不止西班牙）都以欧元计价。 货币在创建 Messaging 账户时选定，之后保持固定，只有通过 Meta 的 Currency Migration API 才能更改。Meta 的定价页面只提到巴西和印度需要强制迁移到本地货币计费，因此西班牙企业可以自行选择 EUR 或其他受支持的货币。 1. Check the number: The +34 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Choose EUR or USD: Set the currency when the account is created and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm the connection in the app. - 相信排除欧盟的旧版可用地区名单。Meta 当前的接入文档没有任何地域限制。 - 按西班牙的费率给葡萄牙客户定价。葡萄牙（+351）属于 Rest of Western Europe，费率不同。 - 使用 2026 年 7 月 1 日之前的营销费率数据。Meta 在该日上调了西班牙的营销费率。 **Coexistence 在欧盟曾经不可用吗？** 早期推出阶段的名单确实把欧盟排除在外。Meta 当前面向 Business 应用用户的接入文档没有写明任何地域限制，因此以接入流程本身的结果为准。 **从西班牙向拉丁美洲发消息，按西班牙的费率计费吗？** 不是。Meta 按收件人的国家区号收费，因此发往墨西哥号码的消息按墨西哥的费率计费。 **客户发给我的消息需要付费吗？** 不需要。Meta 只对企业送达用户的消息收费。 **连接之后应用还能继续使用吗？** 可以。WhatsApp Business 应用仍保留在手机上，聊天记录也在，号码则额外获得 API 访问权限。 --- ## 印度的 WhatsApp Coexistence：可用性、Meta 费率与 INR 计费 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-india Coexistence 可用于印度号码：Meta 面向 WhatsApp Business 应用用户的接入文档未列出任何国家限制。自 2026 年 10 月 1 日起，Meta 对每条送达 +91 号码的营销模板收取 US$ 0.0118，对每条实用类或验证类模板收取 US$ 0.0014。Billing Hub 中 Sold-To 国家为印度的企业，必须在 2026 年 12 月 31 日前将所有 WhatsApp Business Account 转为 INR 计费。 ### WhatsApp Coexistence 在印度可用吗？ 可用。Meta 目前关于接入 WhatsApp Business 应用用户的文档列出了各项要求（应用版本 2.24.17 或更高，并由 Tech Provider 或 Solution Partner 运行 Embedded Signup），以及一项限制：吞吐量固定为每秒 20 条消息。文档没有提到任何国家、地区或国家代码限制，因此在 WhatsApp Business 应用中处于活跃状态的 +91 号码，与其他任何地区的号码适用相同条件。 阻碍印度号码的原因与阻碍其他号码的相同：仍在使用 WhatsApp 个人版应用、应用版本低于 2.24.17，或已绑定到其他服务商。只要 Embedded Signup 没有拒绝该号码，就可以使用 Coexistence。 ### Meta 在印度每条消息收费多少？ Meta 按每条送达的模板消息收费，费率取决于收件人的国家代码，而不是企业所在的位置。无论发送方位于何处，送达 +91 号码的模板都按印度费率计价。 下列数字来自 Meta 自 2026 年 10 月 1 日起生效的 USD 和 INR 费率表。在 24 小时客户服务窗口内发送的非模板回复免费，在该窗口内发送的实用类模板免费，在 Coexistence 号码上通过 WhatsApp Business 应用输入的消息也保持免费。营销模板始终收费。Meta 的每月用量阶梯可为大量发送的企业降低实用类和验证类费率。 ### INR 计费在印度有哪些变化？ Meta 于 2026 年 1 月 1 日针对 Billing Hub 中 Sold-To 国家为印度的合作伙伴和直接集成的企业，推出了 INR 计费本地化。这些企业必须在 2026 年 12 月 31 日前，将其组合下所有 WhatsApp Business Account 迁移到 INR。Meta 表示，自 2027 年 1 月 1 日起，将不再送达符合条件客户名下非 INR 账户的消息。 对于 Coexistence 号码，这会影响通过 API 发送的付费消息，因为付款方式绑定在企业自己的 WhatsApp Business Account 上。印度还设有国际验证费率，适用于位于印度境外的符合条件企业，待 Meta 确定开始日期后生效，并会提前 30 天通知。 ### 如何将印度号码连接到 API 并继续使用应用？ 通过 Tech Provider 运行的 Meta Embedded Signup，并选择 Coexistence 选项。企业使用 Facebook 登录，选择其 Business Portfolio，输入已在 WhatsApp Business 应用中注册的 +91 号码，然后扫描应用中显示的二维码进行确认。之后可以同步应用中的聊天记录，其中媒体文件仅限最近两周。 该号码可继续在应用中使用，同时获得 Cloud API 访问权限，吞吐量固定为每秒 20 条消息。完整步骤以及每个界面所需的信息，请见“连接号码”页面。 - 在 Sold-To 国家为印度的情况下，2026 年 12 月 31 日之后仍让 WhatsApp Business Account 使用 USD。Meta 已表示将停止送达这些消息。 - 按发送方所在国家为营销活动计价。Meta 按收件人的国家代码收费，因此 +91 收件人按印度费率计算。 - 把所有模板都当作实用类。被 Meta 归为营销类的模板，在印度的费用是实用类费率的 8 倍以上。 **给印度客户的回复免费吗？** 在 24 小时客户服务窗口内的非模板回复免费，在 WhatsApp Business 应用中输入的消息也免费。窗口之外发送的模板需要付费。 **Meta 以哪种货币向印度企业计费？** Billing Hub 中 Sold-To 国家为印度的企业正在转为 INR 计费，所有账户须在 2026 年 12 月 31 日前完成。Meta 为此发布了 INR 费率表。 **如果我的企业在国外，也按印度费率付费吗？** 营销和实用类模板是的，因为费率取决于收件人的 +91 代码。待 Meta 为您的企业确定开始日期后，验证类模板可改按国际验证费率计费。 **我还能继续在手机上使用应用吗？** 可以。只要应用版本为 2.24.17 或更高，并且定期打开，Coexistence 就能让 WhatsApp Business 应用在同一号码上继续使用。 --- ## 印尼的 WhatsApp Coexistence：可用性、Meta 费率与设置 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-indonesia 印尼号码可以使用 Coexistence，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有设置国家限制。自 2026 年 10 月 1 日起，Meta 对每条送达 +62 号码的营销模板收费 US$ 0.0411（IDR 586.33），对每条实用类或身份验证类模板收费 US$ 0.025（IDR 356.65）。客户服务窗口内的回复仍然免费。 ### WhatsApp Coexistence 在印尼可用吗？ 可用。Meta 发布的 WhatsApp Business 应用用户接入 Cloud API 页面，对应用版本（2.24.17 或更新）和合作伙伴（使用 Embedded Signup 的 Tech Provider 或 Solution Partner）提出了要求，但没有列出任何被排除的国家或国家区号。在 WhatsApp Business 应用中已注册并处于活跃状态的 +62 号码，与其他号码享有相同的资格条件。 实际的障碍都是常见的几种：号码仍在个人版 WhatsApp 应用上、应用版本过旧，或号码已连接到其他服务商的应用。资格页面逐一说明了这些情况及解决办法。 ### Meta 在印尼每条消息收费多少？ Meta 按每条送达的模板计费，费率取决于接收方的国家区号。每条送达 +62 号码的模板都按印尼的费率收费，无论发送企业在雅加达还是在海外。 以下费率来自 Meta 自 2026 年 10 月 1 日起生效的 USD 和 IDR 费率表。在印尼，实用类与身份验证类共用一个费率 US$ 0.025，约为营销费率的 61%。在 24 小时服务窗口开启期间，自由文本回复不收费；在该窗口内发送的实用类模板免费；企业在 Coexistence 号码的 WhatsApp Business 应用中手动输入发送的消息同样免费。 ### 印尼企业需要了解哪些计费币种和身份验证方面的信息？ IDR 是 Meta 发布费率表的计费币种之一，另外还有 USD 和其他 14 种，因此印尼企业可以直接在 Meta 的费率表上查看以印尼盾计价的费用，无需自行换算。 印尼也在 Meta 设有国际身份验证费率的国家名单上。总部在印尼以外、向 +62 号码发送一次性验证码的企业，可能会被调整为每条身份验证模板 US$ 0.136，超过国内费率的 5 倍。Meta 按企业分别确定生效日期，并提前 30 天通知，因此需要验证印尼用户的海外应用，应在扩大注册规模之前做好预算。 ### 如何在不失去应用的情况下连接印尼号码？ 通过 Meta 的 Embedded Signup，选择现有 WhatsApp Business 应用号码的选项。企业使用 Facebook 登录，选择自己的 Business Portfolio，输入 +62 号码，并扫描应用上显示的二维码。完成后，合作伙伴须在 24 小时内开始同步联系人和聊天记录，否则企业需要重新走一遍流程。 接入完成后，手机照常使用，号码也可通过 Cloud API 收发消息，两者共享固定的每秒 20 条消息。连接号码页面逐屏介绍了每一步。 - 手动把美元价格换算成印尼盾。Meta 发布了 IDR 费率表，IDR 账户实际按该数字收费。 - 总部在海外的企业按国内费率为一次性验证码做预算。印尼设有国际身份验证费率 US$ 0.136。 - 扫描二维码后就中止流程。同步必须在 24 小时内开始，否则接入需要重做。 **印尼的实用类和身份验证类费率相同吗？** 相同。在 Meta 自 2026 年 10 月 1 日起生效的费率表上，两者每条送达的模板均为 US$ 0.025，即 IDR 356.65。 **Meta 可以用印尼盾向我收费吗？** IDR 是 Meta 在定价页面列出的计费币种之一，并有专属费率表，因此可以直接在 Meta 查看印尼盾金额。 **连接之后，从手机发送的消息会收费吗？** 不会。Meta 表示，完成 Coexistence 接入后，从 WhatsApp Business 应用发送的消息仍然免费。只有通过 Cloud API 发送的消息才按 Cloud API 定价计费。 **如果我的号码还在普通 WhatsApp 上怎么办？** 须先迁移到 WhatsApp Business 应用。Coexistence 仅提供给已在 Business 应用中的号码。 --- ## 阿联酋的 WhatsApp Coexistence：可用性、Meta 费率与 AED 计费 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-uae 阿联酋的号码可以使用 Coexistence，因为 Meta 面向 WhatsApp Business 应用用户的接入文档没有列出任何国家限制。自 2026 年 10 月 1 日起，每条送达 +971 号码的营销模板，Meta 收费 US$ 0.0576（AED 0.2115）；每条实用或验证模板收费 US$ 0.0157（AED 0.0576）。 ### WhatsApp Coexistence 在阿联酋可以使用吗？ 可以。Meta 关于将 WhatsApp Business 应用用户接入 Cloud API 的文档列出了企业和合作伙伴所需的条件，主要是应用版本 2.24.17 或更新，以及使用 Embedded Signup 的 Tech Provider 或 Solution Partner，文档中没有任何国家、地区或国际区号的排除条款。只要 +971 号码正在 WhatsApp Business 应用上使用，就符合条件。 阿联酋号码失败的原因与其他地方相同：号码在个人版 WhatsApp 应用上、应用版本过旧，或号码仍绑定在其他服务商。Embedded Signup 本身就是最可靠的检测方式，因为它要么接受该号码，要么说明原因。 ### Meta 在阿联酋每条消息收费多少？ Meta 按每条送达的模板收费，价格由接收方的国际区号决定。任何送达 +971 号码的模板都按阿联酋费率计费，与发送企业在哪里注册无关。阿联酋在 Meta 费率表上有单独一行，而不是与中东其他地区共用费率。 下方数字取自 2026 年 10 月 1 日起生效的 Meta USD 与 AED 费率表。在开启的 24 小时客户服务窗口内发送的自由文本回复免费，在该窗口内发送的实用模板免费，而在 Coexistence 号码上通过 WhatsApp Business 应用发送的消息仍然免费。营销模板每次送达都会收费。 ### 阿联酋的定价和计费最近有什么变化？ Meta 定价变更记录中有两项变化直接适用。2025 年 10 月 1 日，Meta 上调了阿联酋的营销消息费率。2026 年 4 月 1 日，Meta 新增八种计费货币，AED 就是其中之一，因此阿联酋的企业现在可以用迪拉姆结算，并根据 AED 费率表查看成本。 阿联酋也在 Meta 设有国际验证费率的市场名单中。总部在阿联酋境外、向 +971 号码发送一次性验证码的企业，一旦 Meta 确定开始日期（会提前 30 天公布），验证模板可能改按每条 US$ 0.051 计费。 ### 如何连接阿联酋号码到 API 并保留应用？ 通过 Meta 的 Embedded Signup，选择现有 WhatsApp Business 应用选项，由 Tech Provider 运行。企业用 Facebook 登录，选择其 Business Portfolio，输入 +971 号码，并用应用中显示的二维码确认。已同步聊天记录中的媒体文件只提供最近两周的内容。 之后 WhatsApp Business 应用仍可在手机上正常使用，同一号码则通过 Cloud API 收发消息，固定速率为每秒 20 条消息。连接号码页面列出了每个步骤及所需条件。 - 误以为阿联酋按中东其他地区的费率计价。它在 Meta 费率表上有单独且更高的一行。 - 手动把 USD 费率换算成迪拉姆。自 2026 年 4 月 1 日起，Meta 已发布数字各异的 AED 费率表。 - 从境外向 +971 号码发送验证码，却仍按本地预算估算。国际验证费率高出三倍多。 **Meta 可以用迪拉姆向阿联酋企业收费吗？** 可以。自 2026 年 4 月 1 日起，AED 成为 WhatsApp Business Platform 的计费货币，并有独立的费率表。 **阿联酋和沙特阿拉伯的定价相同吗？** 营销模板相同：在 2026 年 10 月 1 日的费率表上均为 US$ 0.0576。实用和验证模板则不同，阿联酋为 US$ 0.0157，沙特阿拉伯为 US$ 0.0107。 **回复先发消息的客户会收费吗？** 如果是在 24 小时客户服务窗口内的自由文本回复，则不收费。在窗口之外发送的模板会收费。 **手机上的应用会停止工作吗？** 不会。Coexistence 让 WhatsApp Business 应用在同一号码上继续工作，从应用发送的消息仍然免费。 --- ## 沙特阿拉伯的 WhatsApp Coexistence：可用性、Meta 费率与 SAR 计费 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-saudi-arabia 沙特号码可以使用 Coexistence：Meta 针对 WhatsApp Business 应用用户的接入文档没有设置国家限制。自 2026 年 10 月 1 日起，每条送达 +966 号码的营销模板，Meta 收费 US$ 0.0576（SAR 0.2159）；每条实用或验证模板收费 US$ 0.0107（SAR 0.0401）。在客户服务窗口内发送的自由文本回复不收费。 ### 沙特阿拉伯可以使用 WhatsApp Coexistence 吗？ 可以。Meta 关于将 WhatsApp Business 应用用户接入 Cloud API 的文档，对应用版本（2.24.17 或更新）和运行 Embedded Signup 的合作伙伴设有条件，但没有列出任何被排除的国家、地区或国际区号。已在 WhatsApp Business 应用中注册并处于活跃状态的 +966 号码符合资格。 沙特号码被拒绝时，原因通常是几种常见情况之一：号码在个人版 WhatsApp 应用上、应用版本低于 2.24.17，或号码仍绑定在其他服务商。资格页面逐一说明了每种情况及其解决办法。 ### Meta 在沙特阿拉伯每条消息收费多少？ Meta 按收件人的国际区号为每条送达的模板定价。无论发送方位于何处，送达 +966 号码的模板都按沙特阿拉伯的费率收费，沙特阿拉伯在费率表上有单独一行。 下方数字来自 Meta 自 2026 年 10 月 1 日起生效的 USD 和 SAR 费率表。在 24 小时客户服务窗口内发送的自由文本回复免费，在该窗口内发送的实用模板免费，Coexistence 号码从 WhatsApp Business 应用发出的消息也不收费。营销模板每次送达都会收费，月度用量分级可为大批量发送方降低实用和验证模板的费率。 ### 2026 年沙特企业遇到了哪些变化？ Meta 的定价变更日志显示，2026 年 4 月 1 日有两项变化：沙特阿拉伯的营销消息费率上调，SAR 成为八种新增计费币种之一。因此，沙特企业可以用里亚尔结算，并对照 SAR 费率表核对成本，无需再从美元换算。 沙特阿拉伯也是设有国际验证费率的市场之一。总部在境外的企业向 +966 号码发送一次性验证码时，可能被调整为每条验证模板 US$ 0.0598，是本地费率的五倍多。Meta 会按企业分别指定生效日期，并在生效前提前 30 天通知。 ### 如何连接沙特号码并继续使用应用？ 通过 Meta 的 Embedded Signup，选择适用于已在 WhatsApp Business 应用中使用的号码的选项。由 Tech Provider 托管该流程；企业使用 Facebook 登录，选择其 Business Portfolio，输入 +966 号码，并扫描应用显示的二维码。随后合作伙伴需要在 24 小时内开始同步，否则必须重新走一遍流程。 此后手机照常使用，同一号码通过 Cloud API 收发消息，速率固定为每秒 20 条消息。每一步都在连接号码页面中有详细说明。 - 按 2026 年 4 月 1 日之前的费率为沙特营销发送做预算。Meta 在当天上调了营销费率。 - 用货币转换器把 USD 费率表换算成 SAR 成本。Meta 自行发布了 SAR 费率。 - 从境外企业向 +966 号码发送验证码时按本地费率计算。国际验证费率为 US$ 0.0598。 **沙特企业可以用里亚尔结算吗？** 可以。Meta 于 2026 年 4 月 1 日新增 SAR 作为计费币种，并发布了 SAR 费率表。 **沙特阿拉伯按“中东其他地区”计价吗？** 不是。它在 Meta 费率表上有单独一行，营销为 US$ 0.0576，实用和验证为 US$ 0.0107。 **我在应用中输入的消息会收费吗？** 不会。Meta 表示，完成 Coexistence 接入后，从 WhatsApp Business 应用发送的消息仍然免费。 **需要哪个应用版本？** 持有 +966 号码的手机上需安装 WhatsApp Business 应用 2.24.17 或更新版本。 --- ## 土耳其的 WhatsApp Coexistence：可用性、Meta 费率与设置 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-turkey 土耳其号码可以使用 Coexistence，因为 Meta 面向 Business 应用用户的接入文档没有列出任何国家限制。自 2026 年 10 月 1 日起，Meta 向 +90 号码每送达一条营销消息模板收取 US$ 0.0109，每条实用或身份验证消息模板收取 US$ 0.0009。Meta 已于 2026 年 4 月 1 日下调土耳其的实用和身份验证费率，且没有发布里拉费率表。 ### 土耳其可以使用 WhatsApp Coexistence 吗？ 可以。Meta 维护的、介绍如何将 WhatsApp Business 应用用户接入 Cloud API 的页面，只对应用版本（2.24.17 或更新）和合作伙伴（使用带会话日志的 Embedded Signup 的 Tech Provider 或 Solution Partner）提出要求，没有任何国家或国际区号的排除条款。在 WhatsApp Business 应用中处于活跃状态的 +90 号码符合条件。 土耳其号码被拒绝的原因与其他号码相同：号码仍在个人版 WhatsApp 应用上、应用需要更新，或者另一家服务商仍占用该号码。这些问题都可以在手机上或向原服务商处理，资格页面有详细说明。 ### Meta 在土耳其每条消息收费多少？ Meta 按每条送达的消息模板收费，费率取决于收件人的国家区号，因此无论发送方在哪里，送达 +90 号码的每条消息模板都按土耳其的费率计价。土耳其在费率表上有单独一行。 在 2026 年 10 月 1 日生效的 Meta USD 费率表上，这些数字属于表中最低之列：营销为 US$ 0.0109，实用和身份验证为 US$ 0.0009。EUR 费率表列出的是 €0.009 和 €0.0007。Meta 没有列出土耳其的国际身份验证费率。在 24 小时客户服务窗口内的自由文本回复免费，在窗口内发送的实用消息模板同样免费，Coexistence 号码从 WhatsApp Business 应用发出的消息也保持免费。 ### Meta 以哪种币种向土耳其企业计费？ Meta 以十六种币种发布其 WhatsApp Business Platform 费率表：USD、AED、ARS、AUD、BRL、CLP、COP、EUR、GBP、IDR、INR、MXN、MYR、PEN、SAR 和 SGD。土耳其里拉不在其中，因此土耳其企业会以其中一种币种（如 USD 或 EUR）计费，成本应直接参照该费率表，而不是自行换算。 最重要的费率变动发生在不久前。2026 年 4 月 1 日，Meta 下调了土耳其的实用和身份验证费率，使发给 +90 号码的订单更新和一次性验证码每条只需不到一美分。在该日期之前制定的预算会高估这些成本。 ### 如何连接土耳其号码并保留应用？ 通过 Meta 的 Embedded Signup，选择适用于已在 WhatsApp Business 应用中使用的号码的选项，由 Tech Provider 托管。企业使用 Facebook 登录，选择其 Business Portfolio，输入 +90 号码，并在应用中扫描二维码确认。同步必须在 24 小时内开始，否则需要重新运行该流程。 连接后，手机照常使用，同一号码获得 Cloud API 访问权限，速率固定为每秒 20 条消息。连接号码页面会逐个界面带您完成整个过程。 - 寻找土耳其里拉费率表。Meta 没有发布，请查看您的账户所用计费币种的 USD 或 EUR 费率表。 - 沿用 2026 年 4 月 1 日之前制定的预算。Meta 当天下调了土耳其的实用和身份验证费率。 - 为省钱而把促销内容归为实用类。Meta 会审核消息模板类别，营销消息模板按营销费率收费。 **土耳其有国际身份验证费率吗？** 没有。Meta 在 2026 年 10 月 1 日生效的费率表中，将土耳其的该项标注为不适用。 **Meta 可以用土耳其里拉向我计费吗？** 不可以。里拉不在 Meta 发布费率表的十六种计费币种之中。 **回复土耳其客户的消息免费吗？** 在 24 小时客户服务窗口内的自由文本回复免费。窗口之外的消息模板按每次送达收费。 **连接 API 会让应用停止工作吗？** 不会。使用 Coexistence 时，WhatsApp Business 应用在同一号码上继续工作，其消息保持免费。 --- ## 德国的 WhatsApp Coexistence：可用性、Meta 费率与设置 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-germany 德国号码可以使用 Coexistence：Meta 面向 WhatsApp Business 应用用户的接入文档没有列出任何国家或欧盟限制。自 2026 年 10 月 1 日起，Meta 对送达 +49 号码的每条营销模板收取 US$ 0.1365（€0.1131），对每条实用或验证模板收取 US$ 0.055（€0.0456）。在客户服务窗口内发送的自由文本回复免费。 ### WhatsApp Coexistence 在德国可用吗？ 可用。Meta 关于将 WhatsApp Business 应用用户接入 Cloud API 的文档，对应用版本（2.24.17 或更高）以及运行 Embedded Signup 的合作伙伴提出了要求，但没有列出任何国家、地区或国家代码限制，也没有针对欧盟的附加条件。在 WhatsApp Business 应用中已注册并处于活跃状态的 +49 号码符合条件。 如果 Embedded Signup 拒绝了某个德国号码，原因通常是这些常见情况之一：该号码仍在消费者版 WhatsApp 应用上，应用版本低于 2.24.17，或者另一家服务商仍持有该号码。资格页面逐一说明了每种情况。 ### Meta 在德国每条消息收费多少？ Meta 按每条送达的模板收费，价格取决于收件人的国家代码。送达 +49 号码的模板，无论发送方企业位于柏林、维也纳还是其他地方，都按德国费率计费。 德国在 Meta 费率表上有独立的一行，明显高于其余西欧那一行：营销模板为 US$ 0.1365，对比 US$ 0.0592；实用模板为 US$ 0.055，对比 US$ 0.0171。Meta 没有列出德国的国际验证费率。在 24 小时客户服务窗口开启期间发送的自由文本回复免费，窗口内发送的实用模板也免费，而在 Coexistence 号码上通过 WhatsApp Business 应用输入的消息依然免费。 ### 德国费率对企业使用 API 的方式意味着什么？ 向 +49 号码发送一条营销模板的费用超过 US$ 0.13，一条实用模板为 US$ 0.055，因此在德国最便宜的消息，就是 Meta 完全不收费的那些。 这使客户服务窗口成为控制成本的主要手段。在 24 小时内回复主动来信的客户，每条消息都不收费。窗口开启期间发送的实用模板同样免费。账单主要来自用模板开启新对话的外联。在 Coexistence 号码上，员工在手机的 WhatsApp Business 应用中输入的任何消息也都免费，因此可以把 API 留给自动发送使用。 ### 如何连接德国号码并保留应用？ 使用 Meta 的 Embedded Signup，并选择适用于已在 WhatsApp Business 应用中使用的号码的选项。由 Tech Provider 托管该流程；企业用 Facebook 登录，选择其 Business Portfolio，输入 +49 号码，并用应用中显示的二维码确认。完成后必须在 24 小时内开始同步，否则需要重新走一遍流程。 之后手机仍可正常使用，同一个号码通过 Cloud API 收发消息，速率固定为每秒 20 条消息。每个界面都在连接号码页面中有说明。 - 按其余西欧费率来预算德国收件人的费用。德国有自己的费率行，营销模板的费用超过其两倍。 - 在窗口内回复即可的情况下，仍用模板开启对话。在德国，免费与收费之间的差距很大。 - 为了少付费而把促销内容归为实用类别。Meta 会审核模板类别，并按营销费率收取营销模板的费用。 **Meta 可以用欧元向德国企业收费吗？** 可以。EUR 是 Meta 发布费率表所用的计费货币之一，在 2026 年 10 月 1 日的费率表上，德国营销模板为 €0.1131。 **Coexistence 在欧盟有额外条件吗？** Meta 当前面向 Business 应用用户的接入文档没有列出任何额外条件。各地要求相同：应用版本 2.24.17 或更高，并通过 Embedded Signup 合作伙伴接入。 **回复德国客户需要付费吗？** 在 24 小时客户服务窗口内发送的自由文本回复不收费。窗口之外发送的模板按每次送达收费。 **从手机发送的消息仍然免费吗？** 是的。Meta 表示，接入完成后从 WhatsApp Business 应用发送的消息依然免费。只有通过 Cloud API 发送的消息才按 Cloud API 定价计费。 --- ## 意大利的 WhatsApp Coexistence：可用性、Meta 费率与设置 https://easycoexistence.com/zh-hans/docs/whatsapp-coexistence-italy 意大利号码可以使用 Coexistence，因为 Meta 针对 WhatsApp Business 应用用户的接入文档没有列出任何国家或欧盟限制。自 2026 年 10 月 1 日起，Meta 对送达 +39 号码的每条营销类消息模板收取 US$ 0.0795（€0.0658），对每条实用类或验证类消息模板收取 US$ 0.03（€0.0248）。Meta 已于 2026 年 7 月 1 日上调意大利的营销消息费率。 ### WhatsApp Coexistence 在意大利可用吗？ 可用。Meta 关于将 WhatsApp Business 应用用户接入 Cloud API 的文档列出了所需条件，主要是应用版本 2.24.17 或更高，以及由 Tech Provider 或 Solution Partner 通过 Embedded Signup 办理，其中没有任何国家、地区或国家区号的排除条款，也没有为欧盟号码增加额外条件。在 WhatsApp Business 应用中正常使用的 +39 号码符合条件。 意大利号码被拒绝，只会出于一般原因：号码在个人版 WhatsApp 应用上、应用需要更新，或号码仍被其他服务商占用。资格说明页面逐一解释了这些情况及解决办法。 ### Meta 在意大利每条消息收费多少？ Meta 按每条送达的消息模板计费，费率取决于收件人的国家区号，因此任何送达 +39 号码的消息模板都按意大利费率收费，与企业在哪里注册无关。意大利在费率表中有单独一行，不适用其他西欧地区的费率。 下方数字来自 Meta 自 2026 年 10 月 1 日起生效的美元和欧元费率表。Meta 没有列出意大利的国际验证类费率。在 24 小时客户服务窗口开启期间，自由文本回复免费，窗口内发送的实用类消息模板免费，在启用 Coexistence 的号码上通过 WhatsApp Business 应用发送的消息也不收费。 ### 2026 年意大利的定价有什么变化？ Meta 的定价更新记录显示，今年意大利只有一项变化：自 2026 年 7 月 1 日起上调营销消息费率，同一次更新还调整了西班牙、波兰、匈牙利、罗马尼亚、英国等地的费率。实用类和验证类不在这次调整之内。 实际影响主要在营销活动上。2026 年 7 月之前制定的 +39 号码促销模板预算会低估成本，而订单确认、配送通知和一次性验证码的价格与之前相同。使用欧元计费无需换算，因为欧元是 Meta 发布费率表的币种之一，€0.0658 的营销费率就是 Meta 自己公布的数字。 ### 如何连接意大利号码并保留应用？ 通过 Meta 的 Embedded Signup，选择适用于已在 WhatsApp Business 应用中注册号码的选项。流程由 Tech Provider 托管。企业使用 Facebook 登录，选择自己的 Business Portfolio，输入 +39 号码，并扫描应用中显示的二维码。同步的聊天记录中，媒体文件只包含最近两周的内容。 接入完成后，手机仍可正常使用，同一号码也会通过 Cloud API 收发消息，速率固定为每秒 20 条消息。连接号码页面逐步说明了每个步骤。 - 沿用 2026 年 7 月 1 日之前制定的 +39 收件人营销预算。Meta 在当天上调了意大利的营销费率。 - 对意大利号码套用其他西欧地区的费率。意大利在 Meta 费率表中有单独一行。 - 在仍使用个人版 WhatsApp 应用的号码上开始接入。必须先迁移到 WhatsApp Business 应用。 **Meta 可以用欧元向意大利企业收费吗？** 可以。欧元是 Meta 的计费币种之一，其欧元费率表中意大利的营销类为 €0.0658，实用类和验证类为 €0.0248。 **2026 年意大利的实用类费率有变化吗？** 没有。2026 年 7 月 1 日的更新只上调了意大利的营销消息费率。 **回复意大利客户的消息要收费吗？** 在 24 小时客户服务窗口内，自由文本回复免费。窗口之外发送的消息模板在送达时收费。 **我的员工还能继续使用应用吗？** 可以。Coexistence 让 WhatsApp Business 应用在同一号码上继续使用，从应用发送的消息仍然免费。 --- ## 如何断开 Coexistence，仅使用应用 https://easycoexistence.com/zh-hans/docs/disconnecting-coexistence Coexistence 需要在 WhatsApp Business 应用中关闭：依次进入设置、账户、Business Platform，然后点击 Disconnect Account。应用继续使用该号码，提供商的访问权限终止，并发送带有 PARTNER_REMOVED 的 account_update Webhook。同时在两处使用的号码，无法通过 Cloud API 的 Deregister 端点注销。 ### 如何关闭 Coexistence？ 在持有该号码的手机上操作。当号码与 WhatsApp Business 应用共用时，Meta 只提供一种让企业退出 Cloud API 的方式，而且必须通过应用完成，不能通过任何控制台或端点。主手机的持有者决定是否断开，因此代理商或开发者需要请企业自行操作。 - 在主设备上打开 WhatsApp Business 应用。 - 进入设置，然后是账户，再进入 Business Platform。 - 点击 Disconnect Account 并确认。 - API 端会收到带有 PARTNER_REMOVED 事件的 account_update Webhook。 ### 为什么 Deregister API 会拒绝该号码？ 因为 Meta 有意将 Coexistence 号码排除在外。注册文档明确说明，Deregister 端点无法注销同时用于 Cloud API 和 WhatsApp Business 应用的企业电话号码。 注销会使号码无法再用于 Cloud API。对于仅使用 API 的号码，这是将线路从平台移除的方式。对于共用号码，应用才是该线路的主要所有者，所以 Meta 把决定权交还给持有它的人。软件如果先尝试调用该端点，得到的是错误而不是断开，号码会一直保持连接，直到有人在应用中点击按钮。 ### 应用、聊天记录和号码会怎样？ 断开不等于删除账户，这一区别就是答案的全部。 Meta 关于丢失消息记录的警告，针对的是删除 WhatsApp Business 应用账户并在 Cloud API 上注册号码。断开这两件事都不做。应用仍然安装并保持注册，号码仍在其中，团队继续用同一部手机回复客户。 终止的是 API 端。提供商的应用会从号码上移除，因此通过 Cloud API 发送消息以及相应的 Webhook 投递都会停止。Coexistence 关闭的功能，例如广播列表，见有关已禁用功能的页面。 ### 之后可以重新连接该号码吗？ 可以，从头重新运行接入流程即可。Meta 自己的文档也把解除接入再重新完成流程视为重置连接的常规做法，例如错过了同步联系人和记录的 24 小时窗口时。 重新连接是一次全新的接入，首次询问的问题会再问一遍，包括是否共享聊天记录。旧连接上配置的内容，例如 Webhook 覆盖设置，需要重新应用。需要换到其他提供商的号码也走同样的路径：在这里断开，然后通过新的提供商接入。 - 对 Coexistence 号码调用 Deregister 端点。Meta 会拒绝，断开必须在应用中完成。 - 为了退出而删除 WhatsApp Business 应用账户。这正是会丢失聊天记录的做法。 - 把 PARTNER_REMOVED 当作需要重试的故障。它是企业主动做出的断开。 **断开后我会丢失聊天记录吗？** 不会。断开只是把 API 从号码上移除，不会删除 WhatsApp Business 应用账户，而 Meta 警告会丢失记录的正是删除账户。 **可以通过 API 断开吗？** 不可以。对于同时用于 Cloud API 和应用的号码，Meta 不允许使用 Deregister 端点。 **我的系统如何得知已断开？** 企业断开时，Meta 会发送带有 PARTNER_REMOVED 事件的 account_update Webhook。 **可以重新连接同一个号码吗？** 可以。像首次连接一样，从头重新运行接入流程即可。 --- ## 将号码从 Coexistence 迁移到纯 Cloud API https://easycoexistence.com/zh-hans/docs/moving-from-coexistence-to-cloud-api 要让 Coexistence 号码变为纯 API 号码，需要先在 WhatsApp Business 应用中断开连接，再删除应用账户，最后使用两步验证 PIN 在 Cloud API 上注册该号码。Meta 警告现有消息历史记录会丢失，而且除非先从 Cloud API 注销注册，否则该号码无法再回到应用。 ### 企业为什么要离开应用？ 通常是因为已经没有人再用手机回复消息。当所有对话都由软件或基于 API 构建的收件箱处理时，应用只会增加负担，却没有带来任何好处：主设备仍需定期打开，号码的吞吐量也仍被 Coexistence 固定在较低水平。 Meta 文档指出，同时在应用和 Cloud API 上使用的号码，吞吐量固定为每秒 20 条消息。纯 API 号码默认起步最高为每秒 80 条消息，满足 Meta 的条件后可自动升级到 1,000。对于大量发送消息的号码，这个差距就是迁移的理由。 ### 步骤的顺序是什么？ 一共四步，顺序很重要，因为 Deregister 端点会拒绝仍与应用共享的号码。除最后一步外，其余每一步都由企业在手机上完成；最后一步是 API 调用，由今后负责运营该号码的一方发起。 - 按照 Meta 的建议，先在 WhatsApp Business 应用中备份聊天记录。 - 在应用中断开连接：设置 > 账户 > Business Platform > Disconnect Account。 - 删除应用账户：设置 > 账户 > Delete my account，然后最多等待 3 分钟。 - 使用 6 位两步验证 PIN 在 Cloud API 上注册该号码。 ### 企业会失去什么？ 手机上的对话，以及用手机回复消息的方式。 Meta 明确指出，删除 WhatsApp Business 应用账户并在 Cloud API 上注册号码，会丢失现有的消息历史记录。这与 Coexistence 接入正好相反：Meta 说明在 Coexistence 下历史记录会保留，应用和 API 也可同时运行。 此外，除非先从 Cloud API 注销注册，否则该号码无法再次用于 WhatsApp Business 应用。因此这是一次经过慎重考虑、不可逆的运营方式变更，开始之前最好确认团队中没有人还在使用应用。 ### API 一侧有哪些保持不变？ 软件与号码交互的方式不变。使用的仍是 Cloud API：消息类型、消息模板、Webhook 和定价都相同，因为 Coexistence 只是进入同一平台的另一种接入方式。 变化在于注册。Coexistence 号码由接入流程完成注册；纯 API 号码则通过携带两步验证 PIN 的 register 调用完成注册，Meta 将此类调用限制为每个号码在 72 小时滚动窗口内 10 次。失败的尝试会消耗次数，所以重试之前请先检查 PIN。 - 在备份聊天记录之前就删除应用账户。Meta 明确指出，这条路径会丢失历史记录。 - 号码仍与应用共享时就调用 Deregister。Meta 会拒绝该请求。 - 在循环中反复重试注册。Meta 允许每个号码在 72 小时内发出 10 次 register 请求。 **迁移到纯 API 后，我能保留聊天记录吗？** 无法在 API 中保留。Meta 警告历史记录会丢失，并建议先从应用中备份。 **号码以后还能回到应用吗？** 根据 Meta 的迁移指南，只有先从 Cloud API 注销注册后才可以。 **吞吐量会提高吗？** 会。Coexistence 号码固定为 20 mps，纯 API 号码起步最高为 80 mps。 **我可以先用 Deregister API 开始吗？** 号码与应用共享时不行。请先在 WhatsApp Business 应用中断开连接。 --- ## 从其他 WhatsApp 服务商迁移号码 https://easycoexistence.com/zh-hans/docs/migrating-a-number-from-another-provider 这取决于号码目前的连接方式。若号码通过其他服务商与 WhatsApp Business 应用共用，需先在应用内断开连接，再由新服务商重新接入。纯 API 号码则走 Meta 的号码迁移，可保留显示名称、质量评级、消息发送上限和 Official Business Account 状态。 ### 我属于哪种情形？ 只需问一个问题：现在是否仍有人在手机上通过 WhatsApp Business 应用接听这个号码？ 如果是，说明该号码与当前服务商使用的是 Coexistence，号码由应用持有。离开该服务商要在应用内操作，加入新服务商则是一次全新的 Coexistence 接入。 如果不是，说明号码只注册在 Cloud API 上，背后没有应用。Meta 为此提供了单独的迁移流程，可把号码从一个合作伙伴的 WhatsApp Business Account 转到另一个，无需从头重新注册。把这两种情形混为一谈，是迁移中途卡住的常见原因。 ### Coexistence 号码如何更换服务商？ 做法是先解除接入，再重新接入。按 Meta 文档，企业需在应用中依次进入「设置」「账户」「Business Platform」，点击「Disconnect Account」按钮来断开与 Cloud API 的连接，服务商会收到带有 PARTNER_REMOVED 的 account_update Webhook。 断开后，该号码就恢复为普通的 WhatsApp Business 应用号码，新服务商可以通过 Embedded Signup 重新接入。条件与一般的 Coexistence 相同：应用版本较新、您担任管理员的 Business Portfolio，以及没有其他服务商仍在连接。是否共享历史记录会再次询问，24 小时同步窗口也会从新的接入开始重新计算。 ### 纯 API 迁移会保留什么？ 保留的内容比多数人预想的要多，这正是 Meta 提供迁移而不是让您删除后重新注册的原因。号码在客户中建立的信誉得以保留，只有消息模板的质量记录会重新开始。 - 显示名称、质量评级、消息发送上限和 Official Business Account 状态都会保留。 - 符合条件的消息模板会以相同状态复制到目标账户。 - 号码上已上传的媒体仍可继续使用。 - 消息模板的质量评级不会延续：每个迁移后的模板都从 UNKNOWN 开始。 ### 纯 API 迁移前需要准备什么？ Meta 对双方都列出了条件，而客户一侧的条件正是迁移最容易卡住的地方。 企业的 Meta Business Portfolio 必须已通过验证，现有的 WhatsApp Business Account 必须已获批准，并绑定有效的付款方式。号码必须已关闭两步验证，而 Meta 没有提供可关闭它的 API 端点，所以服务商无法通过 API 完成这一步。在接收一方，目标账户上至少要有一个应用订阅了 Webhook。 新账户上的注册会立即完成，消息发送不会中断，但模板复制需要时间，因此受影响的模板要等副本生成后才能使用。 - 旧服务商仍在连接时就接入新服务商。必须先在应用内断开号码。 - 在两步验证仍开启时启动纯 API 迁移。Meta 要求先关闭，而且没有端点可以代为操作。 - 以为模板质量会保留。迁移后的模板会从 UNKNOWN 重新开始。 **更换 Coexistence 服务商会丢失聊天记录吗？** 应用会全程保留聊天记录。接入时会再次询问是否与新连接共享历史记录。 **纯 API 迁移会更改我的显示名称吗？** 不会。Meta 会保留显示名称、质量评级、消息发送上限和 Official Business Account 状态。 **为什么我的模板失去了质量评级？** Meta 会把模板复制到目标账户，每个副本的评级都从 UNKNOWN 开始。 **会有停机时间吗？** Meta 表示纯 API 迁移中的注册会立即完成，消息发送不会中断。模板在复制完成后即可使用。 --- ## Coexistence 号码上的 WhatsApp 群组与 API https://easycoexistence.com/zh-hans/docs/whatsapp-groups-and-the-api Meta 的 Groups API 允许 Cloud API 号码创建仅限邀请的小型群组并向其发送消息，但 Meta 明确表示它不适用于 WhatsApp Business 应用的电话号码，而 Coexistence 号码正是这类号码。应用中已有的群组也不会同步。在共用号码上，群组仍然只是应用端的功能。 ### WhatsApp 有 Groups API 吗？ 有。Meta 的 Groups API 允许企业在 Cloud API 号码上创建、列出和更新群组，向群组发送文本、媒体和模板消息，管理邀请链接，批准或拒绝加入请求，以及移除参与者。 它刻意设计得很小。群组仅限邀请，成员通过企业发送的链接加入，Meta 的限制更接近一个项目群，而不是社群。 - 每个群组最多 8 名参与者。 - 每个企业号码最多 10,000 个群组。 - 每个群组只能有一个 Cloud API 企业。 - 支持文本、媒体、基于文本的模板和基于媒体的模板。 ### Coexistence 号码可以使用它吗？ 不可以。Groups API 页面明确说明它不适用于 WhatsApp Business 应用的电话号码，而这句话链接到 Meta 自己关于接入 WhatsApp Business 应用用户的指南，也就是 Coexistence。资格条件同样是 Official Business Account，而 Meta 的 OBA 页面表示不会向 WhatsApp Business 应用的电话号码授予该状态。 因此，这一排除是 Meta 为所有服务商统一设定的。应用与 API 共用的号码无法通过 API 创建群组，无法向群组发送消息，也收不到任何群组事件。 ### 应用中已有的群组会怎样？ 它们仍留在应用中，并继续在那里正常使用。Meta 的 Coexistence 文档将群聊列为号码接入时不会同步的内容，因此群组的历史记录和新的群组消息都不会进入 API。 手机上的团队仍然可以像以前一样创建群组、在群里发言和阅读消息。只是软件看不到这些流量。如果某个工作流程依赖群组，例如员工协调送货，它会继续在应用中进行，而围绕它的任何自动化都只能改用一对一对话来构建。 ### 不通过 API 使用群组时，应该用什么替代？ 使用一对一对话，这也是整个平台的设计基础。原本要发给一群客户的消息，改为分别发给每一位客户：在 24 小时客户服务窗口内以自由文本发送，窗口之外则使用已批准的模板。 如果企业确实需要由 API 管理的群组，Groups API 要求号码仅注册在 Cloud API 上，并持有 Official Business Account，这意味着该号码必须退出 Coexistence。这是关于该号码线路的结构性决定，而不是一项设置，并且会让应用不再能使用这条线路。 - 看到存在 Groups API，就以为它适用于 Coexistence 号码。Meta 排除了 Business 应用号码。 - 以为接入后群组历史记录会出现在 API 中。群聊不会同步。 - 围绕 8 名参与者的上限规划基于群组的工作流程，却没有先确认是否够用。 **我可以通过 API 向 WhatsApp 群组发送消息吗？** 只有使用 Groups API、拥有 Official Business Account 的纯 API 号码才可以。Coexistence 号码不行。 **我现有的群组还能用吗？** 可以，在 WhatsApp Business 应用中照常使用。它们不会同步到 API。 **API 群组最多可以有多少人加入？** Meta 将通过 Groups API 创建的群组上限设为 8 名参与者。 **这是我的服务商造成的限制吗？** 不是。Meta 对所有服务商一律排除 WhatsApp Business 应用号码。 --- ## Meta Verified 与 Coexistence 号码上的官方企业标识 https://easycoexistence.com/zh-hans/docs/meta-verified-and-coexistence 有两种不同的东西都被称为蓝色标识。官方企业账户（OBA）是为 Cloud API 号码申请的状态，Meta 文档称不会授予 WhatsApp Business 应用号码。WhatsApp Business 的 Meta Verified 是在应用内订阅的服务，包含认证标识、多客服访问和增强支持。 ### 什么是官方企业账户？ 这是注册在 WhatsApp Business Platform 上的企业号码所具有的一种状态。Meta 的描述是：由经过验证为真实的企业所拥有的号码，在联系人视图中，名称旁会显示蓝色对勾。您可以在 WhatsApp Manager 中的号码资料下申请，也可以通过 API 的 official_business_account 字段申请。 - 企业遵守 WhatsApp Business 消息政策。 - 已在平台上注册至少 30 天。 - 其 Business Portfolio 已通过 Business Verification。 - 号码已启用两步验证，且显示名称已获批准。 ### Coexistence 号码能获得 OBA 状态吗？ Meta 的 OBA 文档称，不会向企业员工、测试账户和 WhatsApp Business 应用号码授予 OBA 状态。Meta 在其 Groups API 页面上使用了同一个说法，即 WhatsApp Business 应用号码，并链接到 WhatsApp Business 应用用户的接入指南，也就是 Coexistence。 Meta 没有针对应用与 API 共用的号码另行公布规则，因此文档中的立场就是上述内容。被拒绝的申请可在 30 天后重新提交，期间企业资料仍可编辑。 ### 什么是 WhatsApp Business 的 Meta Verified？ 这是通过 WhatsApp Business 应用办理的付费订阅，与平台的 OBA 流程相互独立。Meta 的资源页面列出了其包含的内容：认证标识、自定义网页、增强支持、可连接多台设备并向销售客服分配聊天的多客服账户，以及最多 10 个 WhatsApp 频道上的认证标识。 由于它是在应用内购买的，因此属于 Coexistence 号码的应用一侧。Meta 的页面要求企业在订阅前确保企业和账户信息是最新的，并且该页面没有公布固定价格。 ### 更换号码后，标识还会保留吗？ 对于 OBA，Meta 明确记录了一种情况：通过 Embedded Signup 从一个 Solution Partner 迁移到另一个 Solution Partner 的号码，会保留其显示名称、质量评级、消息上限和官方企业账户状态。 对于更换号码本身，没有类似的说明。OBA 属于特定的企业号码，所以换一个号码就是一次新的申请。显示名称获批是 OBA 的条件之一，因此如果要改名，最好在申请之前规划好，而不是之后。 - 把 OBA 和 Meta Verified 当成同一个标识。一个是平台状态，另一个是应用订阅。 - 在平台上注册不满 30 天就申请 OBA。Meta 要求这一最短时间，被拒绝就意味着要等 30 天。 - 在两步验证关闭或显示名称待审核时申请 OBA。这两项都是明确列出的条件。 **Meta Verified 和官方企业账户是一回事吗？** 不是。Meta 分别记录了两者：OBA 是为平台号码申请的状态，Meta Verified 是在应用内办理的订阅。 **Coexistence 号码可以订阅 Meta Verified 吗？** Meta Verified 通过 WhatsApp Business 应用办理，而 Coexistence 号码仍可继续使用该应用。 **注册多久之后才能申请 OBA？** 号码必须已在 WhatsApp Business Platform 上注册至少 30 天。 **如果我的 OBA 申请被拒绝怎么办？** Meta 要求您等待 30 天后再重新提交。 --- ## 多个客服人员和系统同时回复同一个 Coexistence 号码 https://easycoexistence.com/zh-hans/docs/multiple-agents-on-one-number 同一个 Coexistence 号码可以由人员和软件同时回复。员工使用 WhatsApp Business 应用及其已关联设备（主手机之外最多 4 台），系统则使用 Cloud API。人员从应用或配套设备发送的每条消息，都会以 smb_message_echoes Webhook 的形式送达软件，因此双方共用同一个对话。 ### 多人如何回复同一个号码？ 通过已关联设备。WhatsApp 允许一个账户在主手机之外，再在最多 4 台其他设备上使用。该功能发布时就点明了这个用例：小型企业的员工用自己的手机，在同一个 WhatsApp Business 账户下回复客户。 在 Coexistence 号码上这一点依然成立。主手机仍是账户的所有者，其他员工则通过已关联的手机、平板、浏览器或桌面应用工作。支持哪些配套客户端，以及接入流程对它们有何影响，请参阅关于已关联设备的页面。 ### 软件处于什么位置？ 处于同一号码的 API 一侧。CRM、自动化工具或 AI 代理通过 Cloud API 发送消息，并通过 Webhook 接收客户消息，而员工继续使用应用。 两侧是同一条线路，因此无论每条消息由谁撰写，客户看到的都是同一个对话。API 发送的消息会出现在应用的对话中，员工能看到系统已经说过什么。唯一共同的限制是流量：Meta 将同时使用应用和 Cloud API 的号码固定为每秒 20 条消息。 ### 软件如何得知已有人回复？ 靠回声事件。当由合作伙伴接入的企业通过 WhatsApp Business 应用或配套设备发送消息，以及从应用中编辑或删除消息时，Meta 的 smb_message_echoes Webhook 都会触发。 这涵盖号码上的每一位员工，无论是在主手机上输入，还是在已关联的笔记本电脑上输入。读取回声事件的系统可以把对话标记为已由人员处理，并停止自己的回复。这正是辅助团队的自动化与打断团队的自动化之间的区别。 - 从应用或配套设备发送：会收到回声事件。 - 在应用中编辑：会收到回声事件。 - 在应用中删除：会收到回声事件。 ### 双方各自需要注意什么？ 员工要持续使用主手机。主设备大约 14 天不活动，Meta 就会断开 Coexistence 号码的连接；配套设备自身约 30 天不活动，也会被断开。因此只用笔记本电脑办公的团队可能两者都会失去。 软件须遵守平台规则：在 24 小时客户服务窗口内使用自由文本，窗口之外使用模板。此外，双方都无法通过 API 使用群聊，Meta 在与应用共用的号码上不支持群聊。 - 忽略 smb_message_echoes。没有它，机器人无法得知已有人在已关联的笔记本电脑上回复。 - 整个团队都用已关联的笔记本电脑工作，而主手机却闲置数周。 - 接入后关联 WhatsApp for Windows。Meta 将其列为 Coexistence 号码不支持的客户端。 **一个号码最多可以让多少人回复？** WhatsApp 在主手机之外最多允许 4 台已关联设备，每台设备可由不同的人使用。 **已关联笔记本电脑发出的消息会传到我的 CRM 吗？** 会。对于从应用或配套设备发送的消息，Meta 会发送 smb_message_echoes。 **聊天机器人和真人可以共用一个对话吗？** 可以。双方写入同一个对话，机器人可通过回声事件得知有人已回复。 **API 一侧有席位数量限制吗？** Meta 限制的是 API 流量，将共用号码固定为每秒 20 条消息，而不是系统的数量。 --- ## 关联设备与 Coexistence：哪些会被取消关联 https://easycoexistence.com/zh-hans/docs/linked-devices-and-coexistence 将 WhatsApp Business 应用号码接入 Cloud API 时，该账户下的所有伴随设备都会被取消关联。受支持的伴随设备，例如 WhatsApp Web 和作为伴随设备关联的手机，之后可以重新关联。Coexistence 号码不支持 WhatsApp for Windows 和 WhatsApp for WearOS，而闲置约 30 天的伴随设备会断开连接。 ### 接入期间，已关联的设备会怎样？ 它们都会被登出。Meta 的文档说明，企业使用现有的 WhatsApp Business 应用账户和号码接入 Cloud API 后，该账户下的所有伴随应用都会被取消关联，之后企业可以重新关联任何受支持的伴随应用。 这不会造成任何损失：主手机仍保留账户及其对话。但在浏览器或第二部手机上回复客户的前台人员，会在接入完成的那一刻被登出，因此最好在扫描二维码之前告知团队，而不是事后再说。 ### 之后支持哪些伴随设备？ 除两种之外，全部支持。Meta 列出的所有伴随客户端都支持在 Coexistence 号码上使用，只有 WhatsApp for Windows 和 WhatsApp for WearOS 除外。每个受支持的设备都按常规方式重新关联，即用主手机扫描二维码，并与之前计入同一个设备数量上限。 - 浏览器中的 WhatsApp Web：支持，用二维码重新关联。 - 作为伴随设备关联的其他手机：支持。 - WhatsApp for Windows：不支持。 - 手表上的 WhatsApp for WearOS：不支持。 ### 最多可以关联多少台设备？ 除主手机外，最多四台。WhatsApp 在宣布手机支持多设备时提到，可将一部手机作为最多四台附加设备之一进行关联，与网页浏览器、平板电脑和桌面设备相同，并指出其用途是让小型企业的员工用自己的手机回复客户。 在 Coexistence 号码上，这个上限由仍受支持的伴随客户端共用。以前使用 Windows 应用的办公室，通常会把这些工位改用浏览器中的 WhatsApp Web，它和其他伴随设备一样，占四台名额之一。 ### 什么能让已关联的设备保持连接？ 两条闲置规则，分别对应两类设备，两者都会作为原因出现在 Meta 的断开数据中。 PRIMARY_INACTIVITY 针对主手机，在大约 14 天没有活动后触发。WhatsApp 还指出，当主设备长时间闲置时，会将账户从所有伴随设备登出，因此一部不用的主手机会让所有已关联的设备一同下线。 COMPANION_INACTIVITY 单独针对某台伴随设备，在闲置约 30 天后触发。分公司里一台很少使用的笔记本电脑就是典型情况。 - 接入前没有通知使用 WhatsApp Web 回复消息的员工。接入完成时，他们会被登出。 - 重新关联 WhatsApp for Windows 应用。Meta 列出它在 Coexistence 号码上不受支持。 - 因为大家都用已关联的设备工作，就把主手机丢在抽屉里。它的闲置也会让伴随设备断开。 **Coexistence 会取消 WhatsApp Web 的关联吗？** 会，接入时所有伴随设备都会被取消关联。WhatsApp Web 受支持，可以立即重新关联。 **我可以在 Windows 上使用 WhatsApp 桌面应用吗？** Coexistence 号码不支持。Meta 将 WhatsApp for Windows 列为不受支持的伴随设备。 **Coexistence 本身是一台已关联的设备吗？** 不是。它是通过 Meta 的接入流程附加到号码上的 Cloud API，不占用伴随设备名额。 **我可以关联多少台伴随设备？** 除主手机外，最多四台，范围限于 Meta 支持的伴随客户端。 --- ## 更改 Coexistence 连接上的电话号码 https://easycoexistence.com/zh-hans/docs/changing-the-phone-number 一个 Coexistence 连接对应一个电话号码。当企业在 WhatsApp Business 应用中更改号码时，Meta 会断开该连接，原因为 CHANGE_NUMBER。新号码是平台上另一个独立的企业电话号码，必须通过 Coexistence 流程作为新连接重新接入。 ### 号码更改后，连接会怎样？ 连接会终止。Meta 将更改电话号码列为 Coexistence 连接被断开的原因之一，并在 account_update Webhook 的 disconnection_info 中以 CHANGE_NUMBER 作为原因报告。 这是平台逻辑一致，而不是要求苛刻。API 端所知道的一切都以企业电话号码为键：它的 phone number ID、显示名称、质量评级和 Webhook 订阅。不同的号码就是不同的资产，因此旧号码上的任何内容都不会自动转移，旧连接在更改号码的那一刻就会失效。 ### 如何连接新号码？ 按首次连接处理。新号码必须满足与任何加入 Coexistence 的号码相同的条件，然后从头开始接入。旧连接中的任何内容都不会被沿用，因此最好把这次切换当作一个有日期的小项目来安排。 - 该号码已在 WhatsApp Business 应用中启用，且应用版本为 2.24.17 或更新。 - 该号码位于您管理的 Business Portfolio 中。 - 该号码未绑定到其他提供商。 - 注册时需提供其显示名称，与任何企业电话号码相同。 ### API 端需要更新哪些内容？ 所有存放了旧号码或其 ID 的地方。通过 Cloud API 发送消息的集成使用的是 phone number ID，因此仍指向旧 ID 的 CRM、自动化工作流或 AI 代理会失败，而不会自动切换。 新连接还会重新开始自己的接入设置问题，包括是否共享聊天记录，以及用于同步记录的 24 小时窗口。旧连接上设置的 Webhook 目标需要重新应用到新连接。Business Portfolio 的容量也值得检查：在通过验证或达到 2,000 条消息上限之前，Meta 将新 business portfolio 限制为两个已注册的企业电话号码。 ### 旧号码在平台上会怎样？ 它会一直留在 WhatsApp Business 账户中，直到有人将其移除。Meta 只允许 business portfolio 管理员删除企业电话号码，并且会拒绝删除过去 30 天内用于发送付费消息的号码。 删除只是可选的整理工作，不是连接新号码的前提条件，但账户中留着过期号码，系统很容易继续向错误的号码发送。30 天期限过后将其移除，可以让账户保持清晰易读。 - 在规划重新连接之前就在应用中更改号码。旧连接在那一刻就会终止。 - 在集成中保留旧的 phone number ID。发送会失败，而不会转到新号码。 - 在切换后立即尝试删除旧号码。如果该号码在 30 天内发送过付费消息，Meta 会阻止删除。 **连接会跟随我的新号码吗？** 不会。Meta 会以 CHANGE_NUMBER 为原因断开连接，新号码需要作为新连接接入。 **我需要新的 phone number ID 吗？** 需要。新号码是平台上另一个独立的企业电话号码，拥有自己的 ID。 **我可以立即删除旧号码吗？** 只有在过去 30 天内未发送过付费消息时才可以，而且只有 portfolio 管理员能删除。 **我需要重新选择显示名称吗？** 需要。注册企业电话号码时，Meta 要求提供显示名称信息。 --- ## Meta 企业验证与 Coexistence 号码 https://easycoexistence.com/zh-hans/docs/business-verification Meta 企业验证适用于 Meta Business Portfolio，而不是某个电话号码。未经验证的 Business Portfolio 也可以发送消息，起始上限为每天 250 个唯一收件人，可注册 2 个号码。验证是升至 2,000 上限的途径之一，会把号码数量上限提高到 20，也是申请蓝色勾选标记之前的必要条件。 ### 连接号码是否必须先完成企业验证？ 不必。Meta 的文档把验证视为提升 Business Portfolio 能力的方式，而不是发送消息的前提条件。 新建的 Business Portfolio 起始消息发送上限为：在客户服务窗口之外，每滚动 24 小时 250 个唯一收件人，并且最多注册 2 个商业电话号码。无论是否通过验证，这两项限制都一样，企业从第一天起就可以在这些限制内向客户发送消息。 验证改变的是上限。Meta 列出了三条把发送上限从 250 提高到 2,000 的途径，验证是其中之一；它也是把已注册号码数量上限提高到 20 的两个触发条件之一。 ### 验证能在 WhatsApp 上解锁什么？ 三件互相独立的事，常被说成一件事。 - 发送上限途径：验证是获得 2,000 资格的方式之一，之后由 Meta 的自动扩容接管。 - 更高的号码数量上限：Meta 会把 Business Portfolio 的已注册号码从 2 个提高到 20 个，并发送 business_capability_update Webhook。 - 官方商业账户资格：拥有该号码的 Business Portfolio 必须先通过验证，才能申请蓝色勾选标记。 - 这三项都不会改变 WhatsApp Business 应用在手机上的使用方式。 ### 验证如何适用于 Coexistence 号码？ 通过 Business Portfolio 适用。通过 Coexistence 连接的号码位于某个 WhatsApp Business 账户中，该账户属于一个 Meta Business Portfolio，而验证是这个 Business Portfolio 的属性。其中的每个号码都共享验证结果，也共享该 Business Portfolio 的消息发送上限。 蓝色勾选标记的范围更窄。Meta 的官方商业账户页面说明，不会向 WhatsApp Business 应用的电话号码等授予该状态，也没有单独说明同时用于应用和 Cloud API 的号码。其他资格条件包括：通过验证、在平台上至少 30 天、号码已启用两步验证，以及显示名称已获批准。 ### 应该验证哪个 Business Portfolio？ 验证拥有该 WhatsApp Business 账户的那一个。企业连接自己的号码时，应当使用企业自己的 Business Portfolio。 这对代理机构尤其重要。如果客户的号码连接在代理机构的 Business Portfolio 中，适用的就是代理机构的验证、发送上限和号码数量上限，客户的上限还要与代理机构在其中持有的所有其他号码共享。Meta 明确指出，在特定时段内，一个号码可能耗尽整个 Business Portfolio 的消息发送能力。 把每家企业连接到它自己的 Business Portfolio，验证、上限和计费就都留在实际发送消息的企业手中。 - 等验证完成才连接。没有验证也可以发送消息，只是受起始上限限制。 - 验证了错误的 Business Portfolio，而不是拥有 WhatsApp Business 账户的那一个。验证结果无法转移。 - 把多个客户的号码放在同一个代理机构 Business Portfolio 中。它们共享同一个消息发送上限和号码数量上限。 **使用 Coexistence 需要企业验证吗？** 不需要。Business Portfolio 未经验证也可以发送消息，起始上限为每滚动 24 小时 250 个唯一收件人。 **验证后就能获得蓝色勾选标记吗？** 不能单靠验证。它只是官方商业账户状态的条件之一，该状态需要单独申请，并由 Meta 审核。 **验证是按号码进行的吗？** 不是。验证属于 Meta Business Portfolio，该 Business Portfolio 中的每个号码都共享验证结果。 **验证会改变我手机上的应用吗？** 不会。验证改变的是平台上限和资格，不会改变 WhatsApp Business 应用的行为。 --- ## WhatsApp 消息限制：当前的 Business Portfolio 等级 https://easycoexistence.com/zh-hans/docs/messaging-limits-and-tiers 消息限制规定了企业在移动 24 小时内，可在客户服务窗口之外向多少个不同的用户发送消息。自 2025 年 10 月 7 日起，该限制按 Meta Business Portfolio 设置，由其中所有号码共用，起始值为 250，依次升至 2,000、10,000、100,000 和不限。 ### 消息限制到底统计什么？ 统计的是在移动 24 小时内，您的企业在客户服务窗口之外发送消息所触达的不同 WhatsApp 用户号码数。这一表述带来三点结论。 在已开启的客户服务窗口内回复不计入限制，因此只回复主动来信用户的号码，可以远高于其限制运行，也不会触及限制。向同一个人发送多条模板，该用户只计一次。此外，这个窗口是滚动的，而不是自然日，所以最早的发送记录过期后，额度会逐步释放。 限制衡量的是您首次触达多少人，而不是发送速度或发送总量。 ### 2025 年 10 月有什么变化？ 2025 年 10 月 7 日之前，每个手机号码都有各自的限制，新号码无论同一组合中的其他号码已达到什么水平，都从 250 起步。此后，限制归属于 Business Portfolio，其中所有号码共用同一个限制。 - 新注册的号码会立即共用该 Business Portfolio 的限制。 - 250 之后的第一级是 2,000，以前是 1,000。 - 满足条件后 6 小时即可提升，此前为 24 小时。 - 号码质量评级下降不再导致限制被降级。 - 应读取的字段是 whatsapp_business_manager_messaging_limit，messaging_limit_tier 已弃用。 ### 限制如何提升？ 分两个阶段。要脱离 250 这一级，Business Portfolio 需完成一条扩容路径：验证企业、由接入合作伙伴验证企业，或在 30 天内使用高质量评级的模板，在客户服务窗口之外向不同的收件人发送 2,000 条消息。随后 Meta 会审核消息质量并批准或拒绝，若被拒绝，会通过 account_alerts Webhook 告知可以采取的替代路径。 从 2,000 起，扩容是自动的。当 Business Portfolio 下所有号码和模板都在发送高质量消息，且在过去 7 天内至少用掉当前限制的一半时，Meta 会将其提升一级。无需付费购买，也无需提交申请。 ### 消息限制与吞吐量有何不同？ 限制统计的是每天触达的人数，吞吐量统计的是每秒发送的消息数。两者分别设置，也分别出现故障。 在 Coexistence 号码上，这一差别尤为明显。对于同时在 WhatsApp Business 应用和 Cloud API 上使用的号码，Meta 将吞吐量固定为每秒 20 条消息，以保持与应用的兼容。这个数值不会随 Business Portfolio 的等级变化，因此即使消息限制为不限，Coexistence 号码的发送速度仍然是每秒 20 条。 每秒限制、每个收件人的限制以及管理调用限制，各有自己的页面和错误代码。 - 读取 messaging_limit_tier。该字段已弃用，当前字段是 whatsapp_business_manager_messaging_limit。 - 以为每个新号码都从 250 起步。自 2025 年 10 月起，新号码会立即继承 Business Portfolio 的限制。 - 把回复计入限制。已开启的客户服务窗口内的消息不属于限制范围。 - 让某一个号码的营销活动耗尽其他号码的额度。整个 Business Portfolio 共用同一个限制。 **限制是按号码还是按账户计算？** 自 2025 年 10 月 7 日起按 Meta Business Portfolio 计算，其中所有号码共用同一个限制。 **客户的回复会计入我的限制吗？** 不会。只有在客户服务窗口之外的发送才会计入，每个不同的收件人在移动 24 小时内只计一次。 **质量评级较低会降低我的限制吗？** 自 2025 年 10 月起不会。Meta 已不再因质量下降而降级限制，但质量仍决定限制能否提升。 **更高的等级会提高 Coexistence 的吞吐量吗？** 不会。无论处于哪个等级，Coexistence 号码的吞吐量都固定为每秒 20 条消息。 --- ## Coexistence 号码上的产品目录 https://easycoexistence.com/zh-hans/docs/catalog-and-coexistence 通过 Coexistence 连接号码后，WhatsApp Business 应用中的目录、订单和状态工具在应用内保持不变，而 Cloud API 不开放这些应用工具。通过 API 发送的产品消息，使用的是上传到 Meta 并连接到 WhatsApp Business Account 的目录，并按号码进行配置。 ### 我的 WhatsApp Business 应用目录在 Coexistence 之后还在吗？ 在，手机上依然可用。Meta 的 Coexistence 功能对照表将目录、订单和状态列为商业工具的示例，接入之后，它们在 WhatsApp Business 应用中的使用方式没有变化。 同一行也标明这些工具在 Cloud API 上不受支持。这是需要提前规划的部分：集成不应期望通过 API 读取、编辑或同步应用的目录工具。 因此，通过应用目录销售的商家在连接之后可以照常销售。变化之处在于，商家同时获得了 API，并可使用其独有的产品发送方式。 ### 产品目录如何通过 Cloud API 运作？ 通过上传到 Meta 并连接到 WhatsApp Business Account 的目录。目录是产品或服务的结构化清单，每个条目包含名称、描述、价格、图片和库存状态等详情。Meta 将其分为四个阶段。 - 上传库存，可通过 Commerce API 或 Meta Commerce Manager 完成。 - 按号码配置商务设置：是否启用购物车，以及目录是否可见。 - 通过目录、单产品、多产品或轮播消息分享产品。 - 客户的回应，会以 Webhook 通知的形式送达，其中包含订单详情和产品咨询。 ### 应用中的产品消息与通过 API 发送的有何不同？ Meta 记录了一处可见的差异：与从 WhatsApp Business 应用发送的产品消息不同，通过 Cloud API 发送的消息目前不会在聊天窗口标题栏显示购物车图标。 API 一侧还有应用没有以同样方式开放的设置。默认情况下，账户下每个商业号码都启用购物车并隐藏店面图标，两者都可以通过商务设置端点按号码切换。停用目录后，点击 wa.me 目录链接和“查看目录”按钮时，会显示目录无效的警告。 在客户服务窗口之外，产品仍须放在已获批准的模板中发送，与其他由商家发起的消息相同。 ### 谁来审核产品？ 由 Meta 自动审核。添加到已连接 WhatsApp Business Account 的目录中的商品都会被审核，违反政策的商品会被标记，并提示商家查阅 WhatsApp 商务政策。被拒的商品可以在 Meta Commerce Manager 中申诉。 客户也可以举报他们在消息中收到的某个具体产品，这会触发单独的审核。针对商家本身的举报则是另一回事：它们是 Meta 评定号码质量评级的信号之一。 印度的商家另有义务遵守网络销售法规，Meta 通过其 Business Compliance API 提供相关功能。 - 期望通过 API 读取应用的目录工具。Meta 将其列为 Cloud API 不支持。 - 在 wa.me 目录链接仍在流传时停用号码的目录。这些链接随后会显示目录无效的警告。 - 在客户服务窗口之外不使用模板发送产品。由商家发起的消息仍然需要模板。 **连接后会删除我的目录吗？** 不会。Meta 将应用的商业工具（包括目录）列为 Coexistence 接入后保持不变。 **API 能读取我的应用目录吗？** Meta 标明应用的商业工具在 Cloud API 上不受支持。API 产品消息使用连接到 WhatsApp Business Account 的目录。 **一条消息最多能放多少个产品？** 多产品消息最多 30 个，并按分区组织。 **我可以关闭购物车吗？** 可以，通过商务设置端点按号码关闭。购物车默认启用。 --- ## Coexistence 之后的广播列表与营销模板 https://easycoexistence.com/zh-hans/docs/broadcast-lists-vs-templates 号码通过 Coexistence 连接后，WhatsApp Business 应用中的广播列表会变为只读，也无法再创建新的列表。API 上的对应做法是向每位收件人发送营销模板：它需要用户事先明确同意，计入 Business Portfolio 的消息发送限额，由 Meta 收费，并遵循每个人的营销偏好设置。 ### 在 API 上用什么取代广播列表？ 一个经批准的营销模板，通过 Cloud API 向每位收件人各发送一次。API 端没有列表对象：受众由集成方自行保存，再把模板发给其中的每个号码。 这会同时带来三个变化。内容必须先通过 Meta 的模板审核才能发送。在客户服务窗口之外，每次发送都会开启一次对话，由 Meta 向企业自己 WhatsApp Business 账户上的付款方式收费。每位不重复的收件人还会计入 Business Portfolio 在滚动 24 小时内的消息发送限额。 广播列表被停用本身，以及 Meta 给出的原因，请参阅介绍 Coexistence 所关闭功能的页面。 ### 谁可以接收营销模板？ 向企业提供了号码，并明确同意接收其消息的人。Meta 的 Business Messaging Policy 对这两个条件都有明确要求，而且同意声明必须写明企业名称，并说明对方同意接收该企业的消息。 只要符合这些要求和适用法律，Meta 不限定获取同意的方式：短信、网站表单、IVR 电话或签署的纸质表格都在其列举的示例中。因此，同意的证据应保存在企业自己的记录里，而不是手机通讯录中。 向从未同意的人发送消息，也是招致屏蔽和举报的最快途径，而这正是质量评级下降的原因。 ### 为什么有些营销模板没有送达？ 因为 API 会对每位收件人单独施加控制，而广播列表从未显示过这些控制。 - 每位用户的营销限制：WhatsApp 可能暂缓向参与意愿较低的用户发送营销模板，并返回 131049。 - 已停止营销：用户可以在“优惠和公告”设置中停止接收该企业的营销消息，此时返回 131050。 - 美国号码：WhatsApp 目前不会向使用美国电话号码的用户投递营销模板。 - 例外地区：每位用户的限制目前在 EEA、英国、日本和韩国尚未生效。 ### 应用自带的营销消息工具还能用吗？ Meta 的 Coexistence 功能对照表把应用的消息工具归在同一行，列出了营销消息、问候消息、离开消息、快速回复和标签，并注明接入后它们在 WhatsApp Business 应用中没有变化。同一行也标明，这些工具在 Cloud API 上不受支持。 因此，应用的营销消息功能与 API 营销模板，是同一号码上两条各自独立的途径。Meta 还说明，接入后从 WhatsApp Business 应用发送的消息仍然免费，而通过 Cloud API 发送的消息按 Cloud API 的定价计费。 广播列表是唯一发生变化的例外，所以才需要替代方案。 - 收到 131049 后立即重试。Meta 要求至少等待 24 小时，过早重试可能导致后续尝试被阻止长达一天。 - 收到 131050 后重试。该用户已停止接收企业的营销消息，消息不会送达。 - 把广播列表直接导入为同意名单。保存过号码，并不等于政策所要求的明确同意。 **我的广播列表会被删除吗？** 不会。现有广播列表会变为只读，号码保持连接期间也无法创建新的列表。 **向广播受众发消息需要使用模板吗？** 在客户服务窗口之外，需要。营销模板是 API 上由企业主动发起推广的途径。 **为什么模板发送失败并返回 131050？** 该收件人已选择不再接收您企业的营销消息。Meta 表示不应重试。 **应用的营销消息功能不能用了吗？** Meta 将应用的消息工具（包括营销消息）列为接入后在应用中保持不变。 --- ## WhatsApp 企业主动发起消息的选择加入要求 https://easycoexistence.com/zh-hans/docs/opt-in-requirements 企业在 WhatsApp 上向某人发消息之前，Meta 的政策要求满足两点：对方已将手机号码提供给企业，且企业已收到对方的选择加入，确认愿意接收其消息。自 2024 年 11 月起，选择加入可以是通用的，不必专门针对 WhatsApp，但必须写明企业名称并遵守当地法律。 ### Meta 的选择加入政策有哪些要求？ 企业在 WhatsApp 上联系某人之前，必须同时满足两项条件。第一，对方已将手机号码提供给企业。第二，企业已获得对方的选择加入许可，确认对方愿意接收企业后续发来的消息或来电。 选择加入本身有三项要求。必须清楚说明对方同意接收该企业的联系。必须清楚写明企业名称。还必须遵守适用法律，而如何判断则完全由企业自行负责，Meta 不作判断。 Meta 在 2024 年 11 月的政策更新中放宽了一点：选择加入可以是通用的，不必提及 WhatsApp，只要遵守当地法律即可。 ### Meta 接受哪些选择加入方式？ 只要符合上述三项要求，任何方式都可以。Meta 表示，这样的方式符合政策，具体选择由企业决定，并列出了一些受支持的方式。无论采用哪一种，Meta 还建议向对方说明接收这些消息能得到什么好处。 - 短信。 - 网站表单。 - 电话，通过互动语音应答流程。 - 当面或纸质形式，使用签署的实体文件。 - 无论采用哪种方式，企业都有责任发出适用法律要求的通知并取得相应许可。 ### WhatsApp Business 应用中的联系人算选择加入吗？ 单靠这一点不算。Meta 的政策把许可与对方确认愿意接收企业消息联系在一起，而通讯录里的一个号码，最多只满足两项条件中的第一项。 这一点对 Coexistence 号码尤其重要，因为连接可以同步应用中的联系人，而现有客户群显然是首次消息模板营销活动的目标受众。拥有对方的号码，不等于拥有对方的确认。 主动给企业发消息的客户则是另一种情况：对方的消息会开启客户服务窗口，企业可以在窗口内回复。 ### 选择加入做得不扎实会怎样？ 收件人会表达不满，而平台会对这些反馈作出反应。Meta 的选择加入指南指出，用户可以屏蔽或举报企业，或停止接收其营销消息，如果企业的质量评级长期偏低，Meta 的系统会对其限制发送速率。 Meta 的实用建议由此而来。通过说明企业将发送的消息类别来设定预期，或按类别分别收集选择加入。清楚说明如何退出特定类别，并予以遵守。让选择加入和退出流程一目了然，并在新的选择加入方式上线时密切关注质量评级。 政策还要求遵守每一项屏蔽、停止或退出请求，无论是否在 WhatsApp 上提出，包括将该用户从联系人名单中移除。 - 把同步的应用联系人当作选择加入名单。政策要求的是每个人的确认，而不仅仅是号码。 - 收集选择加入时没有写明企业名称。Meta 要求清楚写明企业名称。 - 只在退出请求通过 WhatsApp 送达时才遵守。政策涵盖通过任何渠道提出的请求。 **选择加入必须提及 WhatsApp 吗？** 不必。自 2024 年 11 月政策更新后，允许通用的选择加入，前提是遵守当地法律。 **回复先发消息的客户，需要选择加入吗？** 客户的消息会开启客户服务窗口，窗口内允许回复。选择加入约束的是企业主动发起的消息。 **选择加入可以线下收集吗？** 可以。Meta 在接受的方式中列出了当面或纸质形式，并使用签署的文件。 **有人选择退出时应该怎么做？** 停止向对方发消息，无论对方通过什么渠道提出，并按政策要求将其从您的联系人名单中移除。 --- ## 屏蔽与举报如何影响 WhatsApp 质量评级 https://easycoexistence.com/zh-hans/docs/quality-rating-blocks-and-reports 消息质量根据收件人过去 7 天对企业消息的反馈来评判，近期反馈权重更高。信号包括屏蔽、举报、静音、归档，以及用户屏蔽时给出的原因。质量持续偏低会导致发送受限、发送时出现错误 131048，以及消息模板被暂停。 ### 哪些反馈会降低 WhatsApp 质量评级？ Meta 直接列出了这些信号：屏蔽、举报、静音、归档，以及用户屏蔽企业时给出的原因。质量依据过去 7 天消息的接收情况评估，并按时间远近加权，因此昨天一次糟糕的发送比 6 天前的影响更大。 由此有两点结果。一次定位不当的群发活动就可能让评级迅速变化，Meta 也指出，流量大的号码通常在几分钟内就会出现质量变化。另外，由于评估只涵盖最近 7 天，更早的反馈不再计入。 消息模板也有各自的评级，依据反馈和阅读率得出，与号码的评级并行。 ### 质量下降会怎样？ 会有几方面的影响，层级各不相同。 - 发送可能失败并返回 131048，Meta 将其归因于过多消息被屏蔽或被标记为垃圾信息。 - 评级为 YELLOW 或 RED 的消息模板仍可发送，但有被暂停或停用的风险。 - 质量会影响消息模板的发送节奏，可能拖慢一次群发活动的送达速度。 - 政策允许 WhatsApp 根据屏蔽和举报情况，限制企业可发送的消息数量。 - 自 2025 年 10 月 7 日起，质量下降不再降低 Business Portfolio 的消息上限，但可能使上限无法提升。 ### 如何恢复较低的质量评级？ 先止住负面反馈的来源，再等 7 天窗口滑过这些反馈。 Meta 的高质量消息指南就是检查清单。只向已选择接收该企业消息的人发送。让消息个性化且有用。避免开放式的欢迎或介绍消息。避免每天发送过多消息。内容和长度都要精炼。 实际操作中，这意味着暂停正在招来屏蔽的活动或消息模板，检查它发给了哪个受众群体，并核对该受众给出的同意。Meta 自己的指引建议按消息类别分别收集同意，正因为意料之外的类别正是人们会屏蔽的对象。 ### 质量评级在哪里显示？ 在 WhatsApp Manager 的“账户工具”下的“号码”中，与号码状态和消息上限一同显示；也可通过 Graph API 在号码对象上以 quality_rating 读取。消息模板的评级位于每个消息模板的 quality_score 字段，在“管理模板”面板中显示为高、中、低或质量待定。 手机上的 WhatsApp Business 应用完全不会显示这些信息，所以 Coexistence 号码的质量可能在店里没人察觉时就一路下滑。尽管字段名如此，phone_number_quality_update Webhook 并不传递该评级，我们另有一页专门说明这个 Webhook 实际传递什么。 - 向刚导入的名单发送开放式欢迎消息。Meta 明确将其列为应避免的做法，它会招来屏蔽。 - 对返回 131048 而失败的发送反复重试。限制针对的是号码，更多发送只会加重造成限制的反馈。 - 只盯着号码的评级。消息模板有自己的评级，号码看似正常时，RED 模板也可能已被暂停。 **一次屏蔽会降低我的评级吗？** Meta 没有公布阈值。质量反映的是过去 7 天消息所获得的整体反馈，且近期反馈权重更高。 **评级偏低会降低我的消息上限吗？** 自 2025 年 10 月 7 日起不会。但它仍可能阻止上限提升，并限制发送。 **恢复需要多久？** Meta 没有公布恢复时间。评估涵盖最近 7 天，所以更早的反馈不再计入。 **静音的聊天也算吗？** 算。Meta 将静音和归档与屏蔽、举报并列为质量信号。 --- ## GDPR 与 Coexistence：消息数据去向何处 https://easycoexistence.com/zh-hans/docs/gdpr-and-coexistence 号码通过 Coexistence 连接后，其消息会在 WhatsApp Business 应用与 Cloud API 之间镜像同步。Meta 表示，就 Cloud API 而言，它是企业的数据处理者，消息最多保留 30 天，并要求每家企业自行履行 GDPR 义务。 ### 号码使用 Coexistence 后，消息数据有什么变化？ 对话除了在手机上可见，Cloud API 也能看到。Meta 的 Coexistence 文档指出，收发的消息会在 Cloud API 与 WhatsApp Business 应用之间镜像，拥有 WhatsApp 号码的联系人可以同步，最近 6 个月的聊天消息可在接入期间同步。群聊不会同步。 从此时起，该号码的一对一消息会经由 Cloud API 传输。Meta 的描述是：收到消息后先解密再转发给企业，发出的消息则在投递前使用 Signal 协议加密。 本页陈述的是 Meta 的文档内容以及 EasyCoexistence 的做法，不构成法律意见。具体配置是否符合 GDPR，应由企业及其顾问判断。 ### Meta 如何说明自己在 GDPR 下的角色？ Meta 的 Cloud API 数据隐私页面用自己的话阐述了立场。 - 在法律承认数据处理者的情形下，Meta 提供 Cloud API 时是企业的数据处理者。 - 除非另有指示，Cloud API 仅代表企业并按企业的指示使用其处理的消息。 - 消息最多保留 30 天；用户标识符会在消息最后一次状态更新后 30 天内删除。 - Cloud API 客户必须自行履行 GDPR 等法律规定的义务。 - 欧洲地区的客户适用 WhatsApp Business Data Transfer Addendum。 ### 消息数据可以存储在欧盟吗？ Meta 提供 Cloud API 本地存储：在短暂的使用期之后，消息内容会静态存放在所选国家。对 Cloud API 而言，该使用期最长 60 分钟，期间内容可能在 Meta 的国际数据中心处理。欧洲的选项是：德国（对应欧盟）、瑞士和英国。 本地存储在号码注册时设置，已注册号码要更改，就必须先取消注册再重新注册。Meta 的注册文档还指出，同时用于 Cloud API 和 WhatsApp Business 应用的号码不能使用取消注册端点，也没有说明在 Coexistence 号码上启用本地存储的单独途径。 ### 经过 Meta 之后，消息去向何处？ 去向接收该 WhatsApp Business 账户 Webhook 的任何端点。Meta 的 Webhook 覆盖功能允许应用把某个账户的 Webhook 发送到与应用自身不同的回调 URL。 EasyCoexistence 利用该覆盖功能，把消息事件指向企业自己的系统，因此 Meta 将对话内容直接投递到那里，而不是我们这里，EasyCoexistence 也从不存储对话内容。我们保留的是运营事件，例如连接状态和质量，监控正是由这些构成。 Meta 还说明，Cloud API 拥有 SOC 2 Type II 和 ISO 27001 报告，并通过其 Business Messaging Compliance Center 发布。 - 以为 Meta 的处理者角色涵盖了企业自身的义务。Meta 明确表示，客户必须履行自己的 GDPR 义务。 - 接受历史记录同步，却没有决定它落在哪里。最多 6 个月的聊天可能被投递到接收系统。 - 打算以后再开启本地存储。它在注册时设置，更改就意味着重新注册。 **对于 Cloud API，Meta 是处理者还是控制者？** Meta 表示，在法律承认该概念的情形下，就 Cloud API 而言，它是企业的数据处理者。 **Meta 会保留消息内容多久？** Meta 表示，Cloud API 消息的最长保留期限为 30 天，用于重传等功能。 **EasyCoexistence 会看到我的对话吗？** 消息事件由 Meta 直接路由到您自己的系统，EasyCoexistence 从不存储对话内容。 **本页内容是法律意见吗？** 不是。本页陈述 Meta 的文档内容和 EasyCoexistence 的做法。合规与否，应由企业及其顾问评估。