# EasyCoexistence: 繁體中文 (zh-hant) 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-hant/whatsapp-mcp-server MCP 伺服器讓 AI 助手直接使用 WhatsApp：列出您的號碼、傳送訊息及範本、檢查健康狀態，並將 Webhook 指向您的系統。EasyCoexistence 在 Meta 的官方 Cloud API 上運作，因此客戶現時傳訊息至的號碼仍然是官方號碼，不會有被封鎖的風險。 ### 甚麼是 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 實際可以用它做甚麼？ 十六項工具，對應人們實際會提出的要求。 讀取：列出您帳戶內的號碼，檢查某個號碼的健康狀態，包括品質評級、訊息層級及連接狀態；當您需要在其他地方使用 API 憑證時，也可以讀取這些憑證。 傳送：在 24 小時工作階段內傳送訊息；列出該號碼的範本、建立新範本、檢查 Meta 是否已批核範本，以及向工作階段以外的對話傳送已批核範本。 接線：設定 Webhook 目的地，讓傳入訊息由 Meta 直接轉送至您自己的伺服器。也可以開始連接，取得客戶開啟後用來連接其號碼的連結。此外還有文件工具，讓助手查閱運作方式，而不是自行猜測。 最後兩項功能令它不只是一個聊天玩具。代理程式可以啟用號碼並將它指向您的系統，而毋須人手開啟控制台。 Partner API：當您自己的軟件讓其客戶連接自己的號碼時，另外五項工具負責設定託管連接連結。它們可查看設定狀態、建立或撤銷 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-hant/whatsapp-coexistence Coexistence 是 Meta 的官方模式，讓 WhatsApp Business 應用程式與 Cloud API 同時使用同一號碼。團隊仍可用電話回覆，保留相同聊天及歷史記錄，同時由軟件在同一條線路上傳送及接收訊息。無需遷移，也無需更換號碼。 ### Coexistence 實際解決了甚麼問題？ 在這項功能出現之前，把企業號碼連接至 WhatsApp API，意味著必須放棄應用程式。號碼會被遷移，電話不再能作為 WhatsApp 用戶端，而原本整天回覆客戶的人，突然要改用所購買的軟件處理。大部分小型團隊不願接受這種取捨，因此一直沒有自動化。 Coexistence 消除了這項取捨。應用程式維持原有運作方式。同一個人繼續用同一部電話回覆，查看相同對話，無需學習新操作。同時，API 連接至同一號碼，可以傳送、接收訊息，並接入其他系統。 因此，問題不再是是否放棄電話，而是您希望軟件處理甚麼，以及人員何時接手同一段對話。 ### 連接後，電話上會有甚麼變化？ 幾乎沒有變化，而這正是重點。應用程式以相同方式開啟，聯絡人清單不變，舊有對話也全部保留。沒有人需要在新的地方登入。 電話上看不見的地方才會改變。API 傳送的訊息會出現在應用程式的對話串中，讓回覆人員看到完整情況，而不是只看到一半。於應用程式輸入的訊息也會讓 API 看見，軟件便不會在人工回覆後再次回覆。 號碼首次連接時，Meta 會同步約 6 個月的歷史記錄，因此 API 不會在毫無背景資料的情況下開始運作。開始前值得知道兩項限制：所有供應商的 Coexistence 號碼都無法讓 API 使用群組聊天，而號碼也不能使用 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 需要 Business 應用程式，號碼必須先移至該應用程式。 - 假設群組聊天會傳送過來。所有供應商的 Coexistence 號碼都不支援 API 使用群組聊天，因此任何以群組為核心的功能都無法運作。 - 在客戶上次訊息超過 24 小時後，仍以自由文字回覆。超過這段時間後，只有已核准的訊息範本可以傳送。 - Webhook 仍指向無法回應 Meta 驗證請求的 URL。Meta 會在傳送任何內容前檢查端點，而無聲失敗與正常設定看起來完全相同。 **我的團隊是否必須停止使用電話？** 不用。這正是 Coexistence 的全部意義。WhatsApp Business 應用程式會在同一號碼上繼續運作，保留相同對話，而 API 同時在旁運作。 **我會失去現有對話嗎？** 不會。對話會留在應用程式內，而號碼連接時，Meta 會將約 6 個月的歷史記錄同步至 API，因此軟件能掌握背景，不會從空白開始。 **可以取消嗎？** 可以。號碼可以中斷連接，而應用程式會如常繼續運作。連接不會永久改變號碼本身。 **這是否與非官方 WhatsApp API 相同？** 不是，而兩者的差異會決定號碼能否保留。Coexistence 是 Cloud API 上的 Meta 官方功能。非官方閘道會把 WhatsApp Web 當作已連接裝置使用，違反條款，並導致號碼被封鎖。 --- ## 非官方 WhatsApp API：號碼究竟為何被封鎖 https://easycoexistence.com/zh-hant/unofficial-whatsapp-api-risks 非官方 WhatsApp API 透過以已連接裝置登入，並自動化 WhatsApp Web 會話運作。這違反 WhatsApp 條款，Meta 會偵測相關模式，令號碼被封鎖。官方 Cloud API 則透過 Meta 支援的介面，在企業已使用的號碼上完成相同工作。 ### 非官方 WhatsApp API 如何運作？ 不論宣傳如何說，所有這類 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-hant/integrations/n8n 將 Webhook 目的地指向 n8n Webhook 節點，發送至該號碼的每則訊息都會成為工作流程觸發程序。回覆會經由 Cloud API，或經由我們的 MCP 伺服器傳送。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 和存取權杖。兩者都可從控制台讀取，或者如果您希望由助理提取，也可透過 MCP 連接器讀取。 要傳送的內容取決於時間，這正是最容易出錯的地方。在客戶最後一則訊息後 24 小時內，可以使用自由格式訊息，回覆內容由工作流程組成。超過此時限後，只有 Meta 已批准的訊息範本可以送出。只傳送自由格式訊息的工作流程在測試時看似完美，因為測試總是在訊息後幾秒內進行，到了第一個真正的隔夜個案便會停止回應。 穩健的做法是加入分支：檢查最後一則傳入訊息距今多久，再相應選擇自由格式訊息或訊息範本。 ### n8n 也可以使用 MCP 連接器嗎？ 可以，而 n8n 在這方面相當少見。它的 MCP Client Tool 節點會連接到遠端 MCP 伺服器，並支援 OAuth2，這正是我們所需的功能，因此工作流程中的 AI Agent 節點可以直接呼叫我們的工具。 這一點值得注意，因為大部分自動化平台都做不到。Make 和 Zapier 都會自行執行 MCP 伺服器，兩者都不會作為用戶端，因此都無法連接第三方伺服器。n8n 可以。 它適合處理的是執行部分：工作流程運行期間，由代理程式節點決定傳送訊息、檢查號碼狀況，或讀取訊息範本的批准狀態。它無法取代 Webhook，因為 MCP 沒有方法因應傳入訊息而被喚醒。 ### 工作流程應該使用哪一個？ 兩者都要，分別處理不同部分，這並非偏好問題。 Webhook 是一切開始的方式。客戶發出訊息，Meta 將訊息傳送到您的 Webhook 節點，工作流程便會執行。任何工具都沒有 MCP 的對應方式，因為該協定是請求與回應，而不是可以被呼叫進入的機制。 MCP Client Tool 是讓工作流程內的代理程式執行操作，而不必由您硬編碼呼叫。如果工作流程已確切知道要傳送的內容，使用 HTTP Request 節點呼叫 Cloud API 會更簡單，出錯的地方也較少。如果由代理程式作決定，連接器會提供 16 個工具，以及工具描述中附帶的規則，包括 24 小時時限。 ### 這與人們已在使用的 n8n WhatsApp 節點有何不同？ 您在實際環境中找到的大部分 n8n WhatsApp 設定，都是建基於以連結裝置身分登入的非官方閘道。它們容易開始使用，卻會令號碼面臨風險，因為這種機制違反 WhatsApp 條款，而 Meta 偵測的是流量模式，不是所使用的程式庫。 另一條常見路徑是不使用 Coexistence 的官方 API。它可以運作，但會遷移號碼。WhatsApp Business 應用程式會停止在該號碼上運作，而原本整天負責回覆的團隊必須轉移到新工具。對大部分小型企業而言，這不可接受，因此許多企業最初才會選擇非官方閘道。 Coexistence 正是缺少的組合：官方 API，同時保留手機的正常運作。 - 使用 n8n Test URL 作為 Webhook 目的地。編輯器關閉後，它便會停止監聽，訊息也就無人接收。 - 沒有回應 Meta 的驗證請求。Meta 會先以 GET 傳送挑戰值，然後才傳送其他內容；如果節點沒有原樣回傳挑戰值，便永遠收不到訊息。 - 在 24 小時時限以外使用自由格式訊息回覆。從工作流程角度看，這會無聲無息地失敗，只有已批准的訊息範本可以送出。 **我需要為此安裝獨立的 n8n 節點嗎？** 不需要。Webhook 節點負責接收，HTTP Request 節點負責傳送。無需安裝任何軟件，因為整合只需要一個 URL 和 REST 呼叫。 **團隊仍可在手機上回覆嗎？** 可以。這就是 Coexistence 的意思。WhatsApp Business 應用程式會繼續在同一個號碼上運作，工作流程和人員都能看見對方的訊息。 **一個工作流程可以處理多個客戶的號碼嗎？** 可以。將每個號碼都指向同一個 Webhook，然後按負載中的 receiving phone number id 分支。一個帳戶可以容納您需要的任意數量號碼。 **如果我的 n8n 執行個體停止運作，會發生甚麼事？** Meta 會在一段時間內重試傳送，之後停止。訊息仍會到達手機上的 WhatsApp Business 應用程式，因此對企業而言不會遺失，只會無法進入工作流程。 --- ## 使用自訂連接器將 WhatsApp 連接至 Claude https://easycoexistence.com/zh-hant/integrations/claude 在 Claude 加入 https://easycoexistence.com/api/mcp 作為自訂連接器並登入。之後，Claude 可列出您的號碼、檢查狀況、傳送訊息及範本，並將 Webhook 指向您自己的系統，全程使用 Meta 官方 Cloud API，而非已連接裝置工作階段。 ### 如何將它加入 Claude？ 在 Claude 中開啟設定，加入指向 EasyCoexistence MCP 端點的自訂連接器。Claude 會開啟登入頁面，您授權後，工具便會出現。毋須產生金鑰，也毋須將任何內容貼入設定檔，因為連接器使用 OAuth。 Claude Desktop 使用相同連接器，從「設定」中的「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-hant/whatsapp-cloud-api-vs-coexistence Coexistence 並不是 Cloud API 的替代方案，而是接入 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-hant/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 會先審核，通常數分鐘內完成，但有時需 1 日。 **我可以延長 24 小時時段嗎？** 不可以。時段由 Meta 固定，任何服務供應商都不能延長。唯一能重新開啟時段的方法，是客戶再次向您發訊息。 **客戶回覆訊息範本會重新開啟時段嗎？** 會。客戶發出的任何訊息都會開始新的 24 小時時段，包括回覆您傳送的訊息範本。 **我應使用哪個訊息範本類別？** Utility 用於交易訊息，Marketing 用於推廣訊息。傳送 Marketing 訊息時，您自己的 WhatsApp Business 帳戶必須設有付款方式。 **錯誤 131047 是否與 131049 相同？** 不相同。131047 代表時段已關閉；131049 則代表 Meta 為保障生態系統健康而限制傳送，屬於另一種情況。 --- ## WhatsApp 錯誤 131049：為維持生態系統健康而封鎖訊息 https://easycoexistence.com/zh-hant/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-hant/docs/whatsapp-error-131048 錯誤 131048 表示 Meta 正限制這個號碼的發送，因為其質素下降，通常是收件者封鎖或舉報訊息所致。號碼仍然可以正常運作。改變的是，在質素恢復期間，允許發送的訊息數量有所減少。 ### 甚麼會令號碼質素下降？ 收件者作出負面反應，Meta 會衡量這些反應，而不是從您的代碼推斷。 相關訊號包括封鎖、舉報，以及較不明顯的情況：收件者只是沒有回覆原本預期會收到回覆的訊息。大量發送訊息但很少收到回覆的號碼，與持續進行對話的號碼看起來不同，而這種差異會累積成質素評分。 評分會經歷綠色、黃色及紅色。進入紅色後，發送便會開始因這個錯誤而失敗。手機不會顯示任何狀態變化，而 WhatsApp Business 應用程式在整個過程中仍會正常運作，因此大多數商戶首先發現的是發送失敗，而不是收到警告。 ### 號碼如何恢復？ 只要停止導致質素下降的發送，號碼便會自行恢復。 質素是一項滾動衡量指標。近期發送獲得較佳反應後，評分會逐步回升，發送限制亦會隨之解除。您無需提出申訴，也沒有任何供應商可以切換的開關，因此沒有人可以向您出售解決方案。 真正有幫助的是縮小訊息接收者範圍。向近期曾互動的人發送訊息。相比群發推廣訊息，應優先發送與客戶行動相關的實用訊息。刪除所有向名單而非個別人士發送的內容。導致評分下降的模式，也正是令評分持續偏低的模式，因此改變這種模式，恢復才會開始。 ### 發送失敗前，如何得知問題？ 只能直接監察評分本身，這正是監察連接而不只是建立連接的最明確理由。 Meta 會在電話號碼上顯示質素評分及訊息層級，而且這些資料會在造成損失前變化。號碼由綠色轉為黃色，代表仍有時間處理的警告。號碼進入紅色並開始返回這個錯誤時，已經失去部分發送能力；到那時，受影響的訊息已經遺失，不會排入隊列。 質素下降不會在 WhatsApp Business 應用程式中顯示，因此團隊從手機回覆時，一直會以為業務正常，直到發送突然停止。 - 把它當成發送代碼的錯誤。請求本身沒有問題，受限制的是號碼。 - 更換供應商以逃避限制。評分屬於號碼，亦會隨號碼保留。 - 等待通知。手機不會宣布質素下降。 **我仍然可以接收訊息嗎？** 可以。接收不受影響，WhatsApp Business 應用程式會繼續在該號碼上正常運作。 **恢復需要多久？** Meta 沒有公布具體時間。這是滾動衡量指標，因此會隨近期發送改善而改善，而不是在固定期限後恢復。 **轉用另一間供應商可以重設限制嗎？** 不可以。質素附屬於電話號碼，而不是透過該號碼發送訊息的人。 **這是否等同於被封禁？** 不是。封禁會移除號碼；這只會限制正常運作的號碼可發送的訊息數量，直至其質素恢復。 --- ## WhatsApp 錯誤 132001：訊息範本不存在 https://easycoexistence.com/zh-hant/docs/whatsapp-error-132001 錯誤 132001 表示您嘗試發送的訊息範本不存在於指定語言，或雖然存在但尚未獲批。訊息範本由名稱及語言共同識別，因此相同名稱的不同地區設定會是不同訊息範本。 ### 為何存在的訊息範本仍會回傳 132001？ 幾乎總是因為語言代碼有誤。 訊息範本由名稱及語言共同識別。以 en_US 建立的 order_update，不會以 en、pt 或 pt_BR 的 order_update 形式存在。使用正確名稱但錯誤地區設定，就會產生這個錯誤，而錯誤訊息不會清楚說明是哪一部分有誤。 第二個原因是審核狀態。已建立但仍在待審核的訊息範本無法發送，被拒絕的訊息範本也一樣。兩者都會回傳與完全未建立的訊息範本相同的代碼，因此在假設名稱有誤之前，值得先檢查狀態。 ### 如何找出正確的名稱及語言？ 請列出該號碼上的訊息範本並讀取結果，不要只依賴原先的設定。 清單會顯示每個訊息範本的確切名稱、確切語言代碼及審核狀態，一次解決這個錯誤的 3 個成因。這也是唯一可靠的來源，因為訊息範本可能在建立它的程序記錄名稱後被編輯或拒絕。 透過 MCP 連接器，這是一個問題而非 API 呼叫：詢問某個號碼上哪些訊息範本已獲批，助理便會讀取結果。使用您自己的程式碼時，則可向 WhatsApp Business Account 發出單一 Graph 請求，並使用該連接的 phone number id 及存取權杖。 ### 審核需要多長時間？ 通常只需數分鐘，有時最多一天。 Meta 會在訊息範本可供發送前逐一審核。大部分很快便會完成，但時間並無保證，服務供應商也無法加快流程。對於建立訊息範本後立即發送的流程，這一點尤其重要，因為審核仍在進行時，發送會因這個錯誤而失敗。 穩妥的做法是在設定整合時預先建立訊息範本，然後在使用前檢查狀態。使用連接器的助理可以完成兩者：提交訊息範本，然後報告它已獲批、被拒絕，還是仍在審核中。 - 訊息範本以 en_US 建立，卻使用 en 發送。對 API 而言，兩者是不同的訊息範本。 - 建立訊息範本後在同一次執行中發送。Meta 會先進行審核。 - 以為被拒絕的訊息範本仍然可用。它會像不存在的訊息範本一樣回傳這個錯誤。 **在哪裡可以查看確切的語言代碼？** 在該號碼的訊息範本清單中。清單會同時顯示名稱、語言及狀態，是唯一可靠的來源。 **可以發送待審核的訊息範本嗎？** 不可以。只有已獲批的訊息範本可以送達，待審核的訊息範本會回傳相同錯誤。 **被拒絕的訊息範本必須重新建立嗎？** 可以編輯後重新提交，但在被拒絕的狀態下無法發送。 **WhatsApp Business 應用程式可以發送訊息範本嗎？** 在 Coexistence 號碼上不可以。訊息範本必須經由 API 發送，這也是連接號碼的實際原因之一。 --- ## WhatsApp 錯誤 132000：參數數量不符 https://easycoexistence.com/zh-hant/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-hant/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 是同一個問題嗎？** 不是。該代碼表示在啟用超過 24 小時後才嘗試同步，而不是表示同步已經執行過。 --- ## WhatsApp 錯誤 2593108：24 小時時限外同步 https://easycoexistence.com/zh-hant/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-hant/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-hant/docs/whatsapp-error-131042 錯誤 131042 表示 Meta 無法收取訊息費用，因為 WhatsApp Business 帳戶沒有可用的付款方式。相關費用由 Meta 直接向您收取，因此應在 WhatsApp Manager 修正，而不是聯絡為您提供 API 存取權的供應商。 ### 實際上是誰向誰收費？ 涉及兩家公司，而其中只有一項費用與供應商有關。 Meta 會就 WhatsApp Business Platform 上的對話收費，並向您自己的 WhatsApp Business 帳戶所連結的付款方式收費。這段關係存在於您與 Meta 之間。供應商則在旁提供存取權及工具並收費，完全不會接觸這些對話費用。 因此，聯絡供應商無法修正這項錯誤，處於該位置的任何人也不能代您新增信用卡。這亦表示，供應商從未收到這筆對話費用，便不能對其加價。 ### 付款方式在哪裡設定？ 在 WhatsApp Manager 內，設定於擁有該號碼的 WhatsApp Business 帳戶。 您可在該處新增或更新付款方式，而帳戶必須先設定付款方式，部分訊息發送功能才會正常運作。尤其是發送推廣訊息範本時必須設定付款方式，因此，如果帳戶一直只用於回覆客戶，首次嘗試推廣訊息時便很容易出現這項錯誤。 API 特意無法執行這項操作。系統沒有用於連結信用卡的端點，因為這是帳戶層面的商業關係，而不是訊息操作。 - 要求供應商修正問題。付款關係存在於您與 Meta 之間，任何 API 都不能連結信用卡。 - 以為供應商費用已包括訊息成本。這是兩家公司收取的兩項獨立費用。 - 在沒有付款方式的帳戶上使用推廣訊息範本。Meta 要求這類發送必須設定付款方式。 **EasyCoexistence 可以代我向 Meta 付款嗎？** 不可以。費用會向您自己的 WhatsApp Business 帳戶所設定的付款方式收取，而且沒有可用於連結付款方式的 API。 **為甚麼現在才出現這項錯誤？** 通常是因為首次嘗試發送推廣訊息範本。Meta 特別要求這類發送必須設定付款方式。 **這會停止接收訊息嗎？** 接收訊息不受影響。失敗的是 Meta 需要收費的訊息發送。 **有沒有方法完全避免 Meta 收費？** 在 24 小時客戶服務時段內的回覆免費。Meta 收費的是在該時段以外開啟的對話。 --- ## WhatsApp 錯誤 133010：號碼未註冊 https://easycoexistence.com/zh-hant/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 表示號碼需要先完成驗證，之後才能註冊。此錯誤則表示註冊本身從未完成。 --- ## WhatsApp 錯誤 190：存取權杖已過期 https://easycoexistence.com/zh-hant/docs/whatsapp-error-190 錯誤 190 代表請求所用的存取權杖已過期或失效。每次請求都以相同方式失敗，看起來就像號碼消失了。其實並非如此：憑證失效，而號碼通常沒有問題。 ### 為甚麼過期權杖看起來像號碼遺失？ 因為每個請求都會失敗，而且失敗方式完全相同。 讀取號碼、檢查狀態、列出範本及傳送訊息會同時停止運作。從外部看來，這與號碼已從帳戶移除沒有分別，而只有一個憑證的整合無法分辨兩種情況。不少人因此以為自己已中斷連接，但實際上並沒有。 這個分別很重要，因為兩者需要的處理完全相反。憑證失效，只需替換憑證。號碼已被移除，則必須重新連接，並需要企業擁有人及電話配合。 ### 如何分辨兩種情況？ 使用第 2 個可讀取同一帳戶的憑證。 EasyCoexistence 會為每個連接保留客戶的權杖及自己的 System User 權杖。當其中一個被拒絕時，另一個會讀取 WhatsApp Business 帳戶，確認究竟是哪一個失效。客戶權杖被拒絕，但第 2 個讀取權杖正常，表示憑證已過期，而號碼狀態正常。兩者都失敗，才表示號碼本身可能發生問題。 沒有第 2 個讀取者，唯一的分辨方法就是請企業擁有人檢查，而這正是監察應避免的中斷。 ### 權杖如何失效？ 原因有多種，大部分都不是蓄意造成。 權杖有使用期限，會自行過期。更改 Meta 帳戶密碼會令權杖失效。有人在 Business Settings 移除應用程式存取權也會造成同樣結果，Meta 撤銷被視為已洩露的權杖亦然。這些情況事前都不會發出警告，而且無法從手機上的 WhatsApp Business 應用程式看見。 因此，權杖有效性應納入監察，而不是只在錯誤處理程式中處理。錯誤處理程式看見錯誤時，訊息通常已經傳送失敗。 - 重新連接號碼。如果問題在於權杖，重新連接只會要求企業擁有人處理根本不需要的工作。 - 把問題當作間歇性錯誤並重試。失效的權杖不會自行恢復。 - 只依賴一個憑證。只有一個權杖時，無法分辨憑證失效與號碼遺失。 **號碼仍然可以運作嗎？** 通常可以。WhatsApp Business 應用程式不受影響，號碼本身亦完整無缺。停止運作的是 API 存取。 **錯誤 0 是同一回事嗎？** 實際上是。Meta 會根據端點，在這種情況下回報其中一個代碼。 **重新連接可以修復問題嗎？** 可以，但這是用繁重方法處理簡單問題，而且需要企業擁有人及電話配合，原本只需建立新憑證即可解決。 **可以讓權杖永不過期嗎？** System User 權杖可以有較長有效期，這正是保留第 2 個權杖有用的原因之一。 --- ## WhatsApp 錯誤 130429：已達吞吐量上限 https://easycoexistence.com/zh-hant/docs/whatsapp-error-130429 錯誤 130429 表示此號碼的 Cloud API 吞吐量上限已達到。這是速率問題，而不是總量問題：相同訊息以較慢速度傳送即可成功。對於 Coexistence 號碼，上限由 Meta 固定。 ### 實際受到限制的是甚麼？ 是訊息離開的速率，而不是您一天可以傳送的訊息數量。 平台會為每個號碼接受每秒固定數量的訊息，超出的請求會被拒絕，而不是排隊。因此，傳送 10,000 個訊息本身並不是問題，在同一秒內全部傳送才是問題。將相同批次分散在幾分鐘內傳送，便可全部成功。 這與訊息級別不同，後者限制您一天可以主動開始對話的不同客戶數量；也不同於品質限制，後者會限制收件人反應欠佳的號碼。這是 3 個不同的上限，對應 3 個不同的代碼，經常互相混淆。 ### 可以提高這個上限嗎？ Coexistence 號碼不可以。上限由 Meta 按固定速率設定，任何服務供應商都無法提高。設計系統時，您應先了解這一點，不要假設可以依靠更高的數值。 以一般方式完成註冊的號碼，其吞吐量會隨着品質評分及訊息級別逐步提升。這是 Coexistence 少數真正的取捨之一，也是高用量廣播號碼通常較適合在不使用 Coexistence 的情況下完成註冊的原因。 對話用途很少會受到這個上限約束。當某個程式循環處理清單，並以程式允許的最快速度傳送時，問題才會出現。這種做法本身就值得避免。 ### 傳送端應改為怎樣做？ 控制傳送速度，並採用退避方式重試，不要立即重試。 設定固定速率的佇列是持久可靠的做法，因為這會令上限成為系統本身的屬性，而不是在正式環境中才發現的問題。如果這樣做過於複雜，針對這個代碼採用指數退避，也能取得大部分效果。 緊密重試並不能解決問題。若程式在請求被拒絕後立即重試，便會在號碼已超出速率的同一刻產生更多請求，令問題延續，而不是解除。 - 立即重試。在拒絕發生時產生更多請求，會令號碼持續超出速率。 - 將它與訊息級別混淆。訊息級別限制每日不同的對話數量，而不是每秒的訊息數量。 - 按照可提升的吞吐量來設計 Coexistence 號碼。吞吐量不會提升，上限是固定的。 **這是否表示我的號碼受到限制？** 不是。這是普通的速率限制。號碼狀態正常，以較慢速度傳送相同訊息時便會成功。 **Coexistence 號碼可以多快傳送？** Meta 會為 Coexistence 號碼設定固定速率，不會按品質及訊息級別提升。 **80007 是相同的錯誤嗎？** 不是。那是 WhatsApp Business 帳戶的速率限制，不是某個號碼的訊息吞吐量限制。 **換用其他服務供應商會傳送得更快嗎？** 不會。限制屬於該號碼及 Meta，而不是取用 API 的服務供應商。 --- ## 透過官方 Cloud API 將 WhatsApp 連接至 Make https://easycoexistence.com/zh-hant/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 不同，n8n 有 MCP Client Tool 節點，可透過 OAuth 使用遠端伺服器。 實際上不會產生額外費用。Webhook 路徑已能完成情境所需的一切，而且它會回應收到的訊息，這是 MCP 在任何工具中都無法做到的。 ### 情境如何發送回覆？ 使用 HTTP 模組呼叫 Cloud API，並提供該號碼的 `phone_number_id` 和存取權杖。兩者都可從控制台讀取，或透過 MCP 連接器取得，讓助理代您擷取。 要傳送的內容取決於時間。在客戶最後一則訊息後 24 小時內，可使用自由文字。超過這段時間，只有 Meta 已批准的訊息範本才能成功傳送。如果情境只會傳送自由文字，第一次遇到隔夜個案時便會停止回覆。 穩妥的做法是建立路由器：檢查最後一則收到的訊息距今多久，再按情況選擇自由文字分支或訊息範本分支。 - 讓 Webhook 持續指向已關閉情境的 Make URL。Meta 仍會傳送訊息，但不會執行任何內容。 - 沒有回應 Meta 的驗證請求。Meta 會先發送帶有挑戰值的 GET，然後才傳送其他內容。 - 在 24 小時時限外回覆自由文字。傳送會失敗，而從情境角度看起來就像甚麼也沒有發生。 **Make 可以連接您的 MCP 伺服器嗎？** 不可以。Make 是 MCP 伺服器而不是用戶端，因此無法向外呼叫我們的伺服器。Webhook 路徑已涵蓋情境所需的一切。 **我需要 WhatsApp 的 Make 應用程式嗎？** 不需要。自訂 Webhook 負責接收，HTTP 模組負責傳送。整合只需一個 URL 和一次 REST 請求。 **團隊仍可在手機上回覆嗎？** 可以。這就是 Coexistence 的意思。應用程式會繼續使用同一個號碼，而情境也會看到人員發送的內容。 **一個情境可以服務多個客戶嗎？** 可以。將每個號碼都指向同一個 Webhook，再按負載中的 `phone_number_id` 分流。 --- ## 透過官方 Cloud API 將 WhatsApp 連接至 Zapier https://easycoexistence.com/zh-hant/integrations/zapier 將號碼的 Webhook 目的地指向 Zapier 的 Catch Hook，每則新訊息都會觸發一個 Zap。回覆會透過 Cloud API 的 Webhook 動作發送。Zapier 無法使用我們的 MCP 伺服器，因為 Zapier 是 MCP 伺服器，而不是用戶端。 ### 收到訊息後，如何觸發 Zap？ 使用 Webhooks by Zapier 觸發程序建立 Zap，選擇 Catch Hook，然後複製 Zapier 產生的 URL。將該 URL 設為號碼的 Webhook 目的地後，Meta 會直接將每則傳入訊息傳送至該處。 負載會提供發送者、訊息內容、時間戳記及訊息 ID，這些資料已足夠大多數 Zaps 作出分支判斷。所有程序都不會在您的基礎設施上執行，也沒有需要我們維護的 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 動作，向 Cloud API 發出請求，並使用來自控制台的號碼 `phone_number_id` 及存取權杖。 可發送的內容取決於時間。在客戶最後一則訊息後 24 小時內，可以發送自由格式訊息。超過時限後，只能發送已核准的範本。這也是大多數 Zaps 在正式環境中失敗的原因，因為測試總是在訊息發出數秒後進行。 要同時處理兩種情況的 Zap，需要根據上一則傳入訊息收到多久加入路徑篩選器。這只是多一個步驟，卻決定自動化程序只能在星期二下午運作，還是凌晨 3 時也能正常運作。 - 使用 Zapier 測試 URL 作為目的地。測試 URL 會停止監聽，訊息也會無人接收。 - 忘記 Meta 的驗證 GET。Catch Hook 必須在開始傳送前回傳 challenge。 - 在 24 小時時限外發送自由格式訊息，從 Zap 的角度看會靜默失敗。 **是否有官方 WhatsApp Zapier 應用程式？** 這裏不需要。Catch Hook 負責接收，Webhook 動作負責發送，讓您直接使用官方 Cloud API，無需中間層。 **Zapier 可以使用您的 MCP 伺服器嗎？** 不可以。Zapier 本身就是 MCP 伺服器，不會作為用戶端運作，因此無法連接我們的伺服器。 **我的團隊會失去電話使用權嗎？** 不會。Coexistence 讓 WhatsApp Business 應用程式繼續使用同一個號碼運作。 **如果我的 Zap 暫停了，會怎樣？** Meta 會重試一段時間，然後停止。訊息仍會到達手機上的應用程式，因此商戶不會遺失任何訊息。 --- ## 使用自訂連接器將 WhatsApp 連接至 ChatGPT https://easycoexistence.com/zh-hant/integrations/chatgpt 在 ChatGPT 設定中開啟開發人員模式，加入 EasyCoexistence 作為連接器。之後，ChatGPT 便可列出您的號碼、檢查狀態、傳送訊息及範本，並將 Webhook 指向您自己的系統，全部透過 Meta 官方 Cloud API 完成。 ### 如何將它加入 ChatGPT？ 開啟「設定」，前往「連接器」，再選擇「進階」，然後開啟開發人員模式。這樣才會顯示透過 URL 加入連接器的選項，而不是只能從內置清單中選擇。 加入指向 EasyCoexistence MCP 端點的連接器。ChatGPT 首次呼叫工具時會開啟登入畫面，您可在該處授權。由於連接器使用 OAuth 而非 API 金鑰，因此不會產生、複製或貼上任何內容。 伺服器本身位於遠端。您無需安裝任何程式，電腦上也不會在背景執行任何程式；關閉 ChatGPT 亦不會以任何方式影響已連接的號碼。 ### 連接後，ChatGPT 可以做甚麼？ 您只需用日常語言提出要求，ChatGPT 便會選擇合適的工具。例如：我的哪些號碼狀態不佳？把預訂確認訊息傳給這位客戶。建立訂單更新範本，並在 Meta 批准後通知我。將這個號碼的 Webhook 指向我的伺服器。 讀取工具涵蓋列出號碼、檢查品質評分、訊息層級及連接狀態，以及在其他系統需要時提取憑證。傳送工具則涵蓋在會話時段內傳送自由文字，以及在時段以外傳送已批准的範本。 十六個工具之中，有一個會以 markdown 格式向 ChatGPT 提供我們的文件，因此它能根據我們的文件回答這些功能的運作方式，而不是自行猜測。 ### 它不能做甚麼？ 它不能回應傳入訊息。這點值得說清楚，因為大多數人都會以為助理能夠這樣做。 MCP 採用請求及回應模式。您要求時，ChatGPT 才會呼叫工具。沒有任何機制可以讓客戶的 WhatsApp 訊息喚醒 ChatGPT，並讓它在凌晨三時自行回覆。無論哪個產品的 MCP 伺服器，都不會改變這一點。 自動回覆需要使用 Webhook：Meta 將傳入訊息傳送到您運行的系統，再由該系統決定如何處理。兩者可以配合使用，而連接器甚至可以代您設定 Webhook 目的地。 - 以為它會自動回覆客戶。MCP 只會在收到指示時運作；傳入訊息需要 Webhook。 - 在內置連接器清單中尋找 EasyCoexistence。開啟開發人員模式後，需透過 URL 加入。 - 以為需要金鑰。連接器透過 OAuth 授權，您無需貼上任何內容。 **需要付費 ChatGPT 方案嗎？** 自訂連接器位於設定中的開發人員模式後方。可用性遵循 OpenAI 自身的方案規則，而非由我們控制。 **ChatGPT 會看到客戶的對話嗎？** 只會看到您要求的內容。傳入訊息會由 Meta 路由至您指定的 Webhook 目的地，而我們絕不儲存對話內容。 **它可以連接新號碼嗎？** 它可以開始流程。連接器會返回一條連結，由帳戶擁有人開啟，透過 Meta 的流程授權自己的號碼。 **它可以與 Claude 使用同一個帳戶嗎？** 可以。一個 EasyCoexistence 帳戶、一個端點，您連接的每個助理都能看到相同的號碼。 --- ## 透過 MCP 將 WhatsApp 連接至 Cursor https://easycoexistence.com/zh-hant/integrations/cursor 將 EasyCoexistence 加入 Cursor 的 MCP 設定後，編輯器便可連接真實 WhatsApp 號碼，無需離開專案：列出號碼、檢查狀態、傳送訊息及已核准的訊息範本，並將 Webhook 目的地指向您正在建立的任何項目，全程使用 Meta 官方 Cloud API。 ### 如何將它加入 Cursor？ 開啟設定並找到 MCP 部分，然後加入一部指向 EasyCoexistence 端點的伺服器。Cursor 亦會讀取 mcp.json；如果您要設定多部機器，或希望將設定納入版本控制，這是較合適的方法。 重新載入後，要求 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-hant/integrations/claude-code 執行一次 claude mcp add 指令，Claude Code 即可連接真實的 WhatsApp 號碼：列出號碼、檢查健康狀況、發送訊息及範本，以及設定 Webhook 目的地。整個過程使用 Meta 官方 Cloud API，而不是已連結裝置的工作階段。 ### 如何加入？ 在任何終端機執行 claude mcp add，指定 http 傳輸方式及 EasyCoexistence 端點。然後在 Claude Code 內執行 /mcp 並完成驗證。此後，這 16 個工具會在該部機器的每個工作階段中提供使用。 除了設定項目外，不會安裝任何內容。伺服器位於遠端，因此無需保持任何程序運作，磁碟上也不會保留工作階段。 授權採用 OAuth，因此存取權杖不會出現在 shell 歷程記錄、dotfile 或儲存庫中。這一點在此比桌面應用程式更重要，因為終端機設定很容易意外提交至儲存庫。 ### 實際上有甚麼用途？ 同時處理 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-hant/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。這些事件不含對話內容，也是監察功能的基礎。 把自己放在訊息路徑上的供應商會收到第 1 組事件。不在該路徑上的供應商則不會收到。 ### Meta 如何驗證端點？ Meta 會先發出 GET 請求，驗證成功後才會傳送任何內容。驗證失敗，是看似完成設定卻一直收不到訊息的最常見原因。 Meta 會以 hub.mode 設為 subscribe、您的 hub.verify_token，以及 hub.challenge 值呼叫您的 URL。您的端點必須將該 challenge 作為原始回應主體回傳，不可包裝成 JSON，也不可加入任何其他內容。否則 Meta 不會開始傳送事件，而任何控制台都不會顯示原因。 端點也必須使用 HTTPS。回傳無提示 404 的端點，或設有拒絕 Meta 請求的驗證層的端點，在第 1 則訊息無法送達前，看起來都與正常設定無異。 ### 目的地可以指向您自己的伺服器嗎？ 可以，而這正是不同供應商之間的差異所在。 Meta 允許應用程式覆寫指定 WhatsApp Business 帳戶傳送 Webhook 的位置。我們會把覆寫設定為您的 URL，將訊息路徑事件從我們的回呼移至您的端點。我們會保留運作事件，因為控制台和警報功能都由這些事件組成。 這個結果屬於架構安排，而非我們公布的政策。對話內容不會送到我們這一方，因此沒有機會儲存在我們這一方。未設定覆寫的帳戶會退回我們的預設回呼，處理程式會捨棄這些事件而不予儲存。 ### 號碼重新連接時，目的地會怎樣？ 目的地會被移除，這是幾乎沒有人預計到的故障情況。 目的地不是電話號碼的屬性，而是我們應用程式訂閱 WhatsApp Business 帳戶時的覆寫設定。當連接被移除，不論是因 Meta 的 14 天不活躍規則或其他原因，應用程式都會從該帳戶解除安裝，覆寫設定也會一併移除。 重新連接會恢復傳送和監察，但不會恢復向您伺服器傳送事件，也不會顯示錯誤。因此，最先發現問題的往往是客戶表示無人回覆。我們會在每次重新連接時重新套用覆寫，因為曾有實際號碼順利重新連接，卻因此停止傳送事件。 - 在驗證 GET 中回傳 JSON。Meta 要求只回傳原始 hub.challenge 值。 - 使用臨時或測試 URL。產生該 URL 的工具停止監聽後，Meta 仍會繼續向它傳送事件。 - 假設目的地會在重新連接後保留。它隸屬於應用程式訂閱，會隨訂閱一併解除安裝。 - 把端點置於會拒絕 Meta 請求的驗證層後。 **我的訊息會經過 EasyCoexistence 嗎？** 不會。覆寫設定會把訊息路徑事件從 Meta 直接傳送至您的端點。未設定覆寫的帳戶，其事件會退回我們的回呼，並在不儲存的情況下捨棄。 **之後可以更改目的地嗎？** 可以，您可隨時從控制台或透過 MCP 連接器更改。傳入 null 會將設定重設為我們的預設值。 **Meta 傳送事件時，如果我的伺服器停止運作，會怎樣？** Meta 會在一段時間內重試，之後停止。訊息仍會抵達手機上的 WhatsApp Business 應用程式，因此即使整合失效，商戶也不會遺失任何訊息。 **1 個 Webhook 足以供多個號碼使用嗎？** 可以。將每個號碼指向同一個端點，並根據負載中的 receiving phone number id 分流。 --- ## 使用 Python 傳送及接收 WhatsApp 訊息 https://easycoexistence.com/zh-hant/integrations/python 接收方式是在您的 Web 架構中建立路由，回應 Meta 的驗證 GET 並接收 POST。傳送方式是向 Cloud API 發出 HTTPS 請求，附上號碼的電話號碼 ID 及存取權杖。不提供我們的 SDK，也無需安裝任何軟件。 ### 如何在 Python 中接收訊息？ 在您現有的任何架構中，於同一路由設定兩個處理程序。 GET 處理程序回應 Meta 的驗證。它從查詢字串讀取 hub.mode、hub.verify_token 及 hub.challenge，核對存取權杖是否與您自己的相符，然後以原始本文返回 challenge。在這裏返回 JSON 是最常見的錯誤，而且會無聲失敗。 POST 處理程序接收事件。請迅速返回 200，之後才處理工作，因為 Meta 會將緩慢回應視為失敗並重試，這可能令您處理同一則訊息兩次。請將訊息加入佇列，或交給背景工作，而不是直接在處理程序中執行。 訊息會附帶 wamid 訊息 ID。從一開始便按此 ID 去重是值得的，因為重試是正常情況，而非例外。 ### 如何傳送？ 向電話號碼 ID 對應的 Cloud API `messages` 端點發出一次 POST，並附上 Bearer 存取權杖。 兩項資料都來自連接：控制台會顯示它們；如果您希望由助理代為取得，get_api_credentials 也會返回它們。這個請求沒有任何部分專屬於我們，因此任何 HTTP 程式庫都可使用，而請求格式與 Meta 自己的文件完全一致。 時限會改變本文內容。在客戶最後一則訊息後 24 小時內，您可傳送 `text` 物件。超過時限，則須傳送 `template` 物件，指定已獲批准的範本及其語言。只認識第一種格式的客戶端在測試時運作正常，卻會在第一則隔夜訊息時失敗，返回錯誤 131047。 ### 生產環境的處理程序還需要甚麼？ 有 3 件容易跳過、日後卻很難補上的事情。 按訊息 ID 去重，因為 Meta 會重試。在 Webhook URL 中加入一段長而隨機的密鑰，並拒絕不帶此密鑰的請求，否則任何得知容易猜到的 URL 的人都可以向它發出 POST。簽名標頭在這裡並不可行：Meta 會使用擁有該訂閱的應用程式的應用程式密鑰來簽名，而該應用程式是我們的，其密鑰從不對外提供。還要根據聯絡人上次發出訊息的時間分流，讓傳送路徑自動選擇文字或範本，無需人手決定。 這些都不需要架構或程式庫。它們只是集合、檢查及比較；在第一位客戶加入前完成設定，便能令整合安靜運行，而不是不斷向您發出警報。 - 在驗證 GET 中返回 JSON，而非原始 challenge 值。 - 返回 200 前便直接處理。Meta 會重試緩慢回應，令您處理訊息兩次。 - 未檢查時限便傳送自由文字。這會返回 131047，結果看似甚麼也沒有發生。 **有 Python SDK 嗎？** 我們不提供，但您不需要。API 屬於 Meta，由 Meta 提供文件，任何 HTTP 程式庫都可存取。 **應該使用哪個架構？** 任何架構都可以。要求只是建立能回應 GET 及接收 POST 的路由，所有 Python Web 架構都能做到。 **如何避免處理同一則訊息兩次？** 按負載中的 wamid 訊息 ID 去重。Meta 設計上會重試，因此這是預期情況，而非邊緣案例。 **團隊仍可使用手機嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式繼續使用同一個號碼，而您的處理程序會以回音事件接收他們傳送的內容。 --- ## 使用 Node.js 傳送及接收 WhatsApp https://easycoexistence.com/zh-hant/integrations/node 接收是由路由回應 Meta 的驗證 GET 請求，並接受 POST 請求。傳送則是使用 fetch 呼叫 Cloud API，附上號碼的 phone number id 及存取權杖。不需要我們的 SDK，也無需安裝任何軟件。 ### 如何在 Node.js 接收訊息？ 使用一個包含兩種方法的路由，可在 Express、Fastify、Next 路由處理常式或普通伺服器中運作。 GET 會回應 Meta 的驗證：從查詢讀取 hub.mode、hub.verify_token 及 hub.challenge，將權杖與您的權杖比較，然後以純文字回傳 challenge。以 JSON 回傳是最常見的錯誤，會令端點看似正確，卻永遠收不到任何內容。 POST 會接收事件。立即回應 200，之後才處理。Meta 會重試任何處理緩慢的請求，而在回應前完成工作的處理常式會多次看見同一則訊息。尤其在無伺服器環境，先回應再將工作放入佇列，才能避免冷啟動造成重複處理。 ### 如何傳送？ 使用 fetch 呼叫 phone number id 對應的 Cloud API `messages` 端點，並在 bearer 標頭中附上存取權杖。 這件事沒有任何部分是我們專有的，因此請求完全符合 Meta 的官方文件，您不需要學習或受制於任何包裝層。兩個值都在控制台中；如果由助理負責接線，get_api_credentials 會透過 MCP 連接器回傳它們。 請根據時間決定內容。客戶最後一次傳入訊息後 24 小時內，傳送 text 物件。超過時限，則傳送包含已核准範本名稱及語言的 template 物件。只傳送文字的程式碼能通過所有測試，卻會在第一則夜間抵達的訊息上失敗。 ### 無伺服器環境有何不同？ 有兩點，而且都與函式在工作完成前結束有關。 回應 200 後繼續處理，無法在函式一回應便立即凍結的情況下運作。請使用平台提供的機制，讓回應後的工作繼續執行；或將負載推送至佇列，再由另一個函式處理。Meta 只需要您快速確認收到，不需要工作當刻完成。 冷啟動也會令回應變慢，帶來更多重試及重複訊息。在這種架構中，按 wamid 訊息 id 去除重複並非可有可無，而是可靠運作的必要條件。 - 將 challenge 以 JSON 回傳，而非回傳原始內容。 - 在回應 200 前先處理工作。無伺服器環境下，函式可能在回應時立即凍結。 - 略過去除重複。Meta 會按設計重試，重複訊息是正常情況，而非例外。 **需要程式庫嗎？** 不需要。一個路由及 fetch 已經足夠，而且請求完全符合 Meta 的官方文件。 **可在 Vercel 或 Lambda 上運作嗎？** 可以，但要注意一般無伺服器限制：先確認收到，再透過佇列或背景機制處理，不要在請求內直接處理。 **如何驗證請求確實來自 Meta？** 在 Webhook URL 中加入一段長而隨機的密鑰，並拒絕任何不帶此密鑰的請求。Meta 會使用擁有該訂閱的應用程式的應用程式密鑰來簽名，而這個應用程式是我們的，其密鑰從不對外提供，因此您無法在自己一方核對簽名標頭。 **可以使用 TypeScript 嗎？** 可以。我們沒有需要進行型別定義的內容，因為負載屬於 Meta，且由 Meta 提供文件。 --- ## EasyCoexistence 與 BSP 收件匣 https://easycoexistence.com/zh-hant/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 自己的 API，並由 Meta 提供文件。整合不會依賴任何特定供應商，這也讓您可以離開。 - 只按價格作選擇。這是兩種不同的產品，較便宜的一種並不是另一種的精簡版本。 - 讓一個 8 人支援團隊使用沒有任何功能的原始連接。他們需要收件匣，沒有收件匣便會感到不滿。 - 假設 BSP 可以維持 WhatsApp Business 應用程式運作。有些 BSP 可透過 Coexistence 做到，很多則不能，值得直接向對方查詢。 **我可以兩者一起使用嗎？** 如果 BSP 支援 Coexistence，實際上可以。您應該問對方對話內容儲存在哪裏，因為這才是兩者真正的分別。 **BSP 是否更可靠？** 兩者都使用 Meta 的 Cloud API，因此傳送效果相同。不同之處在於 Meta 與您的系統之間有多少個參與方。 **哪一個較便宜？** 通常固定的連接費用低於按客服席位計算的收件匣價格，但兩者是不同的購買項目，只比較數字會產生誤導。 **如果我離開，對話記錄會怎樣？** 使用 Coexistence 時，對話記錄從未由我們持有。使用平台時，記錄會留在平台上，而取出記錄則需要匯出。 --- ## EasyCoexistence 與自行建置 https://easycoexistence.com/zh-hant/compare/build-it-yourself-vs-easycoexistence 本產品使用的每個 API 呼叫，均有 Meta 文件說明，任何擁有 Meta 應用程式的人都可以使用。建立連接只需一個週末。真正耗時的是成為 Tech Provider，而永遠做不完的是察覺連接何時靜默失效。 ### 您實際需要建置甚麼？ 第一個版本所需的工作比預期少，但要建立一個經得起長期使用的版本，工作量則比預期多。 第一個版本包括 Meta 應用程式、Embedded Signup、能回應驗證交握的端點，以及發送請求。對熟悉 OAuth 和 Webhook 的人來說，這確實是一個週末的工作，而我們自己的文件頁面已說明其中大部分內容。 經得起長期使用的版本則不同。它會按名稱處理 8 種 Webhook 事件類型，分辨存取權杖被撤銷與號碼被移除，定期讀取品質評分及訊息層級，因為兩者都不會以可可靠依賴的事件送達；重新連接移除 Webhook 覆寫後重新套用設定，並分辨 14 天不活躍導致的中斷與客戶真正離開。每一項功能，都是從某次故障中學到的。 ### 哪一部分不能走捷徑？ 成為自己的 Meta Tech Provider。這就是連接 1 個號碼與連接其他人號碼之間的差別。 這項服務免費，但並不快捷。您需要經驗證的 Business Manager、通過 App Review 的應用程式，以及展示操作流程的錄影。在完成前，您只能透過其他人的 provider 帳戶工作，這正是現成工具會出現連接數量上限的原因。 如果您只連接自己擁有的 1 個號碼，以上事項都不適用，直接自行建置即可。如果您要為客戶連接號碼，這才是真正的項目，所需時間是數週等待，而不是數天工作。 ### 實際運行監察需要多少成本？ 這是沒有完結日期的部分，因此與其他工作不同。 連接可能會靜默失效。WhatsApp Business 應用程式仍會在品質下降、存取權杖過期、Webhook 覆寫被移除及 14 天中斷期間繼續運作，因此手機上沒有任何跡象顯示問題，通常要到客戶詢問為何沒有人回覆，您才收到第一個訊號。 要捕捉這些問題，需要排程輪詢程式、Webhook 接收器、儲存狀態的位置、警報，以及留意警報的人。每一項都不困難，但全部都必須持續運作，而且 Meta 改變設定時也要保持正確，因為 Meta 確實會改變設定。這才是您在這裡購買的真正價值，而不是 API 呼叫本身。 - 根據第一個版本估算。連接 1 個號碼只需一個週末，但維持 50 個號碼連接並不簡單。 - 計劃在限期前成為 Tech Provider。App Review 所需時間不由您控制。 - 把監察視為後期工作。它捕捉的故障是靜默的，因此沒有發現故障，不代表故障沒有發生。 **這裡有任何專有技術嗎？** 沒有。每個呼叫都是 Meta 有文件說明的 Cloud API。這是刻意的設計，代表沒有任何東西會綁定您，您可以保留自己的整合並離開。 **如果我只有 1 個號碼，應否自行建置？** 大概應該。您擁有的 1 個號碼只需連接一次，這是小型項目，也能讓您真正了解這個平台。 **成為 Tech Provider 需要多久？** 這項服務免費，但需要經驗證的 Business Manager 及 App Review，包括錄製操作流程。漫長的是等待時間。 **自行建置會失去甚麼？** 沒有任何技術功能。您需要自行負責監察，而監察永遠不會完成，也正是最容易靜默失效的部分。 --- ## WhatsApp 錯誤 368：帳戶因政策受限 https://easycoexistence.com/zh-hant/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-hant/docs/whatsapp-error-131031 錯誤 131031 表示 WhatsApp Business 帳戶受限，通常是因為業務驗證資料與 Meta 持有的資料不符，或涉及兩步驟驗證 PIN。這項問題須在 Business Manager 解決，而不是修改程式碼。 ### 甚麼類型的資料不符會導致此錯誤？ Meta 持有的業務資料與您提交的資料不同。這看似只是小問題，實際上並非如此。 業務驗證會將法律實體連繫至帳戶，包括名稱、地址、註冊資料及證明文件。如果業務資料有變更但未在 Meta 更新，或提交的資料與 Meta 查核的登記資料不符，帳戶可能會受限，直至資料重新一致為止。 另一個常見原因是兩步驟驗證 PIN，而且較容易修正。PIN 設定在號碼上，某些操作需要使用。如果您忘記 PIN，或 PIN 是由已離職的人員設定，就必須先重設，其他操作才會恢復。 ### 實際上應在哪裏查閱？ 請在 Business Manager 的業務帳戶內查閱，而不是在號碼上查閱。 驗證狀態及任何執法通知都會顯示在那裏，兩者通常足以說明實際原因。供應商控制台可以告訴您號碼何時停止運作，卻無法查看驗證記錄，因此不能指出哪項資料有誤。 如果原因是驗證，請更新業務資料並重新提交。如果原因是 PIN，請在該號碼的 WhatsApp Manager 設定中重設，並記錄在業務日後能找到的位置。 - 把問題當作程式碼故障。請求格式正確，但帳戶遭到拒絕。 - 使用相同的遭拒資料重新提交驗證。 - 以為 PIN 由供應商儲存。PIN 是在 Meta 自己的設定中設定於該號碼上。 **這是否與 368 相同？** 相關但並不相同。368 是政策執法行動；此錯誤通常指向業務驗證資料或兩步驟 PIN。 **供應商可以查看我的驗證狀態嗎？** 不可以。驗證狀態位於 Business Manager 的業務帳戶內，供應商無法查看。 **重新連接會有幫助嗎？** 不會。限制套用於帳戶，因此重新建立連接仍會遇到相同條件。 **如何重設兩步驟 PIN？** 在 WhatsApp Manager 的該號碼設定中重設。請記錄在業務日後能找到的位置。 --- ## WhatsApp 錯誤 132015：訊息範本因質素暫停 https://easycoexistence.com/zh-hant/docs/whatsapp-error-132015 錯誤 132015 表示 Meta 已暫停此訊息範本，原因是其質素下降，通常是收件人封鎖或舉報使用該範本的訊息。號碼沒有問題，只有此訊息範本暫時無法發送。 ### 為何單一訊息範本會被暫停？ 因為質素會按訊息範本及號碼分別評估，質素欠佳的範本可以單獨隔離，無需影響其他內容。 Meta 會觀察收件人對每個訊息範本所發訊息的反應，包括封鎖、舉報，以及收件人是否有任何互動。持續引起負面反應的訊息範本會被暫停，而同一號碼上的其他範本仍可運作。這是有意縮小範圍的處理方式，實際上相當有用，因為它能清楚指出哪則訊息出現問題。 常見原因包括在實用訊息範本中加入推廣內容、訊息沒有清楚說明是哪間商戶發出，或向沒有預期收到訊息的人發送範本。 ### 訊息範本被暫停後應怎樣處理？ 修改範本，而不是重新發送，並把暫停視為內容問題的提示。 訊息範本在一段時間後可以恢復發送，但向相同類型的受眾發送相同內容，會產生相同反應，並導致再次暫停。多次暫停後，Meta 會永久停用訊息範本，屆時只能以不同內容建立新的範本，因此第二次暫停最值得避免。 修改通常包括在首行清楚說明用途、列出商戶名稱，以及如實交代收件人為何會收到訊息。同時也要檢查發送對象，因為即使內容良好的範本，發送給不感興趣的名單仍會產生相同訊號。 - 暫停解除後重新發送相同訊息範本，真正造成問題的是內容。 - 把問題理解為號碼出錯，同一號碼上的其他範本仍可運作。 - 等到第三次暫停，多次暫停會永久停用訊息範本。 **其他訊息範本仍可發送嗎？** 可以。暫停只適用於此訊息範本，號碼上其他已核准的範本不受影響。 **暫停會持續多久？** Meta 沒有公布固定時長，而多次暫停會令暫停時間延長。 **可以修改被暫停的訊息範本嗎？** 可以，修改範本正是處理重點。重新提交改善後的內容，訊息範本便有機會恢復。 **什麼是 132016？** 這是永久停用版本。訊息範本多次暫停後會被停用，必須以新範本取代。 --- ## WhatsApp 錯誤 100：參數無效 https://easycoexistence.com/zh-hant/docs/whatsapp-error-100 錯誤 100 表示請求帶有 Meta 不接受的參數：不受支援、拼寫錯誤，或不符合該端點所需的結構。這是可預期的錯誤，因此相同請求每次都會以完全相同的方式失敗，重試也沒有作用。 ### 甚麼情況會產生錯誤 請求本文或查詢內容有部分不獲端點識別，而成因通常一致且容易重現。 - 欄位名稱拼寫錯誤，或大小寫不正確。 - 參數屬於另一個端點。 - 值的類型不正確，例如端點預期整數，卻以字串傳送數字。 - 巢狀物件被攤平，或應使用物件的位置卻傳送了平面值。 ### 為甚麼重試沒有作用 因為每次嘗試之間，平台沒有任何改變。格式不正確的請求在第二次嘗試時，仍會因為與第一次相同的原因而失敗；圍繞此錯誤建立重試迴圈，只會在原有問題之上觸發速率限制，而不會成功。 有效的做法是把請求本文連同錯誤記錄下來，再逐一欄位與端點參考資料比較。幾乎每次都能在查看後一分鐘內找出差異。 - 重試。請求是可預期的，每次都會以完全相同的方式失敗。 - 以為問題出在號碼。此錯誤從不表示連接有任何問題。 - 把它當成一般錯誤。它明確指出參數問題，而更具體的代碼 131008 和 131009 分別用於參數缺失及數值超出範圍。 **這是否表示我的號碼壞了？** 不是。此錯誤只涉及請求，號碼不受影響。 **為甚麼錯誤訊息這麼含糊？** 這是參數問題的通用代碼。Meta 另有更具體的代碼，分別處理參數缺失和數值無效。 **供應商會導致這個錯誤嗎？** 只有在供應商建立請求時才可能。在直接整合中，請求由您建立。 **我應否使用退避機制重試？** 不應。這是可預期的錯誤，重試只會為非暫時性問題增加速率限制。 --- ## WhatsApp 錯誤 131008：缺少必要參數 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131008 錯誤 131008 表示請求缺少必要參數。它比錯誤 100 更精準，也更有用，因為錯誤 100 泛指參數格式錯誤，而此錯誤明確指出欄位不存在，而不是內容有誤。 ### 通常缺少甚麼 有些欄位看似可有可無，其實並非如此，所以同幾個欄位會不斷出現。 - messaging_product，每次發送都必須設定為 whatsapp。 - 需要此欄位的訊息格式中，recipient_type。 - 範本發送時的 language 物件，即使只有一種語言也必須提供。 - 定義變數的範本中的 components，空清單與省略欄位並不相同。 ### 為甚麼這是好消息 因為這是這類錯誤中最明確的一種。錯誤 100 只表示某處的參數有誤，而此錯誤明確指出必要參數完全不存在，讓您可以把搜尋範圍縮小至端點的必要欄位清單。 修正方法是閱讀所呼叫端點的參考文件，並按其必要欄位核對請求。這只需一分鐘，也是值得在記錄中把此錯誤與 100 分開，而不是同樣歸類為錯誤請求的原因。 - 把它與錯誤 100 視為相同。此錯誤指出欄位不存在，範圍更明確。 - 把空的 components 清單當作省略欄位。對 API 而言，兩者並不相同。 - 省略 messaging_product。每次發送都必須提供它，這是最常見的單一原因。 **缺少哪個參數？** 回應會指出缺少的參數。如沒有指出，端點參考文件會列出必要欄位清單。 **messaging_product 真的必須提供嗎？** 是，每次發送都必須設定為 whatsapp。這是最常見的省略欄位。 **這與 100 相同嗎？** 不相同。100 涵蓋存在但內容有誤的參數，此錯誤則涵蓋不存在的參數。 **重試有幫助嗎？** 沒有。請求結果是固定的，在加入欄位前每次都會出現相同錯誤。 --- ## WhatsApp 錯誤 131009：參數值無效 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131009 錯誤 131009 表示一個或多個參數值無效：欄位存在並已獲識別，但其內容並非端點接受的值。地區代碼、電話號碼格式及列舉值是最常見的原因。 ### 最常失敗的值 以下 3 種格式佔大多數，而且對閱讀者而言看起來都正確。 - 地區代碼：範本建立時使用 en_US，卻傳送 en；或範本使用 pt_BR，卻傳送 pt。 - 電話號碼包含標點、開頭的 0 或加號，但端點預期的是國際格式的純數字。 - 列舉值大小寫錯誤，例如範本類別使用小寫。 - 日期或時間戳記所用格式與端點文件所述格式不同。 ### 為甚麼要特別說明地區代碼問題 因為視乎端點而定，它會產生兩種不同錯誤，令人追查錯誤方向。 傳送範本時，如果該名稱沒有對應語言，會返回 132001，看起來像是找不到範本。若端點先驗證地區代碼，而您提供格式錯誤的值，則會返回此錯誤。兩者本質上是同一個錯誤，修正方法也是一樣：讀取範本清單，複製準確的語言字串，不要自行假定其格式。 - 以為 en 和 en_US 可以互換。兩者代表不同範本。 - 傳送帶有加號或標點的電話號碼。應使用國際格式的純數字。 - 重試。這個值必然是錯誤的。 **哪個值不正確？** 回應通常會指出參數。若沒有指出，應先檢查地區代碼及電話格式。 **電話號碼應如何格式化？** 使用國際格式的純數字，不要加入加號或標點。 **為甚麼同一個錯誤有時會返回 132001？** 因為傳送範本時會一併識別名稱及語言，未知的配對會被視為找不到範本。 **這是我的號碼有問題嗎？** 不是。這個錯誤只涉及請求。 --- ## WhatsApp 錯誤 131051：不支援的訊息類型 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131051 錯誤 131051 表示正在傳送的訊息類型不受支援。有時是類型值格式錯誤，但在 Coexistence 號碼上，更常見的原因是該類型不獲此類連接方式的平台允許。 ### 兩種不同原因 第一種是一般情況：類型值拼寫錯誤，或該類型並非 API 所定義。閱讀端點參考資料即可在 1 分鐘內解決。 第二種是結構性限制，而且代碼完全相同，因此容易令人誤判。Coexistence 號碼不能使用普通 Cloud API 號碼具備的所有功能。嘗試使用其中一項功能時，便會返回此錯誤，而不是更清晰的訊息。連接號碼已停用消失訊息、檢視一次媒體、即時位置及廣播清單，而群組聊天完全不在 API 範圍內。 ### 如何判斷是哪一種原因 取決於您嘗試傳送的內容。 - API 已定義，而且您之前曾傳送過的類型：屬於格式錯誤，請比較負載。 - 任何傳送至群組的內容：屬於結構性限制，任何服務供應商都無法啟用。 - 即時位置、檢視一次內容或消失訊息：在 Coexistence 號碼上屬於結構性限制。 - 全新且您之前未曾傳送的類型：檢查您的帳戶及所在地區是否提供該類型。 - 圍繞群組聊天建立功能。所有服務供應商的 API 都不包括群組聊天。 - 假設服務供應商可以啟用已停用的類型。這些限制屬於平台層面。 - 重試。兩種原因都不是暫時性問題。 **可以傳送訊息至群組嗎？** 不可以。在 Coexistence 號碼上，群組聊天不在 API 範圍內，所有服務供應商均一樣。 **為甚麼不支援即時位置？** 這是啟用 Coexistence 後，號碼上會停用的功能之一。 **可以修正嗎？** 如果原因是類型格式錯誤，可以。如果是平台限制，則不可以。 **這會影響接收嗎？** 不會。此錯誤涉及傳送不獲允許的類型。 --- ## WhatsApp 錯誤 131052：媒體下載失敗 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131052 錯誤 131052 表示 Meta 無法下載訊息所附的媒體。問題在於媒體本身，而不是您的請求，因此實際做法是要求對方以其他方式傳送，無需修改程式碼。 ### 為何會發生 因為入站媒體需要另外擷取，而不是直接送達。訊息會攜帶媒體 id，系統再使用它另行取得位元組。 擷取可能因發送者一方的問題而失敗，例如上載未完成、檔案在擷取前已過期，或產生檔案的程序未能保留其格式。這些情況從您的端點無法看見，也不能透過修改請求修復。 ### 應如何處理 把它視為一則收到但缺少附件的訊息，並按照其他不完整輸入處理。 - 記錄訊息，並將媒體標記為無法使用，不要捨棄整個事件。 - 盡快擷取媒體：id 不會永久有效。 - 如有人員介入，請客戶再次傳送，這可解決大部分情況。 - 不要無限重試。如果首次擷取和一次重試都失敗，媒體便不會再送達。 - 捨棄整則訊息。即使沒有附件，文字和內容仍然有用。 - 收到訊息很久後才擷取媒體。id 會過期。 - 循環重試。擷取失敗後很少會稍後成功。 **訊息遺失了嗎？** 沒有。訊息已送達，失敗的是擷取其附件。 **我應否要求客戶重發？** 如有人員介入，應該。這通常能快速解決問題。 **媒體 id 有效多久？** 並非永久有效，因此及時擷取十分重要。 **131053 也是同一回事嗎？** 不是。那是上載您正在傳送的媒體時發生的錯誤。 --- ## WhatsApp Cloud API 錯誤代碼 https://easycoexistence.com/zh-hant/docs/whatsapp-error-codes 這裡以一個表格列出我們記錄的所有 WhatsApp Cloud API 錯誤代碼，並說明每個代碼的意思及重試是否有用。大部分錯誤都沒有用，因為它們是確定性的。同一個請求會以相同方式失敗，重試迴圈只會把錯誤請求變成速率限制。 ### 如何閱讀重試欄 這一欄有 3 個值，選錯是整份參考資料中代價最高的錯誤。 「否」表示失敗具確定性。出問題的是請求、範本或收件人的狀態；再次傳送完全相同的請求，只會得到相同錯誤，並消耗日後需要的傳輸容量。「是」表示問題出在 Meta 一方，退避重試確實可以解決。「等待」表示條件真實存在，但只是暫時性限制或鎖定，會自行解除。在解除前重試沒有作用，還可能延長限制。 ### 為何大部分錯誤不能重試 因為平台會回傳具體代碼，而不是籠統代碼。參數格式錯誤、不存在的範本、已關閉的訊息視窗，以及已選擇退出的收件人，在回應當刻都可以判定，所以 Meta 會明確指出問題，而不是含糊地讓請求失敗。 - 請求有問題，第二次嘗試不會令它變正確。 - 範本有問題，問題存在於範本本身，請求無法改變它。 - 視窗或選擇退出的問題關乎收件人狀態，而不是您的狀態。 - 帳戶限制是一項決定，重試並不是申訴。 ### 收到這些代碼時要記錄甚麼 記錄足夠資料，讓您無需重現問題也能診斷。這是 5 分鐘修復與整天猜測之間的分別。 - 完整錯誤回應，包括追蹤 ID，因為 Meta 支援會要求這項資料。 - 實際傳送的請求主體，而不是您原本打算傳送的內容。兩者之間的差異通常就是錯誤所在。 - 號碼 ID，讓您分辨單一號碼的問題與整個帳戶的問題。 - 時間戳記，讓您可以核對該刻連接的狀態。 ### 只存在於 Coexistence 的代碼 其中有 2 個。它們看起來像普通的傳送失敗，因此容易令人混淆。2593107 和 2593108 都與聊天記錄同步有關，也就是首次連接號碼時，從 WhatsApp Business 應用程式複製最近對話的步驟。 它們不是訊息錯誤，也不代表連接失敗。同步超出限制或在時限外執行時，號碼仍會保持連接並正常傳送，只是複製的記錄少於預期。若將它們理解為連接故障，便可能斷開連接後重新開始，結果只會遺失更多記錄，而不是恢復記錄。 - 預設重試。大部分代碼具確定性，重試迴圈只會額外招致速率限制。 - 記錄錯誤卻沒有請求主體。實際傳送與原本意圖之間的差異通常就是錯誤所在。 - 把同步錯誤理解為連接故障。號碼仍然保持連接並正常傳送。 - 捨棄追蹤 ID。它是令支援工單可以採取行動的唯一資料。 **哪些錯誤應該重試？** 131016 和 131000，配合指數退避。130429、132015 和 133008 在等待後會自行清除。其他錯誤都具確定性。 **錯誤代碼是否代表我的號碼已斷開連接？** 通常不是。大部分錯誤與請求、範本或收件人有關。連接問題會以帳戶及品質 Webhook 顯示，而不是傳送錯誤。 **甚麼是追蹤 ID？** 錯誤回應中的識別碼，讓 Meta 支援找出特定請求。每次失敗都應記錄；沒有它，支援工單便無法處理。 **這些代碼在每個供應商都相同嗎？** 是。它們來自 Meta 的 Cloud API，因此無論由哪個供應商連接號碼，代碼都相同。供應商只能改變錯誤通知您時的清晰程度。 --- ## WhatsApp 錯誤 131053：媒體上載失敗 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131053 錯誤 131053 表示 Meta 無法上載請求中的媒體。不同於相關的傳入錯誤 131052，這次涉及您控制的檔案，因此可以修正：檢查大小和格式；如您傳送連結，亦要確認 Meta 是否確實能夠連接該連結。 ### 三個原因 以下按實際發生的先後排列。 - 大小：檔案超出其類型的上限。圖片 5 MB，影片和音訊 16 MB，文件 100 MB。 - 格式：API 不接受的編解碼器或容器，使用編輯軟件匯出的影片常見此問題。 - 連接：您傳送連結而非已上載的 id，而 URL 可能需要登入、受防火牆阻隔或重新導向。 - 有效期：已上載的媒體 id 在建立很久後才使用。 ### 上載比連結更可靠 傳送連結會讓 Meta 在傳送時擷取檔案，增加一個您無法從自己的網絡看見的失敗途徑。即使 URL 在您的瀏覽器中完全正常載入，Meta 的基礎設施仍可能因地理位置、防火牆規則或瀏覽器已持有的驗證 Cookie 而無法連接。 先上載檔案，再傳送返回的媒體 id，便能完全排除這類失敗。這只需多發出一個請求，並令傳送結果更可預測，對任何大量傳送的內容都值得採用。 - 以為在您的瀏覽器中正常運作的 URL，對 Meta 也會正常。您的工作階段和網絡並不等同於 Meta 的。 - 匯出影片時沒有檢查編解碼器。編輯軟件的預設設定往往不受支援。 - 上載很久後重用媒體 id。id 會過期。 **大小上限是多少？** 圖片 5 MB，影片和音訊 16 MB，文件 100 MB。 **應該上載檔案還是傳送 URL？** 上載檔案。這會排除連接問題這個失敗原因。 **URL 對我有效，為甚麼對 Meta 無效？** Meta 使用的網絡與您的不同。地理位置、防火牆和驗證方式都可能不同。 **這與 131052 相同嗎？** 不相同。131052 表示下載客戶傳送給您的媒體失敗。 --- ## WhatsApp 錯誤 131016：服務無法使用 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131016 錯誤 131016 表示 Meta 一方的服務暫時無法使用。這是少數真正屬於暫時性的系統錯誤，因此正確做法是採用指數退避重試，而不是展開調查。 ### 為何這個錯誤不同 此平台的大多數錯誤都是可確定的：請求格式錯誤、範本不存在，或訊息時段已結束。重試這些請求只會浪費請求次數，並觸發速率限制。 此錯誤是例外。它並不表示您的請求或號碼有問題，只表示 Meta 運行的某項服務目前無法回應。同一個請求通常在一分鐘後便會成功，這正是退避機制的用途。 ### 如何正確重試 請保持克制，因為大量同時重試會令服務中斷更加嚴重。 - 指數退避：先等待 1 秒，再等 2 秒、4 秒，然後 8 秒。 - 設定嘗試次數上限，通常為 5 次，之後將訊息放入佇列稍後處理。 - 加入抖動，避免大量工作程序同時重試。 - 確保冪等性，避免訊息其實已在錯誤傳回前送出，結果被重複發送。 - 立即在緊密迴圈中重試，會增加已經不堪負荷的服務壓力。 - 把它當成連接問題，您的號碼沒有問題。 - 重試時不設上限，有些服務中斷時間比任何重試政策都長。 **我應否重試？** 可以，請採用指數退避。這是重試有效的錯誤之一。 **我的號碼受到影響嗎？** 不會。這是平台一方的故障。 **這些故障通常持續多久？** 通常為數秒至數分鐘。重試 5 次的退避機制足以應付大多數情況。 **如何分辨這是真正的服務中斷？** 觀察問題是否持續即可。持續監察能讓您無需猜測。 --- ## WhatsApp 錯誤 131000：發生問題 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131000 錯誤 131000 表示訊息因 Meta 未分類的原因而傳送失敗。這是未分類錯誤類別，實際處理方法是先配合退避重試一次；如仍然失敗，便附上回應中的 trace id 提交支援工單。 ### 實際涵蓋甚麼 凡是 Meta 的傳送路徑處理失敗，但未將失敗對應至具名代碼的情況，都可能屬於此類。這包括真正的短暫故障、內部問題，以及偶爾在較新 API 版本已有特定代碼，但當時尚未提供代碼的情況。 由於這個錯誤類別涵蓋範圍廣泛，沒有單一回應方式適用於所有情況。單次出現通常只是雜訊。同一收件人反覆出現此錯誤，則值得提交支援工單。 ### 應如何處理 按以下次序處理，成功後便停止。 - 配合短暫退避重試一次，部分情況屬於短暫故障。 - 記錄完整回應，包括支援會要求的 trace id。 - 檢查是單一收件人還是所有收件人受影響。單一收件人指向該號碼，全部收件人則指向平台。 - 如重試後仍然失敗，提交支援工單，並附上 trace id 及時間戳記。 - 無限次重試。若兩次嘗試都失敗，便不屬於短暫故障。 - 捨棄 trace id。它是令支援工單可供處理的唯一關鍵資料。 - 假設這表示您的號碼已損壞。通常並非如此。 **應否重試？** 重試一次並配合退避。超過一次便不屬於短暫故障。 **甚麼是 trace id？** 錯誤回應中的識別碼，讓 Meta 支援找出特定請求。 **這是否表示我的號碼已停止運作？** 通常不是。請檢查其他訊息是否仍能成功傳送。 **何時應提交支援工單？** 當重試後仍反覆出現錯誤，並附上 trace id 及時間戳記。 --- ## WhatsApp 錯誤 131021：寄件者和收件者是同一個 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131021 錯誤 131021 表示寄件者和收件者是同一個號碼。WhatsApp 不容許商業號碼向自己發送訊息，而原因幾乎總是測試訊息發送至已連接號碼，而不是另一部電話。 ### 為甚麼會發生 因為任何人在連接號碼後，第一件事通常是發送測試訊息，而眼前唯一可用的號碼，就是剛剛連接的那個。這是合理的直覺，但平台會拒絕這種操作。 沒有任何設定可以更改。WhatsApp 一般用戶應用程式支援「給自己留言」功能，但 API 不支援這項功能。 ### 如何正確測試 使用第二個號碼，並仔細確認測試的發送方向。 - 使用個人電話作為測試收件者。除已連接號碼外，任何 WhatsApp 號碼都可以使用。 - 如要自由測試發送，先讓測試號碼向商業帳戶發送訊息，這會開啟 24 小時服務時段。 - 如要在該時段以外測試，請發送已獲批准的訊息範本，這是該時段唯一獲准使用的內容。 - 除非有需要，否則不要只為測試而註冊第二個商業號碼：普通個人號碼已經足夠。 - 向已連接號碼發送訊息進行測試。平台設計上會拒絕這項操作。 - 以為「給自己留言」可以透過 API 使用。這是不可能的。 - 在客戶尚未先發送訊息的情況下測試自由格式訊息，這會改為因錯誤 131047 而失敗。 **可以向自己的號碼發送訊息嗎？** 不可以。WhatsApp 不容許透過 API 這樣做。 **有相關設定嗎？** 沒有。這是平台規則。 **應該使用甚麼進行測試？** 任何其他 WhatsApp 號碼，包括個人電話。 **為甚麼我的測試之後以 131047 失敗？** 因為自由格式訊息要求客戶在過去 24 小時內曾向您發送訊息。 --- ## WhatsApp 錯誤 131045：電話號碼未註冊 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131045 錯誤 131045 表示電話號碼尚未註冊 Cloud API 訊息功能。將號碼加入 WhatsApp Business 帳戶，以及註冊號碼以發送訊息，是兩個獨立步驟。此錯誤表示第二個步驟未完成。 ### 為何有兩個步驟 因為 WhatsApp Business 帳戶可以儲存尚未發送訊息的號碼。加入號碼可確認擁有權，註冊號碼則會啟用 Cloud API 訊息功能，並設定其兩步驟 PIN。 手動設定時，這是兩個獨立的 API 請求，很容易完成第一個後忘記第二個。這樣一來，號碼會顯示在帳戶中，在控制台看似正確，卻會因這個錯誤拒絕所有發送。 ### 如何解決 視乎號碼加入帳戶的方式而定。 - 手動設定時，使用該電話號碼 id 的兩步驟 PIN 呼叫 register 端點。 - 透過服務供應商進行 Coexistence 導入時，註冊會在流程中完成，因此這個錯誤通常表示流程未完成。 - 如果號碼最近從其他帳戶遷移，必須在新帳戶中重新註冊。 - 如果註冊本身失敗，原因通常是 PIN，錯誤代碼為 133005。 - 以為控制台中顯示的號碼已可發送訊息。顯示與已註冊是兩回事。 - 中途放棄導入流程。最後幾個步驟才會完成註冊。 - 將此錯誤與 133006 混淆，後者關乎驗證而非註冊。 **甚麼是註冊？** 啟用號碼以使用 Cloud API 訊息功能，與將號碼加入帳戶是兩個獨立步驟。 **需要自行完成嗎？** 手動設定時需要。透過 Coexistence 流程則會代您處理。 **需要重新註冊嗎？** 只有在將號碼遷移至其他帳戶後才需要。 **如果註冊失敗怎麼辦？** 通常是兩步驟 PIN 的問題，會返回錯誤代碼 133005。 --- ## WhatsApp 錯誤 133005：兩步驟驗證 PIN 不正確 https://easycoexistence.com/zh-hant/docs/whatsapp-error-133005 錯誤 133005 表示註冊時提供的兩步驟驗證 PIN 不正確。這是號碼首次註冊時設定的 6 位數字 PIN，連續輸入錯誤會鎖定後續嘗試，因此恢復途徑比重試更重要。 ### PIN 從何而來 號碼首次註冊使用 Cloud API 傳送訊息時會設定此 PIN，之後任何再次註冊都需要它，包括將號碼遷移到另一個帳戶之後。 問題就出在這段空檔。PIN 在設定時只用一次，隔了一年才再需要，很少有人記下來，而當初設定的人往往已經離職。於是錯誤恰好在移動或重新註冊號碼的時候出現，而這本來就是壓力很大的時刻。 ### 如果沒有人知道 PIN 仍有辦法，雖然比亂猜慢，但確實可行。 - 停止猜測。重複失敗會傳回 133008，並在一段時間內鎖定嘗試。 - 在 WhatsApp Manager 中，於該號碼的兩步驟驗證設定下更改 PIN；沒有可以停用它的 API 端點。 - 管理員也可以透過 API，向電話號碼 ID 發出 POST 請求來設定新 PIN，然後用它重新註冊。 - 恢復後，請把新 PIN 存放在下一位同事找得到的地方。 ### 如何避免再次發生 請把 PIN 當作基礎設施，而不是個人資料。它應與帳戶憑證存放在同一個地方，由企業持有，而非由碰巧負責設定的人持有，並且在該人離職後仍然保存下來。 不這樣做的代價不是錯誤本身，那只是小事。真正的代價是在您需要時，無法遷移或重新註冊一個運作中的號碼。 - 重複猜測。這會觸發 133008 並導致鎖定。 - 把 PIN 交由一個人保管，而不是由企業保管。 - 以為設定後就不再需要。遷移時需要它。 **這個 PIN 是在哪裏設定的？** 在號碼首次註冊使用 Cloud API 傳送訊息時設定。 **如果我不知道 PIN 怎麼辦？** 在 WhatsApp Manager 中，於該號碼的兩步驟驗證設定下更改，或透過 API 設定新的 PIN。 **如果我繼續猜會怎樣？** 嘗試會被鎖定，您會收到錯誤 133008。 **什麼時候需要 PIN？** 註冊時需要，之後任何重新註冊或遷移時也需要。 --- ## WhatsApp 錯誤 133008：PIN 猜測次數過多 https://easycoexistence.com/zh-hant/docs/whatsapp-error-133008 錯誤 133008 表示兩步驟驗證 PIN 輸入錯誤次數過多，系統會暫時封鎖後續嘗試。這通常是在多次出現 133005 錯誤後發生，因此輸入錯誤 PIN 時，正確做法是停止嘗試，而不是再次猜測。 ### 甚麼會觸發錯誤 連續幾次輸入錯誤 PIN 很容易觸發此錯誤，因為錯誤的 PIN 讓人覺得值得再試一次。其實不應如此。首次出現 133005 時，應先正確找出 PIN，而不是再次猜測。 號碼鎖定後，必須等候指定時段過去才能重新註冊，即使期間找到了正確 PIN 也一樣。 ### 鎖定期間應怎樣做 利用等候時間處理問題，不要反覆嘗試。 - 停止嘗試。繼續輸入可能延長鎖定時間，而不是縮短時間。 - 在等候期間找回或重設 PIN：使用帳戶層級存取權杖停用兩步驟驗證，或聯絡 Meta 支援。 - 確認您註冊的是正確的電話號碼 ID。對錯誤號碼輸入 PIN 失敗時，顯示的情況可能完全相同。 - 安排在鎖定時段結束後重試，不要持續查詢。 - 號碼鎖定後仍繼續嘗試。這沒有幫助，還可能延長鎖定時間。 - 只是等待，卻沒有利用時間正確重設 PIN。 - 以為號碼已被封禁。PIN 鎖定是暫時的，與政策執行無關。 **鎖定會持續多久？** 由 Meta 設定的一段時間。在此期間繼續嘗試，可能延長而不是縮短鎖定時間。 **我的號碼被封禁了嗎？** 不是。這是驗證鎖定，與政策執行無關。 **鎖定期間可以重設 PIN 嗎？** 可以，這是最值得利用等候時間處理的事項。 **為甚麼會發生這種情況？** 重複輸入錯誤 PIN，而每次都返回 133005。 --- ## WhatsApp 錯誤 133006：號碼未驗證 https://easycoexistence.com/zh-hant/docs/whatsapp-error-133006 錯誤 133006 表示電話號碼須先驗證，才能登記訊息功能。驗證會透過 SMS 或語音通話傳送代碼，以確認您能控制該號碼；這是獨立於新增號碼及登記的步驟。 ### 驗證與登記的分別 驗證可證明商戶能控制該號碼。登記則會啟用 Cloud API 訊息功能。兩者按此順序進行，而此錯誤表示第一步尚未完成。 實際要求是必須有人能透過 SMS 或自動語音通話，在該號碼上接收代碼。無人能接聽的號碼無法驗證；在大多數情況下，真正的阻礙是這一點，而不是 API 請求。 ### 哪些情況會阻礙驗證 幾乎總是實體條件，而非技術問題。 - 沒有人持有該手提電話或 SIM 卡，這在接手前任持有人的號碼時很常見。 - 該號碼是無法接收 SMS 的固網電話，此時應使用語音驗證。 - 虛擬號碼的供應商會過濾或延遲驗證碼。 - 該號碼已在另一個 WhatsApp 帳戶登記，必須先處理這個問題。 - 在驗證前嘗試登記。步驟次序很重要。 - 在固網電話上選擇 SMS。語音驗證正是為沒有 SMS 的號碼而設。 - 假設虛擬號碼一定能可靠接收代碼。許多虛擬號碼都不能。 **如何驗證？** 使用傳送至該號碼本身的 SMS 或自動語音通話代碼。 **固網電話怎麼辦？** 使用語音驗證，這適用於無法接收 SMS 的號碼。 **這是否等同於登記？** 不是。驗證是確認控制權，登記則會啟用訊息功能。 **可以跳過嗎？** 不可以。完成驗證前，登記會持續返回此錯誤。 --- ## WhatsApp 錯誤 131050：使用者已取消接收訊息 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131050 錯誤 131050 表示收件人已取消接收您的商業訊息。這不是故障，也沒有技術方法可以繞過：對方已作出選擇，正確做法是記錄該選擇並停止發送。 ### 為甚麼沒有繞過方法 因為這套機制旨在保護使用者，避免受到不接受拒絕的商業帳戶打擾。若平台可以繞過這項機制，對任何一方都沒有存在價值。 Meta 亦會監察之後發生的情況。持續嘗試向已取消接收訊息的人發送訊息，會影響質素評分相關的訊號。質素評分下降，會削減整個號碼的訊息發送容量，而不只是影響這些收件人。 ### 應該怎樣處理 妥善記錄一次，讓系統其餘部分遵守這項選擇。 - 將取消接收的選擇儲存在聯絡人資料中，避免系統再次自動嘗試。 - 在每個宣傳活動及自動化流程中停止向該號碼發送訊息，不只是觸發錯誤的活動。 - 不要使用第二個商業號碼聯絡對方。對方仍是同一人，選擇亦沒有改變。 - 如果對方日後先向您發送訊息，服務時段便會重新開啟，您可以回覆。這是對方的選擇，不是您的選擇。 - 重試發送。封鎖是刻意設計的，會持續有效，直至本人更改選擇。 - 只在失敗的宣傳活動中停止發送，導致另一個活動翌日再次嘗試。 - 使用其他號碼聯絡同一人。這仍然是在忽略對方同一項選擇。 **可以再次向對方發送訊息嗎？** 只有對方先向您發送訊息，重新開啟服務時段後才可以。 **有方法可以繞過嗎？** 沒有，而且嘗試繞過會損害您的質素評分。 **這會影響整個號碼嗎？** 取消接收只適用於該收件人，但重複嘗試會影響您整體的質素評分。 **應該將對方從清單移除嗎？** 應在所有地方停止向對方發送訊息，不只是失敗的宣傳活動。 --- ## WhatsApp 錯誤 130497：不允許收件人所在國家 https://easycoexistence.com/zh-hant/docs/whatsapp-error-130497 錯誤 130497 表示您的帳戶不允許向收件人所在國家傳送訊息。這是地域限制，與收件人本身無關，通常反映帳戶限制，而不是請求出錯。 ### 甚麼原因導致國家限制 原因有多個，而且並非全部永久存在。 - 新帳戶或未經驗證的帳戶，在完成商業驗證後限制可能解除。 - Meta 在整個平台套用限制的國家。 - 帳戶在審查或執行措施期間設定的帳戶層面控制。 - 號碼使用錯誤的國家代碼，導致您從未打算傳送訊息的國家出現此錯誤。 ### 先排除格式問題 這是唯一可以自行修正的原因，而且比其他原因更常見。 如果保留電話號碼開首的 0，或省略國家代碼而套用預設值，系統會將號碼解析至與原定不同的國家。傳送訊息時，便會因該國家的限制而失敗。檢查號碼是否採用國際格式、只包含數字，並使用正確的國家代碼，只需一秒，便可排除最可能的原因。 - 以為問題出在收件人。限制針對您的帳戶及該國家。 - 重試傳送。各次嘗試之間不會有任何變化。 - 跳過格式檢查，這是唯一可由您控制的原因。 **收件人是否封鎖了我？** 不是。這是針對您帳戶的國家層面限制。 **可以解除嗎？** 部分限制是暫時的，完成商業驗證後會解除。其他限制則適用於整個平台。 **會否是格式錯誤？** 有可能，值得先排除。錯誤的國家代碼會將號碼解析至錯誤的國家。 **重試有幫助嗎？** 沒有。各次嘗試之間限制不會改變。 --- ## WhatsApp 錯誤 132007：違反範本政策 https://easycoexistence.com/zh-hant/docs/whatsapp-error-132007 錯誤 132007 表示範本違反 WhatsApp 的商業訊息政策。訊息無法以目前形式發送，您應重寫並重新提交範本，而不是更改請求內容。 ### 政策實際禁止哪些內容 當大多數人撰寫第一個範本時，政策限制往往比他們想像中更嚴格。 - 對方沒有要求接收，內容卻像未經同意的推廣訊息。 - 受禁止的類別，包括某些金融、健康及受規管產品。 - 歪曲發送者身分，或暗示不存在的關聯關係。 - 誤導性的緊迫語氣，或任何旨在迫使對方回覆的結構。 ### 為何類別與措辭同樣重要 範本以工具類別提交，內容卻像營銷訊息，即使內容本身沒有不當之處，仍然屬於政策問題。Meta 為範本分類，是因為兩者對同意的要求不同；以工具類別發送推廣訊息，便違背這項原則。 實際做法是按範本的真正類別撰寫。坦白表明是營銷訊息的範本可以獲批；把營銷訊息包裝成送貨通知則不行。只修改措辭而不更改類別，通常無法挽救範本。 - 重試發送。問題在範本，而不是請求。 - 只作表面修改後重新提交。類別錯誤時，措辭無法挽救範本。 - 以為獲批後便永久有效。範本日後仍可能因 132016 被停用。 **可以重試發送嗎？** 不可以。您必須重寫並重新提交範本。 **為何措辭看似沒有問題，仍然被拒？** 通常是類別問題。以工具類別提交的營銷訊息，無論措辭如何，仍然屬於政策問題。 **重新提交需要多久？** 審查通常很快，但沒有保證的處理時間。 **這與 132016 相同嗎？** 不相同。132016 指範本獲批後被永久停用。 --- ## WhatsApp 錯誤 132012：訊息範本參數格式不符 https://easycoexistence.com/zh-hant/docs/whatsapp-error-132012 錯誤 132012 表示傳送的參數值與訊息範本所定義的格式不符。包含 3 個變數的訊息範本需要不多不少的 3 個參數，順序及類型亦要正確；任何偏差都會導致此錯誤，而不會只傳送部分訊息。 ### 哪些內容必須一致 全部都要一致，而且不會提示。不存在部分匹配。 - 數量：內文有 3 個佔位符，即需要 3 個內文參數，不多不少。 - 順序：參數按位置排列，因此交換兩個參數會令傳送訊息的值放錯位置；若類型不同，則會產生此錯誤。 - 類型：貨幣或日期參數有指定的物件結構，不能以純文字傳送。 - 元件：標題、內文及按鈕參數分屬不同清單，不能合併為一個清單。 ### 導致正式環境中斷的編輯 編輯訊息範本的人，往往不是呼叫 API 的人。有人為了讓訊息更清晰而加入變數，訊息範本重新獲批後，所有來自未修改整合的傳送便開始失敗。 與其事後發現，不如預先防範。訂閱訊息範本狀態 Webhook 後，編輯會以事件形式送達；將訊息範本的變數數量視為整合規格，並在變更時審查，就能避免文字改善演變成服務中斷。 - 為了預防問題而傳送額外參數。過多與過少同樣錯誤。 - 把位置參數當作具名參數處理。它們只會按位置配對。 - 編輯訊息範本時沒有檢查負責傳送的程式碼。 **我要傳送多少個參數？** 數量必須與訊息範本定義的完全相同，並按順序傳送。 **可以傳送額外參數嗎？** 不可以。過多參數與過少參數一樣會失敗。 **為甚麼突然開始出現這個問題？** 通常是因為訊息範本經過編輯，變數數量有所改變。 **參數有名稱嗎？** 沒有。參數按位置配對，因此順序很重要。 --- ## WhatsApp 錯誤 132016：範本已永久停用 https://easycoexistence.com/zh-hant/docs/whatsapp-error-132016 錯誤代碼 132016 表示範本已永久停用，不能再次使用。這通常是品質下降的終點：收件人封鎖或舉報使用該範本發出的訊息，範本的品質評分下跌，Meta 隨後將其撤回。 ### 範本如何走到這一步 通常不是一步到位。已獲批准但不受收件人歡迎的範本會累積封鎖及舉報，品質評分由綠色降至黃色，再降至紅色，然後被暫停。反覆暫停最終會導致永久停用。 只要您有監察，整個過程都可以觀察到。範本品質 Webhook 會回報每次變更，而範本轉為黃色時仍是警告，您還有時間處理。忽略警告，正是可用範本變成無法使用範本的原因。 ### 應如何處理 按以下次序處理兩件事。 - 停止使用該範本發送訊息，並改用其他範本，因為它永遠不能再次使用。 - 在撰寫替代範本前，先了解收件人不喜歡它的原因，否則替代範本會重蹈覆轍。 - 除了措辭，也要檢查受眾。向不預期收到訊息的人發送優質範本，仍會累積封鎖。 - 訂閱範本品質 Webhook，讓您在下一次品質下降至黃色時，而不是停用後，及時得知。 - 以新名稱重新建立相同範本。真正失敗的是內容。 - 忽略黃色品質評分。黃色是警告，紅色是後果。 - 受眾才是問題，卻把責任歸咎於措辭。 **可以重新啟用嗎？** 不可以。永久停用就是永久停用。 **可以用新名稱重新建立嗎？** 可以，但導致品質下降的是內容，因此很可能重蹈覆轍。 **這與 132015 有何不同？** 132015 是暫停，之後會解除；這個代碼則不會。 **我本來可以預先察覺嗎？** 可以。範本品質 Webhook 會在情況發展至這一步前回報下降。 --- ## WhatsApp 錯誤 131056：向單一收件人傳送過多訊息 https://easycoexistence.com/zh-hant/docs/whatsapp-error-131056 錯誤 131056 表示您的商業號碼在短時間內向單一收件人傳送過多訊息。這是每組配對獨立計算的速率限制，與帳戶整體吞吐量分開，通常表示某項自動化程序不斷重複執行。 ### 為何按配對計算 因為它要防止的不是一般訊息量過多，而是單一人士被大量訊息淹沒。帳戶可能仍在整體吞吐量限制之內，卻在 1 分鐘內向一名收件人傳送 30 則訊息。對方會將此視為垃圾訊息，不論帳戶的總量是多少。 因此，限制按配對而非帳戶套用。這就是為何訊息量低、從未接近整體速率限制的號碼，也可能出現此錯誤。 ### 通常由甚麼造成 幾乎總是由自動程序造成，而不是由人士逐一輸入。 - 重試迴圈將傳送失敗誤判為傳遞失敗，然後再次傳送。 - Webhook 處理程式傳送回覆，卻因同一事件被多次觸發而重複執行。 - 聊天機械人將一個回覆拆成多則短訊息，並在短時間內連續傳送。 - 開發期間，測試指令碼反覆向同一號碼傳送訊息。 ### 如何避免 在對話層級限制傳送速度，而不只是按帳戶限制。傳送前套用每名收件人每分鐘的訊息上限，幾乎不會增加成本，卻可避免此錯誤及背後造成的客戶體驗問題。 訊息去重同樣重要。Webhook 事件可能被傳送多於一次；如果處理程式沒有先確認是否已處理該訊息 ID，負載增加時便會準確地產生這種情況。 - 重試，向已被大量訊息淹沒的收件人再傳送一則訊息。 - 只按帳戶層級限制傳送速度。此限制按收件人計算。 - 處理 Webhook 事件時，沒有按訊息 ID 去重。 **這是我帳戶的速率限制嗎？** 不是。帳戶的整體限制代碼是 130429。此限制按收件人計算。 **為何訊息量低的號碼也會出現？** 因為限制按配對套用，而非按帳戶總量套用。 **如何停止此錯誤？** 按對話限制傳送速度，並按訊息 ID 為 Webhook 事件去重。 **我應否重試？** 不應重試，因為重試會向同一收件人再傳送訊息。 --- ## WhatsApp 錯誤 80007：WhatsApp Business 帳戶的頻率限制 https://easycoexistence.com/zh-hant/docs/whatsapp-error-80007 錯誤 80007 表示 WhatsApp Business 帳戶已觸及頻率限制。這項限制適用於管理及讀取請求，而非訊息傳送量，因此常見原因是輪詢：某項功能檢查狀態的頻率遠高於資料變更的頻率。 ### 它計算甚麼 針對帳戶的請求，而不是傳送給客戶的訊息。 - 讀取號碼、號碼的品質評分及傳送量水平。 - 列出及讀取訊息範本。 - 訂閱及 Webhook 設定請求。 - 按排程執行的任何狀態檢查，請求量通常由此產生。 ### 輪詢是值得修正的原因 每 30 秒對少量號碼進行一次狀態輪詢，每天便會對變更每月只有數次的資料發出數千次請求。這最終會觸及限制，而一旦觸及，輪詢便會在最需要得知變更的時刻停止運作。 Webhook 會把流程倒轉。Meta 會在品質評分、帳戶或訊息範本狀態變更時推送通知，完全不會消耗請求，而且比任何輪詢更快到達。正確的架構是使用 Webhook 接收變更，並只偶爾以輪詢進行核對，而非把輪詢作為主要機制。 - 以短間隔輪詢狀態，消耗頻率限制，但資料很少變更。 - 改為加入重試，令頻率限制更快耗盡。 - 將其與 130429 混淆，後者與傳送訊息有關。 **這是否與傳送訊息有關？** 不是。該項限制是 130429；這項限制涵蓋管理及讀取請求。 **甚麼原因會導致這個錯誤？** 通常是以短間隔輪詢狀態。 **我應該改為怎樣做？** 訂閱 Webhook，並只在需要時以輪詢進行核對。 **它會自行清除嗎？** 會，限制時段結束後便會清除；但如果不改變輪詢方式，問題會再次出現。 --- ## WhatsApp Coexistence 適用於代理商及顧問公司 https://easycoexistence.com/zh-hant/whatsapp-coexistence-for-agencies 代理商面對每位客戶時都會遇到同一個障礙：號碼由客戶員工一直負責接聽，而遷移號碼會令他們失去 WhatsApp Business 應用程式。Coexistence 消除了這個障礙，讓您連接客戶號碼，而無需改變任何人的工作方式。 ### 為甚麼客戶號碼會阻礙大部分整合？ 因為您無權更改該號碼，而與它相關的一切都已經投入使用。 客戶的號碼印在車輛、發票、網站上，也出現在多年的過往對話中。有人整天用電話接聽，並且熟悉每位熟客的姓名。當方案涉及遷移該號碼時，WhatsApp Business 應用程式便會停止在該號碼上運作，而那位員工也必須改用您建立的系統。大部分客戶都會拒絕，而且他們的做法是正確的。 因此，很多代理商最終使用非官方閘道。這些閘道讓電話繼續運作，正是客戶唯一在意的事情，而封禁風險一直隱藏，直到風險變成現實。Coexistence 是同一承諾的官方版本。 ### 客戶實際上如何完成開戶？ 客戶只需在自己的電話上完成一件事，整個過程約需兩分鐘。 您向客戶發送連接連結。他們開啟連結後，Meta 的彈出視窗會執行，接着選擇自己的 Business Portfolio 和號碼，再於 WhatsApp Business 應用程式中掃描代碼。這就是全部要求。無需安裝任何軟件，也無需交出認證資料；掃描完成後，應用程式便會立即繼續運作。 號碼會留在客戶的 Business Portfolio，而不是您的帳戶之下，這有兩個原因。當客戶問誰擁有連接時，這就是答案；而且即使客戶轉換代理商，關係仍然可以延續。這比事後才解釋更容易承諾。 ### 管理二十位客戶時會是甚麼情況？ 一個帳戶、二十個號碼、每個號碼一項固定費用，以及一份清晰可讀的清單。 沒有需要升級的級別，也沒有在某個門檻後改變的方案。新增第二十一位客戶，操作方式與第一位完全相同。每個號碼都會回報自己的品質評分、訊息層級及連接狀態，因此當客戶的號碼狀況轉差時，您可以在他們聯絡您之前發現問題。 在這個規模下，這種可見度就是大部分價值所在。連接可能會無聲無息地失效，而 WhatsApp Business 應用程式在幾乎所有故障期間仍會繼續運作，客戶無從得知。沒有監察時，第一個訊號往往是客戶問為甚麼自動化停止，這是一段很難有良好開端的對話。 ### 代理商可以由代理程式代替人員完成開戶嗎？ 大部分可以，而不能完成的部分，正是客戶本來就必須親自完成的部分。 透過 MCP 連接器，助理可以呼叫 get_connect_link，產生客戶要開啟的連結；然後呼叫 set_webhook_destination，將該號碼指向您用來處理訊息的系統；最後檢查號碼狀態，確認一切已經上線。整個流程都不需要任何人開啟控制台。 它不能做的是掃描代碼。Meta 的開戶流程在瀏覽器中執行，並需要持有該號碼的電話，這是刻意設計的保障，而不是缺陷。客戶是唯一可以授權自己號碼的人，這才是正確的安排。 - 向客戶承諾員工不會察覺，然後才遷移號碼。遷移會令他們失去應用程式，他們會立即發現。 - 將客戶號碼連接到您自己的 Business Portfolio。每個號碼都應留在客戶的 Business Portfolio，讓連接真正屬於他們。 - 把大規模監察視為可有可無。二十位客戶各自出現無聲故障，便是支援負荷，而不是邊緣情況。 **每位客戶都需要在您這裡擁有自己的帳戶嗎？** 不需要。一個帳戶可管理您負責的所有號碼，每個號碼獨立收費，連接器會列出全部號碼。您可以將它用於所服務的企業，沒有相關限制。 **連接由我還是客戶擁有？** 號碼會留在客戶的 Business Portfolio。您負責管理連接，而與 Meta 的底層關係屬於客戶。當客戶提出疑問時，這就是誠實的答案。 **如果客戶離開，會發生甚麼事？** 號碼會中斷連接，而客戶的 WhatsApp Business 應用程式會完全如常運作。號碼不會因曾經連接而永久改變。 **誰向 Meta 支付訊息費用？** 客戶會透過自己 WhatsApp Business Account 上的付款方式支付。這些費用不會經由我們收取，因此沒有人可以在其上加價。 --- ## Meta Tech Provider 是甚麼，為何重要 https://easycoexistence.com/zh-hant/meta-tech-provider Meta Tech Provider 在已驗證的 Business Manager 上運行自己的 Meta 應用程式，並透過它連接其他商戶的 WhatsApp 號碼。EasyCoexistence 正是其中之一，因此號碼會直接連接至您自己的 Business Portfolio，而不是置於轉售商的帳戶下。 ### Tech Provider 實際上做甚麼？ 它運行其他商戶用來連接 WhatsApp 號碼的應用程式。 商戶開始連接時，Meta 的 Embedded Signup 會開啟，並要求商戶授權一個應用程式。該應用程式屬於 Tech Provider，獲授權後便可代表商戶操作其號碼：讀取狀態、傳送訊息、管理範本，以及設定 Webhook 的傳送位置。供應商提供的一切功能，都建基於這段關係。 這個身份令連接具備合法性。Meta 會在 App Review 後，向擁有自己應用程式及已驗證 Business Manager 的公司授予此身份，這也正是供應商與持有他人憑證的程式之間的分別。 ### 為何應用程式由誰擁有很重要？ 因為這決定客戶的號碼最終會連接至誰的帳戶。 建基於他人供應商帳戶的工具，會繼承該帳戶的限制。這正是通用自動化平台出現單一連接上限的原因：平台只持有一段供應商關係，所有使用者都要共用。 使用我們自己的應用程式時，連接會直接建立於客戶的 Business Portfolio 與 Meta 之間。號碼仍然屬於客戶，不會由轉售商持有，而新增下一個號碼的操作也與第一個相同。對代理商而言，這不是技術細節，而是客戶問及誰控制其號碼時的答案。 ### 取得此身份有甚麼要求？ 已驗證的 Business Manager、通過 App Review 的應用程式，以及記錄各項流程的示範影片。 商業驗證會將應用程式連繫至真實的法人實體，Meta 會把文件與登記冊資料核對。App Review 會審查應用程式要求甚麼權限及原因；就 WhatsApp 而言，還包括展示整個連接流程實際運作的錄影。這些程序全部不收費，但都需要時間，而時間不能壓縮。 如果您考慮自行建立服務，這點值得了解。連接一個屬於自己的號碼，完全不需要上述程序。為客戶連接號碼，則全部都需要，而且等待時間以星期計算，而不是以工作天計算。 ### 這對連接號碼的商戶有甚麼改變？ 有 3 件事，而且在介面中都看不見。 號碼會連接至商戶自己的 Business Portfolio，因此與 Meta 的關係屬於商戶。Meta 會直接向商戶的 WhatsApp Business 帳戶收取對話費用，這也是中間沒有人可以加價的原因。此外，單一帳戶可以持有的號碼數量沒有上限，因為不需要分攤共用的供應商關係。 連接流程本身則沒有改變。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-hant/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-hant/whatsapp-coexistence-glossary WhatsApp Coexistence 相關詞彙容易混淆，實際上很多混亂源於兩人用同一個詞指不同事物。以下是本網站採用的定義，並連結至詳細說明各詞彙的頁面。 ### 為甚麼詞彙會造成這麼多問題？ 因為當中有幾個詞彙所指的是不同層級的事物，但看起來都像處於同一層級。 Business Portfolio 內含 WhatsApp Business Account，而 WhatsApp Business Account 內含多個電話號碼，每個號碼都有 phone number id。在日常對話中，這四者都會被稱為帳戶，因此「檢查帳戶是否正常運作」一句話，可能代表四種不同的檢查。本平台的兩個二十四小時時段也有同樣問題，它們衡量互不相關的事物，卻經常被混為一談。 另一半原因是，Meta 和服務供應商對同一事物使用不同詞彙，而各服務供應商之間也沒有統一說法。本頁在有 Meta 原有詞彙時會採用該詞彙，並在詞彙由我們定義時直接說明。 ### 哪些區分在實際使用中最重要？ 有三項，而且每一項都曾令某人浪費一天時間。 客戶服務時段和同步時段都是二十四小時，但兩者完全無關。前者決定自由格式訊息能否送達，時間由客戶上次發送訊息起計。後者決定仍能否提取聊天記錄，時間則由啟用流程起計。 已連接裝置不是 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-hant/docs/webhook-fields WhatsApp Business 帳戶會以具名欄位傳送事件。其中 2 個承載對話內容，並路由至您的端點；另外 6 個承載運作狀態，是監察的基礎。了解兩者分別，才能決定架構。 ### 每個欄位承載甚麼？ messages 會承載客戶傳送至該號碼的所有內容：文字、媒體參照、回覆及反應。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 則承載顯示名稱的批准及拒絕。 ### 為甚麼分流對架構很重要？ 因為這決定對話內容是否會到達供應商。 覆寫設定會將 2 個訊息欄位直接從 Meta 傳送至您的端點。6 個運作欄位則繼續傳送至供應商，讓控制台及警報功能可以運作，而無需任何人持有訊息。 因此，不儲存訊息的說法可以是結構上的保證，而不只是政策。如果訊息欄位傳送到其他地方，程式碼便沒有可以儲存它們的路徑。就我們的情況而言，沒有設定覆寫的帳戶會退回預設端點，處理程式會捨棄這些事件而不予保存。 ### 您的處理程式應預期哪些欄位？ 如果已設定覆寫，則只會有 2 個訊息欄位。建議讓處理程式忽略其他欄位，而不是因遇到它們便失敗。 Meta 會逐步加入欄位，負載結構也可能在沒有通知的情況下增加鍵。按欄位名稱分流並忽略不認識欄位的處理程式可以持續運作；假設固定結構的處理程式，則會在第一個不熟悉的事件上出錯。 亦應明確處理 smb_message_echoes，而不是把它視為雜訊。沒有這個欄位，軟件便不知道人員已經回覆，客戶因而可能就同一問題收到 2 個回覆。 - 假設使用一般負載。每個事件都會標明其欄位，處理程式應按欄位分流。 - 忽略 smb_message_echoes。沒有它，軟件會在已回覆的人員之上再次回覆。 - 遇到不認識的欄位便失敗，而不是略過它們。Meta 會在沒有詢問的情況下加入欄位。 **我可以只接收部分欄位嗎？** 覆寫設定會將訊息路徑移交給您。運作欄位的分流是固定的，因為監察便是以此建立。 **一般 Cloud API 號碼上會有 smb_message_echoes 嗎？** 不會。它存在是因為 Coexistence 號碼同時有人員從應用程式傳送內容，以及軟件從 API 傳送內容。 **如果我沒有設定目的地，訊息事件會怎樣？** 它們會到達我們的預設端點，然後在未保存的情況下被捨棄。 **欄位名稱是 Meta 的，還是您自訂的？** 是 Meta 的。這些名稱沒有一個是我們自創的，因此值得一次學會。 --- ## 驗證 WhatsApp Webhook 端點 https://easycoexistence.com/zh-hant/docs/webhook-verification 在傳送任何事件前，Meta 會以帶有 hub.mode、hub.verify_token 和 hub.challenge 的 GET 呼叫您的端點。您的端點必須比較驗證權杖，並以原始內容回傳 challenge。任何其他回應都會令傳送無法開始。 ### Meta 實際會傳送甚麼？ Meta 會向您的 URL 發出 GET 請求，並附帶 3 個查詢參數。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-hant/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-hant/docs/connecting-a-number 連接流程會使用 Meta 自己的 Embedded Signup：選擇 Business Portfolio、WhatsApp Business Account 及號碼，然後在 WhatsApp Business 應用程式中掃描代碼。整個過程約需 2 分鐘，應用程式期間會一直正常運作。 ### 流程中會發生甚麼事？ Meta 的彈出視窗會依次詢問 3 項資料。 首先是 Business Portfolio，即 Business Manager 中的公司級容器。接着是其中的 WhatsApp Business Account。最後是電話號碼，該號碼必須已在 WhatsApp Business 應用程式中註冊，因為 Coexistence 連接的是應用程式正在使用的號碼，而不是建立新號碼。 之後流程會轉到手機。Meta 會顯示代碼，有人需要在持有該號碼的裝置上開啟 WhatsApp Business 應用程式並掃描代碼。這是唯一離開瀏覽器的步驟，也是沒有其他人可以代替企業完成的步驟。 ### 開始設定時會決定甚麼，而且不能更改？ 是否分享現有對話記錄。系統只會詢問一次，而這項決定對該連接是最終決定。 選擇是，會將近期對話記錄同步至 API，讓軟件一開始便有對話背景，而不是毫無上下文。選擇否，API 只會看到連接後的新訊息。兩個選擇都合理，而大部分整合只關注新對話，但如要重新考慮這項決定，必須先中斷連接再重新連接。 這項功能也有時限。同步必須在開始設定後 24 小時內啟動，而且只能執行一次。錯過任何一項，系統會產生不熟悉的錯誤，而不是顯示警告。因此，最好在當天決定是否分享記錄，不要留到整合期間才處理。 ### 開始前應準備甚麼？ 需要準備 3 項資料，事先準備好可以避免流程中途被放棄。 第一是擁有該號碼的 Business Portfolio 存取權限，通常由企業擁有人持有，而不是負責整合的人員。第二是持有該號碼的手機，手機需要解鎖並已安裝 WhatsApp Business 應用程式。第三是最好先準備好 Webhook 目的地，因為在設定結束時完成設定，比之後再記起來更整潔。 如果流程完成前被關閉，號碼可能已附加至帳戶，但尚未完成註冊，導致第一次發送時出現錯誤。從頭再次執行流程即可修正。 - 沒有把手機放在附近便開始。掃描不能稍後在另一部裝置上完成。 - 號碼出現後便關閉彈出視窗。流程之後仍有步驟，停止會令號碼未完成註冊。 - 把對話記錄的決定留到整合完成後才處理。該選項會在開始設定後 24 小時過期。 **我可以連接不屬於自己的號碼嗎？** 只有擁有該號碼的企業可以授權。您向對方發送連結，由對方在自己的手機上完成流程。 **設定期間應用程式會停止運作嗎？** 不會。整個過程中都會繼續運作，包括掃描代碼期間。 **如果號碼位於 WhatsApp 個人版應用程式，應怎樣處理？** 必須先將號碼轉移至 WhatsApp Business 應用程式。Coexistence 連接的是 Business 應用程式號碼。 **我可以重新執行流程嗎？** 可以。中斷連接後再次連接便會重新執行流程，包括重新選擇是否接受對話記錄。 --- ## 24 小時客戶服務時段 https://easycoexistence.com/zh-hant/docs/customer-service-window 客戶向您的號碼傳送訊息後，客戶服務時段便會開啟，並持續 24 小時。時段內可傳送自由格式訊息，回覆同樣免費。時段外只有 Meta 已核准的訊息範本才能送達。 ### 計時究竟何時開始？ 客戶傳送訊息時開始，而每次客戶再次傳送訊息時都會重設。 這是人們最容易弄反的細節。時段不是由您上次傳送訊息、對話開始，或工單開啟的時間起計，而是由客戶最近一次傳入訊息起計。換言之，活躍對話實際上永遠不會關閉，而單向對話則會在一天後關閉。 這也表示時段是按聯絡人計算，而不是按號碼計算。同一個號碼在同一時間，可以有一位客戶處於時段內，另一位則處於時段外。 ### 時段內外可以傳送甚麼？ 時段內任何內容都可以，包括自由格式訊息、媒體，以及您想使用的訊息範本。時段外只有 Meta 已核准的訊息範本可以傳送。 這就是訊息範本存在的原因。對於尚未傳送訊息的人，訊息範本是開始或重新開始對話的獲批准方式。由於收件人沒有主動邀請這則訊息，因此訊息範本會預先接受審核。 在 Coexistence 號碼上，還有一項額外影響。WhatsApp Business 應用程式不能傳送訊息範本，因此時段外的所有訊息都必須經由 API 傳送。團隊可以用手機自由回覆進行中的對話，但不能重新開始一段沒有活動的對話，這是號碼需要連接的實際原因之一。 ### 為甚麼整合系統往往要到正式環境才發現這點？ 因為測試總是在時段內進行。 建立整合系統的人會向自己傳送訊息，然後在幾秒後回覆。這仍在 24 小時內，所以自由格式訊息可以正常傳送，所有測試也會通過。第一個真正失敗的案例，通常是昨天曾傳送訊息的客戶，而這往往已經是在正式上線之後。 穩妥的做法是在傳送前先分流：檢查該聯絡人上次傳送訊息距今多久，再選擇自由格式訊息路徑或訊息範本路徑。一開始便加入這項處理，幾乎不會增加成本。事後補加則要找出程式碼中的每個傳送位置。 - 以您上次傳送訊息的時間計算。其實是客戶的訊息開啟時段。 - 把時段視為按號碼計算。其實是按聯絡人計算，因此同一個號碼上的兩段對話可以處於不同狀態。 - 只在訊息後立即測試，因為那必然處於時段內。 **可以延長時段嗎？** 不可以。時段由 Meta 固定，任何供應商都不能延長。 **傳送訊息範本回覆後，時段會重新開啟嗎？** 客戶回覆會重新開啟。單獨傳送訊息範本不會開啟自由格式訊息時段。 **回覆真的免費嗎？** Meta 不會向時段內傳送的訊息收費。Meta 收取費用的是在時段外開啟的對話。 **我讀到的另一個 24 小時時段是甚麼？** 那是同步時段，由開始進行設定起計，管理的是聊天記錄，而不是訊息傳送。兩者並無關係。 --- ## WhatsApp 訊息範本 https://easycoexistence.com/zh-hant/docs/message-templates 範本是預先提交 Meta 審核的訊息。獲批准後可隨時發送，包括發送給從未聯絡過您的人。只有範本可以在 24 小時客戶服務時段以外傳送訊息。 ### 三種類別有甚麼用途？ 它們告訴 Meta 訊息的類型，而類別會同時影響審核和收費。 Utility 涵蓋與客戶行動相關的交易訊息，例如訂單更新、預約確認及送貨通知。Marketing 涵蓋推廣內容，發送時需要在 WhatsApp Business Account 設定付款方式。Authentication 涵蓋一次性代碼，並有更嚴格的格式要求。 選錯類別是常見的拒絕原因。Utility 範本含有推廣字眼便會被拒絕，而且這種情況相當一致，並不值得嘗試。 ### 變數如何運作？ 佔位符會按編號順序填入，並按元件分開計算。 內文 Hello {{1}}, your order {{2}} has shipped 定義了 2 個變數，發送內文時必須準確提供 2 個值。標題及按鈕參數會分開計算，不會合併成一個清單，因此即使總數正確，發送仍可能被拒絕。 建立範本時，Meta 亦要求提供示例值，讓審核人員了解實際訊息的樣子。此外還有位置規則：變數位於訊息最開頭或最末端，或相對於周圍文字而言變數過多，都會被拒絕。 ### 為甚麼手機應用程式不能在 Coexistence 號碼發送範本？ 因為範本是平台功能，而不是應用程式功能，應用程式並沒有範本的概念。 這是及早了解很有用的一點。透過 Coexistence 連接的企業可以讓團隊繼續使用手機回覆，團隊亦能即時回覆任何訊息。但如果對話已經冷卻，就不能從應用程式重新開始，因為這需要範本，而範本只能透過 API 使用。 因此，任何預定發送、交易相關，或發送給今天尚未聯絡您的人，按定義都必須使用 API。對許多企業而言，這正是建立連接要填補的缺口。 - 在同一輪操作中建立範本並發送。Meta 會先進行審核，通常需幾分鐘，但有時需一天。 - 合併計算標題和內文變數。它們會按元件分開計算。 - 在 Utility 範本使用 Marketing 字眼。這是穩定而常見的拒絕原因。 **審核需時多久？** 通常需幾分鐘，有時最長需一天。沒有任何服務供應商可以加快審核。 **每種語言都要建立一個範本嗎？** 是。名稱和語言會共同識別範本，因此同一名稱的另一種語言版本是不同範本。 **我可以編輯已批准的範本嗎？** 可以，但編輯會改變變數契約，令固定使用舊數量的發送程式失效。 **我需要設定付款方式嗎？** Marketing 發送需要，而且必須在您自己的 WhatsApp Business Account 設定。Meta 要求提供付款方式，沒有任何服務供應商可以代您新增。 --- ## account_update Webhook 與所有斷線原因 https://easycoexistence.com/zh-hant/docs/webhook-account-update account_update 是 Meta 用來回報連接狀態變更的方式。其 event 欄位說明發生的事件；如屬移除，disconnection_info.reason 會指出原因。這個原因決定號碼會否恢復，還是已經永久失效。 ### account_update 會攜帶哪些事件？ 應用程式從 WhatsApp Business 帳戶解除安裝時，會傳送 PARTNER_REMOVED。這是權威的斷線訊號，也是值得用來建立處理邏輯的訊號，不應透過欄位變為 false 來推斷斷線。 號碼完全解除接入時，會傳送 ACCOUNT_OFFBOARDED。先前移除的連接恢復時，會傳送 ACCOUNT_RECONNECTED。至於執法事件，則包括 ACCOUNT_RESTRICTION 和 ACCOUNT_VIOLATION，以及名稱包含 DISABLED 或 BAN 的事件。 驗證及核准結果也會在這裡傳送，事件名稱包含 VERIFIED 或 APPROVED。處理程式應根據事件名稱分流，並將任何未識別事件視為資訊，而不是因而失敗，因為 Meta 可能在未有通知下新增事件。 ### 斷線原因有哪些？ 共有 6 個，代表的情況截然不同。 PRIMARY_INACTIVITY 是約 14 天的規則：主要裝置沒有開啟 WhatsApp Business 應用程式。這種情況可以恢復，而且最常見。 COMPANION_INACTIVITY 是伴隨裝置的不活動，原理相同，但時限較長，約為 30 天。 BUSINESS_DOWNGRADE 表示號碼已切換回一般 WhatsApp 應用程式，因此 Coexistence 結束，因為 Coexistence 需要 WhatsApp Business 應用程式。 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 時便推斷斷線，而不是根據這個事件判斷。這會造成錯誤警報。 - 遇到未識別事件名稱便失敗。Meta 會新增事件，處理程式應略過不認識的事件。 **PARTNER_REMOVED 是永久性的嗎？** 通常不是。大部分事件都帶有 PRIMARY_INACTIVITY，表示應用程式沒有被開啟；重新連接後一切便會恢復。 **重新連接會恢復我的 Webhook 目的地嗎？** 不會，這正是容易忽略的地方。目的地是應用程式訂閱上的 override，並會隨應用程式一併解除安裝，因此必須重新套用。 **COMPANION_INACTIVITY 是甚麼？** 這是伴隨裝置而非主要裝置的不活動情況，原理相同，但時限較長，約為 30 天。 **事件可以沒有原因嗎？** 可以。發生這種情況時，disconnection_info.initiated_by 是唯一可用來判斷是否有意操作的訊號。 --- ## phone_number_quality_update Webhook https://easycoexistence.com/zh-hant/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-hant/docs/webhook-smb-message-echoes smb_message_echoes 會傳送團隊從 WhatsApp Business 應用程式發出的內容。它僅存在於 Coexistence 號碼，因為只有這些號碼同時有人員從電話發送訊息，以及軟件從 API 發送訊息。 ### 為甚麼需要這個欄位？ 因為 Coexistence 會造成 API 原本未針對的情況：同一個號碼有兩個發送者。 在一般 Cloud API 號碼上，軟件是唯一的發送者，因此無需回報任何內容。在 Coexistence 號碼上，團隊仍會從電話回覆；如果沒有方法查看這些回覆，軟件便無法掌握每段對話近半的內容。 回聲正好解決這個問題。有人在 WhatsApp Business 應用程式中輸入回覆時，該回覆會以事件形式抵達您的端點，結構與傳入訊息相同，但會標示為由商戶發出的訊息。 ### 如果忽略它，會出現甚麼問題？ 客戶會收到兩次回覆，看起來很不專業。 常見情況是，客戶早上 8 時提出問題，人員在 1 分鐘內從電話接手，而從未看見該回覆的自動化流程在 3 分鐘後回答同一問題。對客戶而言，這代表同一間商戶不知道自己已經說過甚麼。 處理方式並不複雜。像處理傳入訊息一樣，將回聲準確記錄在對話中，並在發送前檢查近期活動。這個問題之所以難以察覺，是因為測試對話中沒有人員回覆，因此不會出現問題。 - 將回聲視為雜訊並捨棄。它們是唯一能表示人員已經回覆的訊號。 - 假設每個號碼都有這個欄位。它只適用於 Coexistence。 - 測試時沒有讓人員參與，而這正是問題不會出現的唯一情況。 **回聲是否包括媒體？** 它們會回報已發送的內容，包括媒體的參照資料，結構與傳入訊息相同。 **一般 Cloud API 號碼是否也有這個功能？** 沒有。沒有 Coexistence，便沒有人員從應用程式發送訊息，因此沒有內容需要回聲。 **可以關閉這項功能嗎？** 它隨訊息路徑提供。將該路徑路由至您的端點便會包括它，而在程式碼中忽略它則是需要承擔後果的選擇。 **這項功能是否收費？** 不會。它是 Webhook 事件，而不是訊息發送。 --- ## messages Webhook https://easycoexistence.com/zh-hant/docs/webhook-messages messages 是承載客戶傳送至您號碼的所有內容的欄位，包括文字、媒體、回覆、反應及互動回應。對於路由的 Coexistence 號碼，訊息會由 Meta 直接送往您的端點，不會經過供應商。 ### 負載包含甚麼 一次傳送可包含一則或多則訊息，每則都有寄件者、id 及類型。類型會決定其他哪些鍵存在。 - 寄件者的電話號碼，以及他們所寫入的號碼的電話號碼 id。 - wamid 訊息 id，去重功能以此為基礎。 - unix 時間戳記。 - 類型：text、image、audio、video、document、sticker、location、contacts、reaction、button 或 interactive。 - 對於媒體類型，會提供用來取得媒體的媒體 id，而非媒體本身的位元組。 ### 為何路由號碼上的訊息不會到達我們 因為 override 會將此欄位連同 smb_message_echoes，移至您指定的任何目的地。 Meta 讓應用程式可以覆寫 WhatsApp Business Account 傳送 Webhook 的位置。我們會將此覆寫設定為您的 URL，令訊息路徑完全離開我們的基礎設施。我們這邊不會有副本、佇列或保留資料，因為訊息根本不會送達。 未設定目的地時，這些事件會回退至我們的預設回呼，處理程序會丟棄事件而不保存。這就是儲存聲明與程式碼路徑的差異：對話內容沒有地方可以流向。 ### 正確確認訊息 在開始工作前傳回 200，而不是完成後才傳回。 Meta 會將緩慢回應視為失敗並重試，因此內聯處理的處理程序可能會多次看見同一則訊息。請立即回應，將負載放入佇列或背景工作，讓工作在請求之外進行。 在無伺服器環境中，這並非可選項。函式傳回後仍繼續工作，可能在回應的瞬間被凍結，因此確認與處理必須真正分開。 ### 去重 始終根據 wamid 去重，因為重試是正常情況，而非例外。 同一則訊息可能因與您一方錯誤無關的原因到達兩次，例如回應緩慢、網絡逾時，或部署在傳送途中生效。儲存已見過的 id 並略過重複項只需數行程式碼，卻決定客戶會獲回覆一次還是兩次。 對於 Coexistence 號碼，這點更加重要，因為 smb_message_echoes 會經由相同路徑到達。若處理程序將每個事件都視為新事件，就會在團隊成員已回覆的訊息上再次回覆。 - 在傳回 200 前先處理。Meta 會重試緩慢回應，令您處理同一則訊息兩次。 - 略過去重。重試是設計的一部分，不是罕見情況。 - 預期負載會包含媒體位元組。負載只會提供用來取得媒體的媒體 id。 **EasyCoexistence 會看到我客戶的訊息嗎？** 不會。覆寫會將此欄位送往您的端點。任何到達我們回退回呼的內容都會被丟棄，不會保存。 **一次請求可以收到多則訊息嗎？** 可以。一次傳送可包含多則訊息，因此處理程序應逐一處理，而不是只讀取第一則。 **如何取得媒體？** 負載會提供媒體 id。使用該號碼的存取權杖取得 URL，然後下載。 **smb_message_echoes 是甚麼？** 這是承載團隊透過 WhatsApp Business 應用程式傳送內容的配套欄位。它只會存在於 Coexistence 號碼。 --- ## phone_number_name_update Webhook https://easycoexistence.com/zh-hant/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-hant/docs/webhook-message-template-status-update message_template_status_update 回報範本審核狀態的變更：獲批、拒絕、暫停或停用。整合功能提交範本後，Meta 會回報結果，毋須按時輪詢並猜測查詢頻率。 ### 它會傳送哪些狀態 範本會經過一小組狀態，每次變更都會在此送達。 - 獲批：範本由現在起可以發送。 - 拒絕：範本不能發送，事件會附帶原因。 - 暫停：質素下降至一定程度，Meta 暫時將其暫停。 - 停用：多次暫停後永久停止，必須使用新範本。 ### 為何毋須輪詢 因為替代做法是重複查詢並猜測查詢頻率。 沒有此事件時，建立範本的整合功能必須按某個時間間隔輪詢 get_template_status，直至結果改變。查詢太頻密會浪費資源，太疏落則範本獲批後可能一小時仍無人察覺。 有了此事件，流程就是提交後等候。Meta 通常會在數分鐘內推送結果，整合功能只需作出一次回應。對於代客戶建立範本的代理商而言，這是能自行清空的佇列與必須有人監察的佇列之間的差別。 ### 每種結果應如何處理 獲批最簡單：標記為可供發送。其餘三種狀態才是重點。 拒絕會附帶原因，值得原文顯示而非概括轉述，因為原因通常具體得足以採取行動，而改寫後會失去這點。 暫停表示內容引起不良反應，暫停解除後再次發送仍會得到相同結果。這是提示您修改內容，而不是等待。 停用對該範本而言是永久狀態。唯一的前進方法是建立內容不同的新範本；把它當成暫時狀態，會令發送途徑無限期失效。 - 這個事件已回報結果，卻仍輪詢查詢獲批狀態。 - 概括轉述拒絕原因，而不是直接顯示。具體內容才足以採取行動。 - 等待已停用的範本恢復。此狀態是永久的，必須建立新範本。 **通常需要多久才會獲批？** 通常只需數分鐘，有時最長一天。任何供應商都無法加快此流程。 **暫停的範本是否等同於已停用的範本？** 不是。暫停會在一段時間後解除，停用則是永久狀態，並且是在多次暫停後發生。 **拒絕時會說明原因嗎？** 會，而且原因具體得足以採取行動，所以值得不作修改直接傳遞。 **其中一個範本暫停時，我仍可發送其他範本嗎？** 可以。此狀態只適用於該範本，不適用於該號碼。 --- ## message_template_quality_update Webhook https://easycoexistence.com/zh-hant/docs/webhook-message-template-quality-update message_template_quality_update 會回報收件者對某個範本的反應變化。它會在品質導致範本暫停前送達，讓您有時間處理，而不是等發送失敗後才解釋原因。 ### 它正在量度甚麼 收件者如何回應使用某個範本發送的訊息，而不是整個號碼的整體表現。封鎖和檢舉所佔比重最高，完全沒有互動也會產生影響。 這種按範本劃分的範圍正是它有用之處。某個號碼整體表現良好，但一個範本可能正在悄悄破壞自己的受眾，而這個事件能將兩者分開。沒有它，您收到的第一個訊號會是該範本發送失敗，但號碼上的其他功能仍然正常。 ### 為甚麼及早處理才是重點 因為之後的每個狀態都更糟，也更難恢復。 品質下降至一定程度會暫停範本，之後每次嘗試都會回傳錯誤 132015，並只會在一段 Meta 沒有公布的時間後解除。多次暫停會永久停用範本，屆時必須以新名稱重新建立內容，作為新的範本。 範本仍可發送時收到品質訊號，是唯一可以免費編輯的時機。範本一旦被暫停，編輯仍然是正確做法，但發送路徑已經中斷，除非有人及時察覺，否則會持續一段時間。 ### 通常是甚麼原因造成 先是內容，其次是受眾，而第二點最容易被忽略。 - 在宣稱為實用類別的範本中使用推廣語句，收件者並未預期會收到這類內容。 - 訊息沒有清楚說明是哪間企業發送。 - 向整個名單發送，而不是發送給近期曾互動的人。 - 大量向從未要求接收的受眾發送同一個範本。 - 把它當作資訊通知。這是範本仍然正常運作時收到的最後一個訊號。 - 把它理解為號碼有問題。它只針對一個範本。 - 只修改文字，卻保留相同受眾。發送對象和訊息內容一樣，都會產生相同訊號。 **這會影響我的其他範本嗎？** 不會。這個訊號只針對一個範本，同一號碼上的其他範本不受影響。 **我可以在應用程式中看到這項資料嗎？** 不可以。手機上的 WhatsApp Business 應用程式不會顯示任何範本品質資料。 **如果我忽略它，會發生甚麼事？** 品質持續下滑會暫停範本，而多次暫停會永久停用它。 **只修改文字就足夠嗎？** 通常足夠，但不一定。範本的發送對象和訊息內容一樣，都會產生相同訊號。 --- ## history Webhook 的運作原理 https://easycoexistence.com/zh-hant/docs/webhook-history history 會將 Coexistence 號碼現有對話一次性傳送至 API。當您在啟用流程中接受分享歷史記錄後，它會於完成註冊後送達，是整合唯一得知傳送已完成的訊號。 ### 傳送哪些內容 它會傳送號碼在 WhatsApp Business 應用程式中已有的一對一訊息記錄，讓軟件在企業使用多年後的號碼上運作時，不會毫無背景。 群組對話不會隨之傳送，因為 Coexistence 號碼完全不能在 API 使用群組對話；應用程式本身的工具也不會傳送，包括標籤、快速回覆、問候訊息及離開訊息。這些功能沒有 API 對應項目，會保留在裝置上。 此欄位只存在於 Coexistence 號碼。以一般方式完成註冊的號碼沒有可供傳送的應用程式歷史記錄，因此沒有內容可傳送。 ### 為何只會觸發一次 因為傳送是啟用流程的一部分，而不是持續提供的功能。 企業擁有人會在 Embedded Signup 期間被詢問是否分享現有對話。回答「是」才會允許同步執行；之後沒有任何設定可以重新開啟，也沒有端點可以再次執行。第二次嘗試會傳回 2593107，而不是等待後便會清除的限流錯誤。 此外還有期限。同步必須在完成註冊後 24 小時內開始，較後嘗試會傳回 2593108。錯過任何一項，都必須中斷號碼連接，重新執行整個流程。 ### 處理程式應如何處理 將它視為只會送達一次、可能容量很大的批次，而不是訊息路徑上的額外流量。 - 快速確認接收並以非同步方式處理，與其他傳送相同。 - 按訊息 ID 去重：history 與即時訊息可能在完成註冊前後重疊。 - 預期它可能不存在。擁有人拒絕分享歷史記錄的號碼不會在此傳送任何內容，整合必須在兩種情況下都能運作。 - 不要以它完成為啟用流程的條件。傳送完成前，連接已可使用。 - 建立必須有歷史記錄才能運作的整合。許多號碼連接時並沒有歷史記錄。 - 在 2593107 後重試同步。這是一次性事件，因此重試會傳回相同錯誤。 - 等到整合工作開始後才決定是否分享歷史記錄，而那通常已經超過 24 小時期限。 **會傳送多少歷史記錄？** 近期一對一對話的時段，由 Meta 設定，而不是由供應商設定。 **群組聊天會傳送過來嗎？** 不會。Coexistence 號碼完全不能在 API 使用群組對話。 **稍後可以再次要求嗎？** 不可以。每次啟用流程只會執行一次，再次執行必須中斷並重新連接號碼。 **如果擁有人拒絕分享歷史記錄，會怎樣？** 此欄位不會傳送任何內容，API 只會看到號碼連接後收到的訊息。 --- ## smb_app_state_sync Webhook https://easycoexistence.com/zh-hant/docs/webhook-smb-app-state-sync smb_app_state_sync 傳送 WhatsApp Business 應用程式本身的狀態，主要是 Coexistence 號碼連接時進行的聯絡人同步。它與傳送對話的 history 分開，而且只存在於 Coexistence 號碼。 ### 所承載的內容 應用程式端的狀態，實際上是企業原本儲存在手機上的聯絡人。 每個擁有 WhatsApp 號碼的聯絡人都可以同步至平台，讓軟件識別多年前已儲存在企業手機內的客戶，而不是將其視為新號碼。這與對話本身不同，對話會在 history 欄位送達。兩者分開，是因為一個是目錄，另一個是對話記錄。 與 history 一樣，這只存在於 Coexistence。從未使用過應用程式的號碼沒有應用程式狀態可供同步。 ### 不承載的內容 應用程式本身的操作工具，這些內容在平台端沒有對應資料。 - 標籤只儲存在裝置上，軟件無法讀取。 - 快速回覆、歡迎訊息及離開訊息。 - 目錄、訂單及狀態。 - Channels，以及語音或視像通話記錄。 ### 為何這對整合很重要 因為它決定您的系統能否從第一天起知道誰正在發送訊息。 沒有聯絡人同步時，每則傳入訊息只會顯示沒有名稱的號碼，您需要自行將它與客戶記錄配對。有了同步，企業自己的聯絡人清單便可供使用，大部分配對工作已經完成。 值得同時為兩種情況作規劃，因為企業可以拒絕同步或錯過期限。假如整合假設聯絡人一定存在，使用者開啟系統時可能只會看到大量原始號碼。 - 假設聯絡人一定存在。企業可以拒絕同步或錯過期限。 - 預期此負載會包含標籤或快速回覆。它們會留在裝置上。 - 將它與 history 混淆。history 傳送的是對話，而不是聯絡人清單。 **這是否與 history 同步相同？** 不是。這會傳送應用程式狀態，主要是聯絡人。history 傳送對話。 **它會執行多於一次嗎？** 初次同步是啟用流程的一次性部分，與 history 一樣有 24 小時期限。 **我會取得標籤嗎？** 不會。標籤是應用程式功能，沒有相應的 API。 **一般 Cloud API 號碼也有這項功能嗎？** 沒有。一般 Cloud API 號碼沒有 WhatsApp Business 應用程式狀態可供同步。 --- ## template_category_update Webhook https://easycoexistence.com/zh-hant/docs/webhook-template-category-update template_category_update 表示 Meta 已重新分類範本，將其在 utility、marketing 和 authentication 之間調整。這很重要，因為分類會決定 Meta 就對話收取的費用，因此重新分類會在無人修改任何內容的情況下改變您的成本。 ### 為何分類會自行變更 因為 Meta 會審查範本實際寫了甚麼，而不只是查看範本原先申報的分類。 以 utility 提交但包含優惠的範本，是用較低廉的標籤包裝的推廣內容。有時這會在審查時被發現並拒絕。有時範本會先獲核准，待內容在實際使用中被看見後才重新分類，而這個第二種情況就是此事件所報告的內容。 這不是由您這邊觸發的。範本沒有變更，程式碼沒有變更，而在沒有此事件的情況下，最先出現的跡象可能是一張與預測不符的帳單。 ### 它會改變甚麼 從那時起，該範本開啟的每個對話所需支付的價格。 - Meta 對 utility、marketing 和 authentication 對話採用不同價格。 - Marketing 發送另外需要 WhatsApp Business 帳戶設有付款方式。 - 如果帳戶沒有付款方式，範本重新分類為 marketing 後會開始返回 131042。 - 範本本身仍然運作，改變的是費用及所需條件。 ### 如何避免被重新分類 如實申報，這比刻意優化更省錢。 utility 範本描述客戶已經作出的事情，例如訂單、預約或配送。如果沒有客戶採取的某項行動，訊息便不會存在，那就是 utility。如果訊息存在是因為您想銷售某項產品或服務，那就是 marketing。直接申報為 marketing，成本低於在您未選擇的時刻被重新分類。 持續提交分類錯誤的範本，也會令帳戶本身受到關注。相較之下，為 marketing 訊息支付 marketing 費率是較好的結果。 - 為了少付費而將推廣內容申報為 utility。重新分類會在稍後抵達，而且時機更差。 - 忽略此事件。它會在您沒有改變任何可控制內容的情況下改變計費。 - 假設核准就是最終結果。範本獲核准後仍可被移至另一分類。 **範本會停止運作嗎？** 不會。範本仍會繼續發送，改變的是對話價格，以及 marketing 所需的付款方式。 **我可以對重新分類提出申訴嗎？** Meta 會透過自己的渠道處理分類爭議，任何供應商都無法更改分類。 **哪個分類最便宜？** Meta 會按市場採用不同價格。最便宜的正確分類，就是如實描述訊息內容的分類。 **甚麼是 131063？** 帳戶已停用 marketing 範本，這與沒有付款方式是兩種不同情況。 --- ## Meta Business Portfolio，以及其中包含的內容 https://easycoexistence.com/zh-hant/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-hant/docs/whatsapp-business-account WhatsApp Business 帳戶儲存電話號碼和訊息範本。它的重要性超乎表面，因為 Webhook 路由設定於此層級，而不是每個號碼各自設定，所以移除連接時，路由也會一併移除。 ### WABA 實際儲存甚麼？ 電話號碼和訊息範本，這個組合的重要性比初看更高。 訊息範本屬於帳戶，而不是某個號碼，因此同一 WABA 上的所有號碼都共用相同的範本庫。建立一個訂單更新範本後，所有號碼都可以發送。Meta 對每個帳戶的訊息範本數量設有上限，對於在同一帳戶管理多個品牌的代理商來說，可能會遇到這項限制。 每個號碼都有自己的電話號碼 ID、顯示名稱、品質評分和訊息層級。這些資料按號碼區分，因此其中一個號碼可能品質下降，而同一帳戶上的另一個仍然正常。 ### 為何 Webhook 覆寫設定於此層級？ 因為它修改的是應用程式對帳戶的訂閱，而不是對某個號碼的訂閱。 設定目的地後，實際上是將 `override_callback_uri` 套用至我們的應用程式對該 WABA 的訂閱。帳戶上的每個號碼，之後都會把訊息路徑事件傳送到該處。沒有按號碼設定的路由，因此管理同一客戶多個號碼的人可能會感到意外。 最值得預先規劃的是這項後果。當連接因 14 天沒有活動規則或其他原因而移除時，應用程式會從帳戶解除安裝，覆寫也會一併解除安裝。重新連接後，發送和監察功能會恢復。至於傳送到您自己的伺服器，除非有程序重新套用覆寫，否則不會恢復。 - 以為每個號碼都有獨立的 Webhook 路由。覆寫是按帳戶設定。 - 以為重新連接會恢復目的地。覆寫會隨應用程式一併解除安裝，必須重新套用。 - 忘記訊息範本是共用的。帳戶上的每個號碼都會看到相同的範本庫。 **同一 WABA 上的兩個號碼可以路由至不同端點嗎？** 不可以。覆寫按帳戶設定，因此所有號碼都會傳送至同一目的地。 **訊息範本可以在帳戶之間轉移嗎？** 不可以。訊息範本屬於建立它的帳戶。 **移除一個號碼時，覆寫會怎樣？** 如果應用程式從帳戶解除安裝，覆寫也會一併移除。重新連接會恢復發送功能，但不會恢復目的地。 **訊息範本有數量限制嗎？** Meta 對每個帳戶的訊息範本數量設有上限，超出後會回傳專用錯誤。 --- ## WhatsApp 號碼的兩步驗證 https://easycoexistence.com/zh-hant/docs/two-step-verification 兩步驗證是在 WhatsApp Business 號碼上設定的 PIN。某些操作需要輸入此 PIN。由於通常只在開通流程中設定一次，之後不會再使用，最常見的問題是企業內無人記得它。 ### 何時才真正需要 PIN？ 在號碼註冊及重新註冊期間，以及某些由 Meta 保護的帳戶操作中需要使用。 這表示大部分企業會在開通流程中設定 PIN，之後再也不會看見它，正因如此，它才會變成問題。設定 PIN 的人離職或轉換工作，PIN 從未記錄在任何地方，結果 18 個月後，當某件事情已經出現故障時，偏偏就在那一刻需要它。 相關錯誤足夠明確，可以用來診斷問題。PIN 不正確會回傳 133005。嘗試次數過多會回傳 133008，並按照回應所述的時間鎖定後續嘗試。提交嘗試的速度過快會回傳 133009，這是速率限制，而不是答案錯誤。 ### PIN 遺失後應怎樣處理？ 在 WhatsApp Manager 的號碼設定中重設，但您必須能存取擁有該號碼的帳戶。 這是企業擁有人要進行的操作，而非服務供應商的操作。沒有任何 API 可以讀取或重設 PIN，也沒有服務供應商會保留 PIN。這是刻意的設計：如果服務供應商可以取回某項憑證，它就不會是第二重因素。 實際做法是把 PIN 記錄在企業本身可以取回的地方，而不是代理商一方。若 PIN 只儲存在代理商的密碼管理工具中，下一段客戶關係便會再次出現完全相同的問題。 - 輸入錯誤 PIN 後迅速重試。這會回傳 133009，並延遲下一次有效嘗試。 - 只在代理商一方儲存 PIN。企業必須能自行取回 PIN。 - 假設服務供應商可以取回 PIN。沒有人會保留它，這正是它存在的意義。 **您可以重設我的 PIN 嗎？** 不可以。PIN 設定在 Meta 自己的號碼設定中，任何服務供應商都不能讀取或修改。 **鎖定會持續多久？** Meta 會在 133008 的錯誤回應中說明等待時間，而不是使用固定時長。 **PIN 是每個號碼一個，還是每個帳戶一個？** 每個電話號碼一個。 **這是否等同於商業驗證？** 不是。驗證針對 Business Portfolio 層級的法律實體，這是設定在號碼上的 PIN。 --- ## account_review_update Webhook https://easycoexistence.com/zh-hant/docs/webhook-account-review-update account_review_update 傳送 Meta 審查業務帳戶的結果。其 decision 欄位說明決定內容，而拒絕應視為連接狀態降級，而非單純資訊，因為訊息發送通常會隨之惡化。 ### 審查何時進行？ Meta 檢查業務帳戶時便會進行審查，觸發原因可能是提交驗證資料、提出申訴，或訊息行為引發自動標記。 供應商無法觸發審查，也無法查看審查過程。能收到的只有結果，即帶有 decision 的事件。獲批通常不會引起注意；值得採取行動的是拒絕，因為拒絕往往先於限制，而不是代表事情已經完結。 WhatsApp Business 應用程式不會顯示任何審查資訊，因此業務可以在審查中、被拒絕後，仍從手機回覆客戶，完全不知道曾發生任何事情。 ### 為何應將拒絕視為狀態降級，而不是單純消息？ 因為拒絕通常是多個事件中的第一個，而不是最後一個。 審查被拒表示 Meta 檢查過帳戶，但對結果不滿意。之後往往會出現限制，完全停止訊息發送，並以帶有執行事件的 account_update 抵達。在拒絕時標記連接狀態降級，讓負責監察的人員可以提早開始與客戶溝通。 如果只將拒絕記錄為資訊，通常要等到訊息開始發送失敗才會有人採取行動。屆時業務已無法接觸客戶，討論也會從危機開始，而不是從警告開始。 - 記錄拒絕卻不更新狀態。這是領先指標，不是附帶備註。 - 期待此事件提供原因。它只傳送決定；詳細資料位於 Business Manager。 - 假設業務會察覺。手機上不會顯示任何審查資訊。 **供應商可以查看審查失敗的原因嗎？** 不可以。執行通知及其原因位於業務帳戶的 Business Manager。 **拒絕是否一定會導致限制？** 不一定，但出現限制的情況相當常見，因此預設將其視為警告是正確做法。 **誰可以提出申訴？** 擁有業務帳戶管理員存取權的人員。供應商不能代替他們提出申訴。 **這是否與訊息範本審查相同？** 不相同。訊息範本審查結果會分開抵達，涉及單一範本，而不是整個帳戶。 --- ## business_capability_update Webhook https://easycoexistence.com/zh-hant/docs/webhook-business-capability-update business_capability_update 會報告帳戶可執行操作的變更，最實用的是訊息上限。它帶有目前上限，即您每日可主動開始對話的不同客戶數量。上限可上調或下調。 ### 訊息上限實際限制的是甚麼？ 您在滾動 1 日內可以主動開始對話的不同客戶數量。這不是您可以傳送的訊息數量，也不是傳送速度。 這項分別最容易造成問題。吞吐量是按每秒計算的速率，超出後會返回 130429。訊息層級是新對話的每日數量，超出後屬於不同情況。數字可能完全未超出層級，卻仍受到速率限制，亦可能相反。 在開放的客戶服務時段內回覆，不會消耗層級，因為回覆不是開始對話。真正會消耗層級的，是聯絡尚未發送訊息給您的客戶。 ### 為甚麼層級會下調？ 因為層級取決於質素，而質素取決於收件人的反應。 如果某個號碼的收件人封鎖或舉報訊息，該號碼的評級會下降，層級也可能隨之調整。因此，下調是很有用的早期訊號：通常在任何功能停止運作前便會出現，讓您仍有時間改變訊息內容及收件對象。 上調較慢，需要持續獲得良好反應。兩個方向都不會在企業可查看的地方公布，所以記錄此事件，而不是只在故障後作出反應，值得付出少量工作。 - 將層級與吞吐量混淆。前者是每日對話數量，後者是每秒訊息數量。 - 將回覆計入層級。在開放時段內傳送的訊息不會開始對話。 - 忽略下調。它會在任何功能出現問題前到達，這正是它的價值。 **如何提升層級？** 層級會隨時間及質素變化，而不是根據申請提升。向希望接收訊息的人妥善發送訊息，就是提升機制。 **範本訊息每次傳送都會消耗層級嗎？** 會開始對話的範本訊息會消耗層級。在開放時段內傳送的範本訊息則不會。 **messaging_limit_update 是否不同？** Meta 會以兩個名稱傳送相關變更。我們的處理常式會以相同方式處理，因為有用內容相同。 **這適用於 Coexistence 號碼嗎？** 適用。Coexistence 固定的是吞吐量，而不是訊息層級。 --- ## account_alerts Webhook https://easycoexistence.com/zh-hant/docs/webhook-account-alerts account_alerts 是 Meta 用來就商業帳戶提出事項的一般渠道。它不像其他事件般帶有需要套用的狀態，因此提示您查看，而不是自動處理。 ### 這個渠道會收到甚麼？ 凡是 Meta 認為值得就帳戶提出警示的事項，都可能出現在這裏。內容刻意保持開放，並會隨時間增加。 由於內容不是固定集合，按特定警報類型分支的處理程式會遺漏新類型。持久可靠的做法，是記錄警報、將它附加至帳戶，並交由人員查看，而不是為每種警報對應自動回應。 這是唯一一個誠實處理方式是留意而非作出判斷的操作事件。我們的處理程式會記錄警報已抵達，但不會嘗試從中推斷狀態。 ### 它應如何納入監察？ 把它作為時間線上的標記，放在那些確實帶有狀態的事件旁邊。 它的價值在於事件次序。在遭拒的審查及其後的限制之前不久收到警報，所說出的故事並不是任何單一事件可以完整呈現的。把它們記錄在同一條時間線上，才能看見這點，也能讓您與客戶的對話由猜測變成日期和事件。 它不應觸發任何操作。警報不是斷開連接，不是品質下降，也不是限制。把它當作其中任何一種，都會造成錯誤警報，最終令人忽略真正的警報。 - 按特定警報類型分支。內容集合會擴展，圍繞現有清單建立的處理程式很快會過時。 - 由警報觸發自動化。它不帶有狀態，因此任何推斷都只是猜測。 - 因為它不能直接採取行動便忽略它。它的價值在於與其他事件形成的次序。 **為甚麼它不會改變我的連接狀態？** 因為它沒有說明發生了甚麼變化。從中推斷狀態會造成錯誤警報。 **在哪裏可以查看詳細資料？** 在商業帳戶的 Business Manager 中。這個事件是提示您到那裏查看。 **它很少出現嗎？** 它不是日常事件，因此出現時更值得顯示出來。 **這是否代表出了問題？** 不一定。這表示 Meta 提出了一項事項，值得人員查看，而不是自動回應。 --- ## WhatsApp 商業號碼的顯示名稱 https://easycoexistence.com/zh-hant/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-hant/docs/template-categories 每個範本建立時都必須指定類別。實用類別涵蓋與客戶行動相關的交易訊息，推廣類別涵蓋宣傳內容，並要求帳戶設定付款方式；驗證類別涵蓋一次性密碼，受更嚴格的格式規則限制。 ### 每個類別適用於甚麼內容？ 實用類別屬於交易訊息，並與客戶採取的行動相關，例如訂單確認、送貨更新、預約提醒或預約變更。判斷標準是：客戶是否會因為自己曾採取某項行動而預期收到這則訊息。 推廣類別涵蓋所有宣傳內容，例如優惠、新產品、重新吸引客戶的訊息或電子通訊。發送這類訊息需要在 WhatsApp Business 帳戶設定付款方式，因此，一個過去只曾回覆客戶的帳戶，首次嘗試發送推廣訊息時通常會失敗。 驗證類別涵蓋一次性密碼及驗證訊息。它有最嚴格的格式，對密碼前後可加入的內容設有限制；之所以獨立成為一個類別，是因為這類訊息有不同的傳送預期。 ### 為甚麼不把所有內容都申報為實用類別？ 因為 Meta 會重新分類，而被重新分類比誠實申報更不理想。 實用類別範本中的宣傳內容會持續被發現。範本可能在審核時被拒，或先獲批准，之後才被重新分類；這時，原本按實用類別收費的發送會在沒有任何人作出修改的情況下，改按推廣類別收費。這不是節省，而是帳單上的意外費用。 反覆提交類別不符的範本，也會令帳戶本身受到更多關注。更省錢的做法，是按訊息的實際內容申報類別；這亦會令審核更快，因為審核人員檢查的正是範本所申報的內容。 - 把優惠放進實用類別範本中。這種情況通常會被發現，批准後也可能被重新分類。 - 在帳戶沒有付款方式時嘗試發送推廣訊息。Meta 要求設定付款方式，任何供應商都無法代為新增。 - 把驗證類別用於密碼以外的內容。格式限制很嚴格，訊息將無法通過審核。 **誰支付推廣訊息的費用？** Meta 會向您自己的 WhatsApp Business 帳戶所設定的付款方式收取費用，不會經由我們收取。 **範本可以更改類別嗎？** 如果內容與原先申報的類別不符，Meta 可以在批准後重新分類。 **實用類別免費嗎？** 實用類別對話由 Meta 定價，與客戶服務時段內的回覆不同，後者免費。 **甚麼是錯誤 131063？** 表示帳戶已停用推廣範本，這與帳戶沒有付款方式是兩回事。 --- ## 號碼停止運作：如何找出原因 https://easycoexistence.com/zh-hant/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-hant/docs/free-and-paid-conversations Meta 按已送達的訊息收費，而不是按對話收費。自 2026 年 10 月 1 日起，每個商業電話號碼每月可獲 1,000 則免費服務訊息，即在 24 小時客戶服務時段內發出的回覆，Meta 由第 1,001 則起收費。訊息範本在送達時收費，實用類範本也不例外。這些費用會從您自己的 WhatsApp Business Account 所設的付款方式扣除。 ### 究竟哪些是免費的？ 每個商業電話號碼每月最多 1,000 則服務訊息。服務訊息指任何非範本訊息，只能在客戶服務時段開啟期間發送，即客戶最後一次向您發送訊息後的 24 小時內。每月由第 1,001 則起，Meta 會逐則收費，未用完的額度亦不會結轉。 這對整合設計的影響比乍看之下大。只回覆主動來信客戶的客戶支援流程，在用盡額度前都是免費的，其後則按則收費。先主動聯絡客戶的流程，每則送達的範本都要付費，而自 2026 年 10 月 1 日起，在開啟時段內發送的實用類範本也包括在內。 因此，整合的成本取決於送達訊息的數量及其類別，而不是對話的數量。兩個發送相同數量訊息的系統，Meta 的收費可以相差很遠。 ### Meta 向誰收費？ 向您自己的 WhatsApp Business Account 所設的付款方式收費，並在 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-hant/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。三個自動化平台中，只有它可以做到。 --- ## 連接後 WhatsApp Business 應用程式的變化 https://easycoexistence.com/zh-hant/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 應用程式。 **我會失去舊有對話嗎？** 不會。對話會保留在應用程式中，啟用服務時亦可選擇與 API 分享約 6 個月的記錄。 **我們仍可使用群組嗎？** 在應用程式中可以，完全如常。透過 API 則不可以，任何服務供應商都是如此。 **如果兩星期內沒有人開啟應用程式，會怎樣？** Meta 會中斷 API 一側。重新連接即可恢復，而應用程式在整個過程中不受影響。 --- ## Coexistence 參考指南 https://easycoexistence.com/zh-hant/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 帳戶所設定的付款方式扣除。在 24 小時客戶服務時段內回覆免費。在時段外開啟對話必須使用訊息範本，並會收費。 ### 已連接裝置 Coexistence 不是已連接裝置，也不會使用這種機制。已連接裝置是指在其他地方登入的消費者端應用程式；非官方工具會自動操作這種裝置，而 WhatsApp 條款禁止此做法。本功能完全不使用該機制。 ### 功能限制 這些限制由 Meta 設定，所有供應商都完全相同。 - 群組聊天無法透過 API 使用。 - 訊息範本不能從手機應用程式發送，只能透過 API 發送。 - 發送量固定，不會隨品質及級別提升而擴展。 - 聊天記錄分享會在註冊期間一次決定。 ### 資格 號碼必須符合以下全部條件，才能連接。 - 已在 WhatsApp Business 應用程式中啟用，而不是消費者應用程式。 - 位於您可以存取的 Business Portfolio 中。 - 尚未連接至其他供應商的應用程式。 ### 操作注意事項 連接後有些事項確實會發生，卻很容易被忽略。 - 必須定期開啟應用程式，否則 Meta 會解除連接 API 一側。 - 解除連接會連同應用程式一起移除 Webhook 覆寫設定。 - 品質評分採輪詢而非推送，因此評分下降時不會發出通知。 - 沒有第二組認證資料時，被撤銷的存取權杖與號碼遭移除看起來完全相同。 ### 帳戶選擇注意事項 在 Embedded Signup 期間，Business Portfolio 與 WhatsApp Business 帳戶會分別選擇。選錯帳戶會將號碼連接至非預期位置；之後要移動號碼，便必須先解除連接，再重新完成整個流程。 ### 單向決定 是否分享現有聊天記錄只會詢問一次，之後不能重新選擇。同步也必須在註冊後 24 小時內開始，而且只能執行一次。錯過時限時，兩者都會產生不熟悉的錯誤，而不是發出警告。 ### 解除連接或還原 您可以隨時從控制台或透過連接器解除號碼連接。WhatsApp Business 應用程式會完全如常運作，對話及記錄均保持完整；號碼曾經連接並不會永久改變其本身。 - 將 Coexistence 當成不同的 API。實際上它是採用不同註冊方式的 Cloud API。 - 圍繞群組聊天建立流程。所有供應商都不支援群組聊天。 - 以為重新連接會還原 Webhook 目的地。實際上不會。 **這與 Cloud API 相同嗎？** 是。Coexistence 是註冊至 Cloud API 的方式，同時讓 WhatsApp Business 應用程式繼續使用該號碼。 **可以還原嗎？** 可以。解除連接後，應用程式及其對話會完全保持原狀。 **團隊需要接受培訓嗎？** 不需要。他們繼續像現在一樣使用 WhatsApp Business 應用程式。 **為甚麼應用程式不能發送訊息範本？** 訊息範本是平台功能，而不是應用程式功能。24 小時時段以外的內容都會透過 API 發送。 --- ## 哪些內容會同步至 API，哪些不會 https://easycoexistence.com/zh-hant/docs/what-syncs-and-what-does-not 聯絡人及一對一訊息記錄會同步至 API，之後訊息會雙向同步。群組不會同步，WhatsApp Business 應用程式的專屬工具也不會，包括目錄、訂單、狀態、標籤、快速回覆、歡迎訊息及離開訊息。 ### 哪些內容會同步 有兩項，而且這兩項對於在企業多年使用的號碼上開始使用軟件最重要。 - 聯絡人：每個擁有 WhatsApp 號碼的聯絡人，都可以同步至平台。 - 一對一訊息記錄，讓 API 不會看不到 API 建立前已發生的對話。 - 從此之後，訊息會雙向同步：API 發出的訊息會顯示在應用程式中，而團隊在應用程式輸入的內容會傳送至您的系統。 ### 哪些內容不會同步 不會同步的內容比人們預期更多。在向客戶作出承諾前，值得先閱讀這份清單。這些都不是供應商的限制，而是平台的運作方式。 - 群組聊天不會同步，任何供應商的 API 都無法存取群組聊天。 - 商業工具：目錄、訂單及狀態。 - 訊息工具：歡迎訊息、離開訊息、快速回覆及標籤。 - 頻道、語音及視像通話，以及商業檔案資料。 ### 為何應用程式的專屬工具不會同步 因為這些是應用程式的功能，而不是平台的功能，API 沒有相應功能。 快速回覆及標籤儲存在裝置上。當沒有人查看應用程式時，離開訊息會由應用程式發出。這些都不是 API 概念，因此沒有可供同步至 API 的內容。 實際上，如果企業依靠標籤整理工作，就必須繼續在應用程式中使用標籤，而軟件無法查看這些標籤。如果這種整理方式對您的建設內容很重要，就必須在您的系統一方重新建立，而不是嘗試從應用程式讀取。 ### 您可能錯過的期限 同步必須在完成啟用後 24 小時內開始。錯過後，必須先解除連接，再重新連接號碼，才有另一次機會。 這與規管訊息發送的 24 小時客戶服務時限不同，但兩者經常被混淆。前者從客戶最後一次訊息開始計算，決定能否傳送自由文字。這個期限則從完成啟用開始計算，決定是否仍可同步訊息記錄。 因此，最好在號碼連接當天決定是否同步記錄，而不是等到整合工作開始時才決定，因為兩者通常相隔不同的一週。 - 向客戶承諾標籤及快速回覆會顯示在您的系統中。它們會留在應用程式內。 - 圍繞群組聊天建立任何功能。任何供應商都不會同步群組聊天。 - 等到整合完成後才同步記錄。期限是完成啟用後 24 小時。 **我的舊對話會顯示在 API 中嗎？** 如果您在啟用流程中接受同步，一對一記錄便會同步。群組對話不會同步。 **軟件可以查看我的標籤嗎？** 不可以。標籤是應用程式功能，沒有相應的 API 功能，因此會留在裝置上。 **團隊會失去快速回覆嗎？** 不會。快速回覆會如常在應用程式中運作，軟件只是不可以查看它們。 **如果我錯過 24 小時同步期限，會怎樣？** 必須先解除連接號碼，再重新連接，重新執行啟用流程，並開啟新的期限。 --- ## Coexistence 後哪些 WhatsApp 功能會停止運作 https://easycoexistence.com/zh-hant/docs/features-disabled-by-coexistence 號碼透過 Coexistence 連接後，會有 4 項功能停止運作：一對一聊天中的消失訊息、僅限檢視一次的訊息及即時位置全部停用，廣播清單則完全停用，現有清單會變成唯讀，而不是被刪除。 ### 4 項功能 每項功能都是在平台層面停用，而不是隱藏，原因都與 API 能夠查看對話有關。 - 消失訊息：所有一對一聊天均會停用。 - 僅限檢視一次的訊息：所有一對一聊天均會停用。 - 即時位置訊息：所有一對一聊天均會停用。 - 廣播清單：會停用，現有清單會變成唯讀，而不是被移除。 ### 為何特別是這 4 項功能 因為每項功能都作出 API 無法配合的承諾。 消失訊息承諾訊息不會保留。僅限檢視一次的訊息承諾訊息只能被查看一次。這兩項承諾都取決於沒有其他系統保留副本，而已連接的號碼按定義會將這些訊息傳送至另一個系統。 即時位置是連續串流，而不是訊息，API 沒有相應表示方式。廣播清單是在應用程式端一次向多人發送訊息的方式，而平台對此提供的方案是訊息範本，須經核准後透過 API 發送。 因此，這些限制並非任意決定，而是平台不再承諾無法履行的功能。 ### 連接客戶號碼前代表什麼 請先了解企業是否使用其中任何功能，因為事後才發現會造成不愉快的溝通。 廣播清單最容易影響實際營運的企業。商店若每週透過廣播清單向 200 位客戶發送訊息，便會失去這套流程。替代方案是經核准的推廣訊息範本，但帳戶需要設定付款方式，並須經 Meta 審查。 消失訊息影響的是另一類使用者，通常是曾經開啟功能後忘記關閉的人。除非涉及配送或外勤服務，企業幾乎不會使用即時位置。 - 在未告知企業的情況下連接依賴廣播清單的號碼。替代方案是訊息範本，並須經核准及處理付款。 - 以為現有廣播清單會被刪除。它們會變成唯讀。 - 以為號碼保持連接時這些功能會恢復。它們不會恢復。 **可以重新啟用消失訊息嗎？** 號碼連接期間不可以。中斷連接後，應用程式會恢復正常運作。 **現有廣播清單會被刪除嗎？** 不會。它們會變成唯讀，內容會保留，但無法再發送訊息。 **這會影響群組聊天嗎？** 文件所述的停用只適用於一對一聊天。在 Coexistence 號碼上，群組完全不在 API 內。 **什麼可以取代廣播清單？** 透過 API 發送的經核准推廣訊息範本，並需要在您自己的 WhatsApp Business 帳戶設定付款方式。 --- ## 哪些號碼符合 Coexistence 資格 https://easycoexistence.com/zh-hant/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 目前針對應用程式使用者的入門文件明確表示完全沒有地區限制，而於地區逐步推出的安排已在 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-hant/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 傳送訊息事件，這是透過我們的應用程式訂閱您帳戶時設定的覆寫。未設定目的地的帳戶，其事件會回退至我們的 callback，而處理程式會捨棄事件，不會持久儲存。 ### Coexistence 本身 連接後，WhatsApp Business 應用程式是否仍可在該號碼上運作。 - 360dialog:: 對方的價格頁面沒有提及此事。請直接向對方查詢，不要相信比較頁面，包括本頁：未有文件記載的功能，不代表沒有該功能。 - EasyCoexistence:: 這就是整項產品。號碼透過 Meta 自己的 Coexistence 流程連接，應用程式照常運作，而兩個介面都能看見對方傳送的內容。 ### 您需要完整 BSP 關係的情況 這是一種實際存在的需要。 - 360dialog:: 當您購買的是供應商關係，而不只是連接。對方是有長期營運歷史、地區覆蓋及支援架構的成熟 BSP，小型產品無法提供同等服務。最高級別之所以存在，是因為大型發送者需要小型使用者不需要的功能。 - EasyCoexistence:: 專注型產品：提供電郵支援，以及顯示事件內容和時間的連接時間線。這正是自行建立介面的使用者所需，但它不是帳戶管理關係。 ### 應選擇哪一個 如果您需要指定的客戶經理，以及由真人負責的升級處理途徑，那就是 BSP 關係，而對方正是這種服務。 如果您管理客戶的號碼，並圍繞這些號碼建立軟件，計算結果便會決定選擇。同一種收費模式，價格只有五分之一，加上有人監察連接，訊息會傳送至您自己的系統，這種產品才會隨代理商的客戶數量擴展，而不是成為負擔。 - 只比較每月金額。費用涵蓋的內容，比數字本身有更大差異。 - 假設任何一方會加收 Meta 的費用。雙方均不會加價，費用由 Meta 直接向您收取。 - 把未有文件記載的功能當作不存在。請向對方查詢，不要相信比較頁面，包括本頁。 **價格是最新的嗎？** 這些價格是 360dialog 於 2026 年 9 月在其價格頁面公布的價格，上方亦有連結。價格會變更，決定前請查閱來源。 **任何一方會加收 Meta 的費用嗎？** 不會。雙方均會直接轉嫁費用，而 Meta 會直接向您自己的 WhatsApp Business 帳戶收取費用。 **360dialog 支援 Coexistence 嗎？** 對方的價格頁面沒有提及此事。這不能證明任何一方的情況，值得向對方查詢。 **哪一個較適合代理商？** 取決於您想為每個客戶使用一個平台，還是為每個客戶使用一個連接。客戶數量增加時，每個號碼的成本更為重要。 --- ## EasyCoexistence 與 WATI https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-wati 兩者是不同產品，不是同一產品的競爭版本。WATI 提供共用團隊收件匣，按使用者及每月活躍聯絡人數量收費。EasyCoexistence 提供連接本身，按號碼收費，完全不設收件匣。 ### 每月帳單實際支付的是甚麼 兩款產品按不同單位定價。對於持有多個號碼的客戶，這項差異每月都會累積。 - WATI:: 按使用者及每月活躍聯絡人收費。截至 2026 年 9 月，公開方案涵蓋 3 至 10 名使用者及 500 至 2,500 名聯絡人，因此每聘用一名代理及每聯絡一名客戶，帳單都會增加。 - EasyCoexistence:: 每個已連接號碼收取固定費用，不設使用者或聯絡人上限。代理的第 20 位客戶收費不會高於第 1 位客戶，繁忙月份與清閒月份也一樣。 ### 客戶的對話最終會存放在哪裏 這是日後無法挽回的差異，而且源於兩款產品的本質。 - WATI:: 存放在對方的平台上。共用收件匣必須儲存訊息內容，才能在任何人開啟時重新顯示。對方的定價頁面將此列為每個方案的核心功能。 - EasyCoexistence:: 不會存放在我們這一側。Meta 會將訊息事件直接傳送至您指定的 URL，任何到達我們備用回呼的內容都會被捨棄，不會持久儲存。這由程式碼強制執行，而不是政策聲明。 ### 您的團隊是否需要改變工作方式 這是企業主在答應任何方案前都會提出的問題。 - 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-hant/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 自有的 API，由 Meta 提供文件，而 Webhook 會傳送至您的端點。您不需要依賴我們的任何內容來建構，這也是可以離開的原因。 ### 誰監察連接 定價頁很少提及，卻正是這項產品存在的原因。 - respond.io:: 其定價頁沒有處理這項內容，因此不應妄下結論。如果您持有客戶的號碼，請具體查詢連接無聲中斷時會發生甚麼。 - EasyCoexistence:: 按排程輪詢品質評分、訊息層級及吞吐量。按名稱處理 Meta 的帳戶事件。保留兩組憑證，避免把已撤銷的存取權杖誤判為號碼遺失。重新連接後會重新套用 Webhook override。 ### 何時需要平台 值得說明，因為兩項產品回答的是不同問題。 - respond.io:: 當您需要平台時。其已公布計劃包括團隊及自訂控制台、工作流程、廣播訊息、AI 代理及報告，高級別計劃更包括 SSO 及多個工作區。它是多渠道平台，而不只支援 WhatsApp。 - EasyCoexistence:: 刻意設定為不同範圍：一個號碼、一個連接、16 個 MCP 工具及一個 Webhook，介面則由您自行處理。 ### 應選擇哪一個 這是不同層次，而非同一事物的競爭版本。如果您這邊沒有人建構介面，又想要一個讓代理工作的完整地方，您要找的是平台。 如果由您負責建構，平台會成為您技術堆疊中的競爭者。您要為使用者根本看不到的控制台按席位付費，為產品已處理的對話按聯絡人付費，並依賴抽象層整合，而不是 Meta 記錄並維持穩定的 API。 EasyCoexistence 就是底層連接：每個號碼收取固定費用，Webhook 指向您的系統，並監察連接，避免無聲故障變成客戶流失。 - 把 US$ 9 與 US$ 79 比較，彷彿兩者購買的是同一樣東西。事實並非如此。 - 當您需要產品時卻選擇連接。您可能要花數月重新建構控制台。 - 假設任何供應商都會監察連接。請具體查詢，定價頁很少會說明。 **哪一個適合我？** 兩者屬於不同層次。respond.io 是供您使用的平台；這是其底層連接，適合自行建構介面的團隊。 **我可以由他們轉到您這裏嗎？** 號碼屬於您，可以透過 Coexistence 連接。您放棄的是其控制台及工作流程。 **你們有工作流程或 AI 代理嗎？** 沒有。MCP 連接器可讓助理使用該號碼，而 Webhook 可讓您自己的系統作出回應。兩者都不是工作流程建構工具。 **這些價格是最新的嗎？** 價格截至 2026 年 9 月按當時公布的資料列出，連結亦已附上。決定前請查閱來源。 --- ## EasyCoexistence 與 Dualhook https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-dualhook 兩者都是採用相同核心架構的 Coexistence 供應商：WhatsApp Business 應用程式繼續運作，而訊息 Webhook 會由 Meta 直接傳送到您的伺服器，不經供應商。兩者相似之處多於差異，但以下差異值得了解。 ### 兩個產品的定位 這是網站上最接近的比較，因為兩者的定位幾乎相同。 - Dualhook:: 採用相同核心承諾的 Coexistence 供應商：保持 WhatsApp Business 應用程式運作，將訊息 Webhook 由 Meta 直接傳送到您的伺服器，而不儲存訊息。他們的文件將此稱為 Webhook Override。 - EasyCoexistence:: 相同機制，亦採用 Meta 使用的相同名稱。我們會在應用程式對 WhatsApp Business 帳戶的訂閱中設定 override_callback_uri，將訊息路徑欄位轉送到您的端點，同時保留操作欄位。 ### 訊息會傳送到哪裏 兩者都會直接傳送。差異在於未被轉送的事件會如何處理。 - Dualhook:: 直接由 Meta 傳送，且不儲存訊息。他們的網站清楚說明這一點，而我們採用相同架構。 - EasyCoexistence:: 傳送方式相同。我們額外處理後備路徑：未設定覆寫的帳戶會將事件傳送到我們的預設回呼，處理程式會捨棄事件而不予保存。這項承諾由程式碼執行，而不是只寫在政策中。 ### 14 天閒置規則 Meta 會在主要裝置約 14 天沒有活動後中斷 Coexistence 連接。兩個產品的處理方式不同。 - Dualhook:: 他們的文件說明會在第 13 天發出警告，並提供倒數及提醒電郵。這只是提醒時鐘正在運行，與了解連接實際中斷的原因不同。 - EasyCoexistence:: 我們會監察中斷本身，並讀取 Meta 的原因欄位，區分 PRIMARY_INACTIVITY、BUSINESS_DOWNGRADE、CHANGE_NUMBER 及其他原因。原因能區分兩星期沒有活動與客戶實際離開。 ### 重新連接會破壞甚麼 閒置規則所帶來、成本最高的後果，也是您應向任何供應商詢問的問題。 - Dualhook:: 他們的文件沒有說明重新連接後 Webhook 覆寫會如何處理。這不代表他們沒有處理，只是值得直接向他們提出的問題。 - EasyCoexistence:: 移除會將應用程式從帳戶解除安裝，覆寫也會一併消失，因此重新連接雖然恢復發送及監察，傳送到您伺服器的功能卻會靜默停止。我們會在每次重新連接時重新套用覆寫，因為曾有實際號碼乾淨地重新連接後停止傳送。 ### 每個號碼的費用 兩者都按每個已連接號碼收取固定月費，而不是按使用者或訊息收費，也不會加價轉嫁 Meta 的對話費用。 - Dualhook:: 他們自己的比較頁面說明，固定月費由每月 US$ 12 起，截至 2026 年 9 月仍是公開價格。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9 起，隨號碼增加最低降至 US$ 1，不設使用者或聯絡人上限。對代理商而言，每增加一個客戶號碼，差額便會累積。 ### MCP 連接器 對特定使用者群組而言，這是我們領先的地方。 - Dualhook:: 他們的文件沒有描述 MCP 伺服器。他們的產品透過 API 及控制台使用。 - EasyCoexistence:: 透過 OAuth 提供十六項工具的遠端 MCP 伺服器，讓 Claude、ChatGPT、Cursor 及 Claude Code 可以列出號碼、檢查狀態、發送訊息及範本，並設定 Webhook 目的地。對於從助理開始為客戶進行設定的代理商而言，這就是差異所在。 - 把未記載的功能當成不存在。請向他們查詢；本頁只指出其文件沒有說明之處，沒有自行猜測。 - 只按價格作決定。兩者的費用，相比 Meta 收取的對話費用都很低。 - 假設任何供應商都會在重新連接後重新套用 Webhook 覆寫。無論選擇誰，都應具體詢問。 **這兩個產品真的採用相同架構嗎？** 在訊息路徑上，是的。兩者都使用 Meta 覆寫 WhatsApp Business 帳戶 Webhook 傳送位置的能力，因此對話內容會傳送到您的伺服器，而不經供應商。 **兩者如何處理 14 天規則？** 他們會在第 13 天警告時鐘正在運行。我們會讀取 Meta 自己的中斷原因，區分兩星期沒有活動與客戶實際離開，並在之後重新套用 Webhook 覆寫，避免傳送功能靜默停止。 **EasyCoexistence 有甚麼不同？** 我們提供其文件沒有描述的 MCP 連接器及十六項工具，並會在重新連接移除覆寫後自動重新套用。 **這個頁面公平嗎？** 本頁每個數字都來自對方公開發布的頁面，並標明日期。決定前請先閱讀：由一方撰寫的比較是證據，不是裁決。 --- ## 可以在同一個號碼上使用 WhatsApp Business 應用程式和 API 嗎？ https://easycoexistence.com/zh-hant/whatsapp-business-app-and-api-same-number 可以。Meta 稱之為 Coexistence，這是官方功能，不是權宜方案。職員可繼續在手機上的 WhatsApp Business 應用程式回覆，Cloud API 同時在同一個號碼上運作，雙方都能看到相同的對話。 ### 一個號碼如何同時用於兩者？ 因為 Meta 為此建立了專用模式。過去這是沒有人想作出的取捨：將號碼遷移至 API 後，WhatsApp Business 應用程式便會停止運作，因此由職員在手機上回覆客戶的企業，只能在熟悉客戶的職員與想加入的自動化功能之間二選一。 Coexistence 消除了這個取捨。Meta 會將號碼註冊為 API 號碼，同時保持 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 會選取資產組合、帳戶和號碼，您只需在 WhatsApp Business 應用程式中掃描代碼確認，幾分鐘內即可完成連接。整個過程中應用程式都會繼續運作，包括建立連接期間。 - 以為必須二選一。Coexistence 正是為了讓您不必作出選擇。 - 期待透過 API 使用群組聊天。群組聊天會留在應用程式中，在任何地方都不屬於 API 範圍。 - 等待 Meta 控制台出現選項。Coexistence 入門流程是透過 Tech Provider 進行。 **這是官方功能嗎？** 是。Coexistence 是 Meta 自己的功能和名稱，不是橋接工具、已連接裝置或權宜方案。 **職員會察覺有不同嗎？** 只有 4 項功能會停用：消失訊息、僅限查看一次、即時位置和廣播清單。其他功能一如以往。 **我會失去聊天記錄嗎？** 不會。記錄會保留在手機上。號碼連接時，最近的記錄也會複製到 API 一方。 **可以取消嗎？** 可以。中斷號碼的連接後，應用程式會完全照常運作，對話內容也會完整保留。 --- ## 如何連接 WhatsApp API 而不遺失聊天紀錄 https://easycoexistence.com/zh-hant/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-hant/cheapest-whatsapp-business-api API 本身免費。您要支付的是 Meta 的對話費，以及供應商的存取費用。無論您選用哪間供應商，Meta 的部分都一樣，因此唯一值得優化的變動成本就是供應商費用，而最便宜的模式是每個號碼收取固定費用，不設加價。 ### 您實際支付的是甚麼？ 兩項不同的費用，而混淆兩者正是這個類別的價格比較出錯的原因。 第一項是 Meta 的對話定價。Meta 按類別就對話收費，費率因國家而異，而 24 小時視窗內的服務對話，處理方式亦有別於由商戶發起的對話。無論您透過哪間供應商購買，這項成本都會存在，因為它屬於 Meta，而且通常是較大的金額。 第二項是供應商收取的存取費用。這完全取決於供應商的商業決定，也是您可以透過選擇不同供應商而真正改變的唯一帳單部分。任何人在未分開這兩項費用的情況下比較供應商總成本，實際上比較的只是噪音。 ### 錢從哪裏流失？ 流失在加價上，而且每則訊息的金額很小，容易被忽略。 多間供應商會在 Meta 費用之上，加收每則訊息費用。Twilio 公布每則入站及出站訊息 US$ 0.005。Gupshup 公布 US$ 0.001。其他供應商則報出已包含 Meta 費用的綜合費率，這代表確實存在加價，但完全無法與 Meta 公布的費率核對。 每則訊息十分之一美仙看似微不足道，但乘起來就不同。每月 100000 則訊息時，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-hant/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-hant/docs/template-status-lifecycle 訊息範本會依次經歷不同狀態，而核准只是中段，並非終點。已核准的訊息範本可能因品質問題而暫停，之後恢復使用，再次暫停，最終永久停用，全程無需任何人操作。 ### 各種狀態 訊息範本通常會依次經歷以下狀態。 - PENDING：已提交，正在等待審核。 - APPROVED：可用於傳送。 - REJECTED：審核時被拒絕，通常涉及結構或類別。 - PAUSED：品質下降後暫時無法使用。 - DISABLED：永久無法使用，生命週期的終點。 ### 訊息範本如何被暫停 不是由您的操作造成。收件人封鎖或舉報使用該訊息範本傳送的訊息，訊息範本本身的品質評分由綠色降至黃色，再降至紅色，Meta 便會暫停它，以阻止情況惡化。 暫停是暫時性的，會自行解除。重要的是接下來會發生甚麼：重複暫停會逐步升級，而持續回到紅色的訊息範本，最終會永久停用，不會再次只是暫停。 ### 兩個 Webhook 要查看完整週期，兩者缺一不可。只訂閱其中一個會留下盲點。 - message_template_status_update：核准、拒絕、暫停及停用。 - message_template_quality_update：品質評分在綠色、黃色和紅色之間變動。 - 品質 Webhook 是預警，狀態 Webhook 是後果。 - 兩者預設均未啟用，因此必須同時訂閱。 ### 為甚麼黃色是應採取行動的時刻 到了訊息範本被暫停時，使用它傳送已經會失敗，推廣活動也已經中斷。黃色狀態下，訊息範本仍然運作，而下降趨勢已經可見。 在黃色狀態採取行動，表示要同時檢視受眾和文字內容。向沒有預期收到訊息的人傳送一個寫得很好的訊息範本，同樣會迅速累積封鎖；只改寫內容而保留名單，並不能改變結果。 ### 編輯會帶來甚麼影響 已核准的訊息範本可以編輯，但編輯後會重新進入審核。這項功能很有用，但在正式環境中會帶來一個常見後果：如果編輯改變了變數數量，所有未更新整合的傳送都會開始回傳錯誤 132012。 應將訊息範本的變數數量視為整合合約的一部分，而不是由市場營銷人員單獨管理的文字內容。 - 把核准視為永久有效。已核准的訊息範本可能被暫停，最終也可能被停用。 - 只訂閱狀態而不訂閱品質。quality 欄位是預警。 - 編輯訊息範本的變數，卻沒有檢查負責傳送的程式碼。 **已核准的訊息範本會一直維持核准嗎？** 不一定。持續的負面回饋可能令它暫停，最終永久停用。 **暫停和停用有甚麼分別？** 暫停會自行解除。停用是永久性的，訊息範本不能再次使用。 **我如何及早察覺？** 訂閱訊息範本品質 Webhook。它會在訊息範本仍然運作時，回報轉為黃色。 **為甚麼編輯後傳送開始失敗？** 如果編輯改變了變數數量，未更新的整合便會傳送錯誤數量的參數，並收到錯誤 132012。 --- ## 傳送含變數的訊息範本 https://easycoexistence.com/zh-hant/docs/sending-a-template-with-variables 訊息範本變數按位置排列，不是按名稱排列。您要按次序，為每個元件傳送參數清單，而數量必須完全符合範本定義。次序或數量出錯會產生 3 種不同錯誤，每種都指向不同問題。 ### 如何配對參數 按位置配對，不是按名稱配對。內文清單中的第 1 個參數會填入第 1 個佔位符，第 2 個參數會填入第 2 個，依此類推。您無法為變數命名，而交換兩個參數後，訊息仍會成功傳送，只是數值會出現在錯誤位置。 這種情況最危險，因為不會出現任何失敗。客戶收到訂單確認時，日期出現在金額應有的位置，而且任何地方都不會記錄錯誤。 ### 元件是分開的清單 標頭變數和內文變數不共用同一個清單。每個元件都有自己的參數，將它們合併便會造成數量不一致。 - 標頭參數放在標頭元件內，而且最多只有一個。 - 內文參數放在內文元件內，並按次序排列。 - 按鈕 URL 參數放在按鈕元件內，並按按鈕編號排列。 - 為所有參數傳送一個扁平清單會返回錯誤 132000。 ### 正確處理語言 範本由名稱和語言共同識別，因此同一名稱的兩種語言代表兩個範本。範本以 en_US 建立時，傳送 en 不會自動改用備用語言，而會因錯誤 132001 失敗，錯誤訊息會顯示範本不存在。 列出該號碼的範本，並複製準確的語言字串，不要自行假設其格式。這是最常見的範本錯誤，也是描述最不清晰的一種。 ### 具有類型的參數 大部分參數都是純文字，但部分參數不是。若將這些參數當作文字傳送，便會因錯誤 132012 而失敗。 - 貨幣參數包含金額、貨幣代碼和備用字串。 - 日期和時間參數包含帶有備用值的結構化物件。 - 媒體標頭參數包含媒體 ID 或連結，而不是檔案名稱。 - 如果收件者的應用程式無法格式化數值，便會顯示備用字串。 ### 每個錯誤代表甚麼 這 3 種失敗可以區分。如果分開記錄，而不是統稱為範本錯誤，便能大幅減少猜測。 錯誤 132001 代表名稱和語言組合無法解析，因此先檢查語言。錯誤 132000 代表數量錯誤，因此要與範本本身的定義比較。錯誤 132012 代表數值格式錯誤，通常是把具有類型的參數當作純文字字串傳送。 - 以為 en 會自動改用 en_US。實際不會，錯誤訊息會顯示範本不存在。 - 將標頭和內文參數合併成一個清單。它們屬於分開的元件。 - 將貨幣或日期當作純文字傳送。具有類型的參數有固定格式。 **訊息範本變數有名稱嗎？** 沒有。它們按位置排列，因此參數次序就是全部規則。 **為甚麼我的範本不存在？** 通常是語言代碼有誤。範本由名稱和語言共同識別，而且不設備用語言。 **如果我傳送太多參數會怎樣？** 錯誤 132000。參數過多和過少會以相同方式失敗。 **如何傳送金額？** 使用包含金額、貨幣代碼和備用字串的貨幣參數，而不是純文字。 --- ## 頻率限制與訊息吞吐量 https://easycoexistence.com/zh-hant/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 回報。 耗盡此限制的元兇是輪詢。每 30 秒查詢一次狀態，一天便是數千次呼叫，而相關資料每月只會變動數次；使用 Webhook 可以省卻當中幾乎所有呼叫。 ### 如何提高限制 靠的是品質和發送記錄，而不是付款。沒有可購買的方案，也沒有任何供應商能代您調高上限。 - 維持綠色品質評級；收件人封鎖會拉低評級。 - 穩定地發送，避免突發大量發送。 - 完成商家驗證，這是由 250 升至 2,000 的途徑之一。 - 使用至少一半的現有限額；2,000 以上的上調會自動進行。 - 把所有頻率限制當作同一種。四種不同的限制會產生四種不同的錯誤。 - 以很短的間隔輪詢狀態。這會把管理限制耗費在極少變動的資料上。 - 期望付費換取更高限制。限制是按品質和發送記錄調整的。 **為甚麼發送量很低也會受到頻率限制？** 很可能是單一收件人限制，即錯誤 131056。它限制傳給同一個人的訊息數量，與您的帳戶總量無關。 **可以付費購買更高的訊息限制嗎？** 不可以。限制會按品質和發送記錄自動提升。 **Coexistence 的吞吐量是否較低？** 是。Meta 將其上限訂得比標準 Cloud API 號碼低，而且沒有任何供應商可以調高。 **哪些操作會計入管理限制？** 讀取及設定類呼叫：列出號碼、範本和狀態。使用 Webhook 可以避免當中幾乎所有呼叫。 --- ## 傳送互動訊息：按鈕及清單 https://easycoexistence.com/zh-hant/docs/sending-interactive-messages 互動訊息讓收件人點選按鈕或清單，而無須自行輸入。互動訊息分為回覆按鈕及清單訊息兩種，兩者都有固定的小量限制，這些限制對對話設計的影響往往最大。 ### 回覆按鈕 一則訊息下最多可放 3 個按鈕。收件人點選其中一個後，回覆會以一般傳入訊息形式送到您的 Webhook，並帶有該按鈕的 id，因此您應根據 id 而非標題進行配對。標題上限為 20 個字元，實際比想像中短，通常需要因此重寫內容。 - 每則訊息最多 3 個按鈕。 - 標題上限為 20 個字元。 - 每個按鈕都帶有由您選定的 id，回覆時會一併返回。 - 按鈕周圍可選擇加入標頭、內文及頁尾。 ### 清單訊息 一個按鈕可開啟最多 10 行的選單，並可分為最多 10 個區段。每行都有標題、可選的說明及 id。當 3 個按鈕不足以應付需求時，可使用清單訊息；但請記住，收件人必須先開啟清單，才會看到其中內容，因此按鈕標籤尤其重要。 - 總共最多 10 行，分布於最多 10 個區段。 - 行標題上限為 24 個字元，說明上限為 72 個字元。 - 每則訊息只能有一個清單，不能與按鈕同時使用。 - 並非所有類別的訊息範本均可使用。 ### 回覆如何送達 回覆會像其他傳入訊息一樣，送到同一個訊息 Webhook，並帶有指出按鈕或行 id 的互動物件。您無須另外訂閱任何項目。 請根據 id 而非標題進行配對。標題可能會由負責編輯內容的人員修改，而根據文字配對的處理程式，第一次有人修正錯字時便可能在沒有提示的情況下失效。 ### Coexistence 有何變化 按鈕及清單本身沒有任何變化。它們都是一般的 Cloud API 訊息，在 Coexistence 號碼上的運作方式與其他號碼相同。 變化在於回覆送達的位置：客戶點選後，回覆會同時送到手機上的 WhatsApp Business 應用程式及您的 Webhook，因為 Coexistence 號碼會同時送達兩處。若處理程式會自動回覆，便應考慮人員可能在應用程式中回覆同一則訊息。 - 根據按鈕標題配對回覆。標題會被修改，id 則不會。 - 按超過 3 個按鈕來設計。這是硬性限制，沒有替代方案。 - 忘記人員可能會在 WhatsApp Business 應用程式中回覆同一次點選。 **我可以傳送多少個按鈕？** 3 個。這是平台的硬性限制，沒有替代方案。 **有人點選後會返回甚麼？** 一則送到訊息 Webhook 的一般傳入訊息，並帶有您為該按鈕或行指定的 id。 **可以同時使用按鈕及清單嗎？** 不可以。每則訊息只能使用其中一種。 **這些訊息需要額外付費嗎？** 不需要。它們都是一般訊息，Meta 會按照該對話中其他訊息的相同方式計費。 --- ## 傳送媒體：圖片、影片、音訊及文件 https://easycoexistence.com/zh-hant/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。使用連結則讓 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 有效多久？** 並非永久有效，因此接收媒體後，應在事件抵達時盡快擷取。 **連接時會同步舊媒體嗎？** 不會。歷史同步只包括最近的訊息內容，連接前的媒體會留在手機上。 --- ## 訊息反應：發送及接收 emoji https://easycoexistence.com/zh-hant/docs/message-reactions 反應會將單一 emoji 附加到現有訊息。發送反應時，您需要指定訊息 ID 和 emoji；移除反應時，則以空白 emoji 字串發送相同反應，而不是呼叫刪除操作。 ### 發送反應 類型為 reaction 的訊息，會帶有所作反應的訊息 ID 及單一 emoji。向同一則訊息發送第二個反應時，會取代第一個反應，而不是在其上新增，因為每位發送者每則訊息只能保留一個反應。 訊息 ID 必須是您的號碼可以看見的訊息：來自該客戶的入站訊息，或您發送給該客戶的訊息。 ### 移除反應 這是最容易令人意外的部分。沒有刪除請求。您要發送相同的反應訊息，並將 emoji 欄位設為空白字串，這樣便會清除反應。 如果處理程式預期接收移除事件，便會一直等待。實際送達的是帶有空白 emoji 的反應，其結構與新反應相同，因此必須檢查該欄位，將它解讀為移除操作。 ### 接收反應 入站反應會在 messages Webhook 上，以類型為 reaction 的訊息送達，並指出所附加的訊息 ID 及 emoji。 - 訂閱 messages 欄位；沒有獨立的 reactions 欄位。 - 空白 emoji 表示客戶已移除其反應。 - 所參照的訊息 ID 是您較早前發送或接收的訊息。 - 反應不會重新開啟 24 小時服務時段。 ### 服務時段仍然適用 反應是一則訊息，因此發送反應需要 24 小時客戶服務時段處於開啟狀態。對 3 天前客戶發送的訊息作出反應，會返回錯誤 131047，與文字訊息的情況完全相同。 接收客戶的反應會重新開啟服務時段，因為任何入站訊息都會產生這個效果。這對自動化流程很重要：客戶對您最後一則訊息按下讚，即表示您現在可以自由回覆。 - 尋找刪除端點。移除反應是使用空白 emoji 的相同請求。 - 將空白 emoji 視為格式錯誤。這正是表達移除反應的方式。 - 在服務時段以外發送反應。它會像其他訊息一樣失敗。 **如何移除反應？** 以空白 emoji 字串發送相同的反應訊息。沒有刪除請求。 **反應是否需要付費？** 不需要。反應不會開啟可收費對話。 **我可以對任何訊息作出反應嗎？** 只可以對您的號碼曾發送或接收的訊息作出反應，而且必須在 24 小時服務時段內。 **客戶的反應會重新開啟服務時段嗎？** 會。客戶發送的任何入站訊息都會，包括反應。 --- ## 發送位置及聯絡人訊息 https://easycoexistence.com/zh-hant/docs/sending-location-and-contacts 位置訊息會發送附有可選名稱及地址的位置標記。聯絡人訊息會發送一張或多張聯絡人卡片。兩者都很簡單，但您需要知道，即時位置會隨對方移動而更新，Coexistence 號碼並不支援。 ### 位置訊息 緯度及經度可連同可選的名稱和地址顯示在位置標記下方。收件人會看到地圖預覽，並可在自己的地圖應用程式中開啟。 填寫名稱和地址是值得的。沒有這些資料，位置標記只會顯示座標，客戶無法知道自己查看的是否是正確分店。 ### 接收位置 客戶分享的位置會以 type `location` 的訊息形式，透過訊息 Webhook 傳入，包含座標；如果客戶的應用程式有提供，也會包含名稱和地址。 - 座標一定存在，名稱和地址則不一定。 - 分享的位置是一則訊息，因此會重新開啟 24 小時服務時段。 - 座標只可視為約數，手機定位準確度各有不同。 - 只儲存您需要的資料。Meta 並不提供位置歷史記錄。 ### 聯絡人訊息 您可在一則訊息中發送一張或多張聯絡人卡片，每張都包含 vCard 的欄位：姓名、電話、電郵、地址、機構及生日。收件人可直接儲存卡片。 這適合將正確聯絡人的資料交給客戶，無須在聊天中輸入號碼，避免資料以未格式化文字傳送後再由對方手動複製。 ### Coexistence 移除的功能 即時位置是 Meta 在號碼啟用 Coexistence 後會停用的 4 項 WhatsApp 功能之一，其他包括消失訊息、檢視一次媒體及廣播清單。 嘗試發送即時位置會傳回錯誤 131051，unsupported message type。這看起來像格式錯誤，但實際並非如此。沒有任何供應商可以啟用這項功能，因為這是 Meta 的限制，適用於每個 Coexistence 號碼。靜態位置標記不受影響，仍可正常使用。 - 發送位置標記時沒有加入名稱或地址。單靠座標，客戶無法得知任何資訊。 - 以即時位置為基礎開發功能。所有 Coexistence 號碼都不支援此功能。 - 當訊息類型確實不受支援時，卻把錯誤 131051 當成格式錯誤。 **可以發送即時位置嗎？** Coexistence 號碼不可以。Meta 會停用此功能，任何供應商都無法重新啟用。 **靜態位置標記可以使用嗎？** 可以正常使用，並可選擇在地圖預覽下方顯示名稱和地址。 **一則訊息可以包含多少位聯絡人？** 可以包含數位聯絡人。每位聯絡人都包含標準 vCard 欄位，收件人可直接儲存。 **分享的位置會重新開啟服務時段嗎？** 會。它與其他訊息一樣，屬於入站訊息。 --- ## EasyCoexistence 與 AiSensy https://easycoexistence.com/zh-hant/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-hant/compare/easycoexistence-vs-interakt Interakt 是按月訂閱、設有每位代理人上限的 WhatsApp 商務及支援平台。EasyCoexistence 是基礎設施，透過 Meta 自家的 Coexistence 功能連接號碼，將訊息傳送至您現有的系統，並按已連接號碼收費。對已有系統的企業，EasyCoexistence 每個號碼成本較低。 ### 兩款產品的定位 兩者並非爭奪同一項採購，釐清這點後，比較才有意義。 - 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。 **哪一款較便宜？** 如您已有系統並管理多個號碼，EasyCoexistence 的每個號碼成本低得多；五人共用一個收件匣時，Interakt 的席位方案可能更合適。 **我會失去共用收件匣嗎？** 您不需要轉移到共用收件匣。訊息會到達團隊現有的工具，您可以繼續在原處工作。 **WhatsApp 連接方式不同嗎？** 不會。兩者都是 Meta 的 Cloud API。不同之處在於前端連接的產品及收費方式。 **可以發送商品目錄訊息嗎？** 可以，透過您自己號碼上的 Cloud API，由您自己的系統發送。我們不會替您建立商品目錄，因為您的商店已經有一個。 --- ## EasyCoexistence 與 DoubleTick https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-doubletick DoubleTick 是按使用者收費的 WhatsApp 銷售平台，以流動裝置優先的共用收件匣為核心。EasyCoexistence 是基礎設施：透過 Meta 自有的 Coexistence 功能連接號碼，將訊息送到您現有的系統，並按已連接號碼收費。哪個較便宜，取決於您是否需要一個供團隊使用的產品。 ### 兩種產品分別是甚麼 兩者並非爭取同一項採購，清楚了解這點，才能令比較有用。 - 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 個號碼具備與第一個相同的功能，費用卻更低。 ### 離開時會怎樣 凡是保存您對話的產品，都值得提出這個問題。 - DoubleTick:: 收件匣、聯絡人歷史及自動化功能都在該平台內。這正是它們能運作的原因，也令離開平台變成一項遷移工作。 - EasyCoexistence:: 您的任何資料都不在我們這裡。訊息抵達時已送到您自己的系統，而號碼位於客戶自己的 Meta Business Portfolio，因此移除我們後，一切仍會留在原來的位置。 - 未按您自身的業務規模計算，就直接比較席位價格與按號碼收費。 - 團隊已在 CRM 工作，卻仍為收件匣付費。 - 以為 WhatsApp 連接方式不同。兩者底層都是 Meta 的 Cloud API。 **哪個較便宜？** 取決於業務規模。五人團隊使用一個收件匣，可能較適合按席位收費。擁有多個號碼及現有系統的企業，使用我們的服務按號碼計算，費用會低得多。 **我會失去共用收件匣嗎？** 您從未需要轉移到共用收件匣。訊息會抵達團隊現有的工具，亦即團隊原本工作的地方。 **WhatsApp 的連接方式不同嗎？** 不會。兩種方式都是 Meta 的 Cloud API。不同之處在於前端連接的是甚麼，以及如何計費。 **有流動應用程式嗎？** 我們提供的是基礎設施，因此團隊使用的應用程式就是原本已有的應用程式。WhatsApp Business 應用程式在整個過程中亦會繼續於手機上運作。 --- ## EasyCoexistence 與 Zoko 比較 https://easycoexistence.com/zh-hant/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。 **哪個較便宜？** 視乎業務規模而定。五人共用一個收件匣的團隊可能偏好席位；擁有多個號碼及現有系統的企業，使用我們按號碼收費的方案，成本會低得多。 **我會失去共用收件匣嗎？** 您從來不必轉移到另一個收件匣。訊息會到達您的團隊現有工具，而您本來就在那裡工作。 **WhatsApp 連接有所不同嗎？** 沒有。兩者都是 Meta 的 Cloud API。不同之處在於前端連接的是甚麼，以及如何收費。 **我使用 Shopify，應否使用 Zoko？** Zoko 按月方案提供已設定的 Shopify 流程。如果您的邏輯已位於自己的商店或後端，我們會以每個號碼 US$ 9 的價格將 WhatsApp 接入其中，讓您在訂單資料原有的位置保留流程。 --- ## EasyCoexistence 與 Trengo 比較 https://easycoexistence.com/zh-hant/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。代理商的第四十個號碼具備與第一個相同的功能，費用更低。 ### 離開時會發生甚麼 任何承載您對話的產品，都值得先問這個問題。 - Trengo:: 收件匣、聯絡人記錄及自動化功能都在該平台內。這正是它們能運作的原因，也令離開變成一個遷移項目。 - EasyCoexistence:: 我們不會存放您的任何資料。訊息到達時已傳送到您自己的系統，而號碼位於客戶自己的 Meta Business Portfolio 內，因此移除我們後，一切仍會留在原處。 - 未按您自身的規模，同時計算用戶名額費及每號碼費便直接比較。 - 團隊已在 CRM 工作，卻仍為收件匣付費。 - 以為 WhatsApp 連接方式不同。兩者底層都是 Meta 的 Cloud API。 **哪個較便宜？** 對已有系統及多個號碼的企業，EasyCoexistence 每個號碼便宜得多；只有單一收件匣的五人團隊則可選擇按名額收費。 **我會失去共用收件匣嗎？** 您不需要轉用新的收件匣。訊息會到達團隊現有的工具，您可繼續在原有工作環境處理。 **WhatsApp 的連接方式不同嗎？** 不會。兩者都是 Meta 的 Cloud API。不同之處在於前端連接甚麼，以及如何收費。 **我也需要電郵及聊天。你們涵蓋這些渠道嗎？** 不涵蓋，而且我們不會為此收費。我們會將 WhatsApp 連接到已處理其他渠道的支援系統。 --- ## EasyCoexistence 與 Rasayel https://easycoexistence.com/zh-hant/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 個號碼具備與第一個相同的功能，費用更低。 ### 離開時會怎樣 凡是承載您對話的產品，都值得先問清楚這點。 - Rasayel:: 收件匣、聯絡人歷史及自動化流程都存於該平台。這正是它們能夠運作的原因，也令離開平台變成一項遷移工作。 - EasyCoexistence:: 您的資料不會存放在我們這裡。訊息抵達時已送到您自己的系統，而號碼位於客戶自己的 Meta Business Portfolio 中，因此移除我們後，一切仍留在原處。 - 比較席位價格與按號碼價格時，沒有按您自己的使用規模計算總數。 - 團隊已在 CRM 工作，卻仍為收件匣付費。 - 以為兩者的 WhatsApp 連接不同。兩者底層使用的都是 Meta 的 Cloud API。 **哪個較便宜？** 5 人團隊使用一個收件匣，可能適合按席位收費的方案。擁有多個號碼及現有系統的企業，使用我們可按每個號碼支付更低費用。 **我會失去共享收件匣嗎？** 您不需要轉移到任何共享收件匣。訊息會抵達團隊現有的工具，大家繼續在原本的工作環境中處理。 **WhatsApp 連接方式不同嗎？** 不會。兩者使用的都是 Meta 的 Cloud API。不同之處在於前端連接的是甚麼，以及如何計費。 **你們支援 HubSpot 整合嗎？** 我們會將 Meta 的 Webhook 送到任何端點，因此具備傳入 Webhook 的 CRM，或前置的工作流程工具，都能直接接收對話。 --- ## EasyCoexistence 與 Callbell https://easycoexistence.com/zh-hant/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。 **哪一款較便宜？** 已有系統並需要多個號碼的企業，使用我們的按號碼定價通常便宜得多；單一號碼、五人共用一個收件匣時，Callbell 可能較合適。 **我會失去共用收件匣嗎？** 您從未需要轉移至共用收件匣。訊息會抵達團隊現有的工具，員工也會繼續在原本的工作環境處理訊息。 **WhatsApp 連接方式不同嗎？** 不會。兩者使用的都是 Meta 的 Cloud API。不同之處在於前端連接的是甚麼，以及如何收費。 **兩名代理使用時，Callbell 會較便宜嗎？** 若只有一個號碼，而且沒有現有系統，Callbell 可能較便宜。增加第二個地點或接入 CRM 後，按號碼收費很快便會更便宜。 --- ## EasyCoexistence 與 Baileys https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-baileys Baileys 是開放原始碼程式庫，直接實作已連接裝置通訊協定，從而連接 WhatsApp。它能夠運作，免費或成本低廉，但承受官方路徑沒有的風險：WhatsApp 商業條款並未提供透過已連接裝置工作階段自動傳送訊息的途徑，以這種方式使用的號碼可能在沒有警告下被限制或封鎖。EasyCoexistence 透過 Meta 自家的 Coexistence 功能連接同一號碼。 ### 兩者如何連接 WhatsApp 整個比較取決於這一點，其餘差異都由此而來。 - Baileys:: 以 TypeScript 編寫的程式庫，透過 websocket 實作 WhatsApp 的已連接裝置通訊協定。它像網頁用戶端一樣登入，掃描 QR code 後自行維持工作階段。不涉及 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-hant/compare/easycoexistence-vs-wppconnect WPPConnect 是一個開源專案，透過受控瀏覽器工作階段自動操作 WhatsApp Web。它確實可行，免費或成本低廉，但有官方途徑沒有的風險：WhatsApp 商業條款並未提供透過已連接裝置工作階段自動傳送訊息的途徑，以此方式使用的號碼可能在沒有警告下被限制或封禁。EasyCoexistence 則透過 Meta 自家的 Coexistence 功能連接同一個號碼。 ### 兩者如何連接 WhatsApp 整個比較的關鍵就在這裡，其他一切都由此而來。 - WPPConnect:: 一個在無頭工作階段操作 WhatsApp Web 的瀏覽器自動化專案，外加 REST 包裝層。號碼透過 QR code 連結，工作階段留在瀏覽器設定檔內，因此 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-hant/compare/easycoexistence-vs-evolution-api Evolution API 是開源 REST API，將非官方 WhatsApp 程式庫封裝在簡潔介面後。它能運作，且免費或費用低廉，但有官方方案沒有的風險：WhatsApp 商業條款並未提供透過已連接裝置工作階段自動傳送訊息的途徑，以這種方式使用的號碼可能在沒有警告下被限制或封鎖。EasyCoexistence 透過 Meta 自家的 Coexistence 功能連接同一個號碼。 ### 兩者如何連接 WhatsApp 整個比較的關鍵就在這裡，其他差異都由此而來。 - Evolution API:: 自行託管的 REST API 及管理器，將已連結裝置程式庫封裝在簡潔介面後，提供控制台、多執行個體支援及 Webhook。開發體驗良好，但每個執行個體底層仍是以 QR 碼連結的裝置。 - EasyCoexistence:: Meta 的 Cloud API 透過 Coexistence 運作，使用 Meta 發出給客戶自有 WhatsApp Business 帳戶的認證資料。號碼會在 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-hant/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 允許的一切：傳送及接收訊息、範本、媒體及互動訊息，Webhook 由 Meta 傳送。群組聊天不在 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-hant/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 覆寫，還是傳送會在沒有提示下停止？ - 對於 14 天無活動規則，您會如何處理，而且會否讀取 Meta 的中斷原因？ - 按功能數量作選擇。Coexistence 是 Meta 的機制，因此各處底層平台都相同。 - 因為服務商支援 WhatsApp，便假設它支援 Coexistence。大部分服務商仍未支援。 - 比較席位價格與按號碼價格時，沒有按自己的實際模式計算兩者總成本。 **為甚麼您在自己的名單中排首位？** 因為我們認為理由成立：此處公開入門價最低、不設席位、零加價並包括監察。所有數字都有來源，請自行查核。 **哪些服務商支援 Coexistence？** 遠少於一般支援 WhatsApp 的服務商。名單上的服務商都在自己的網站上明確說明支援；大部分 WhatsApp API 行業仍未提供此功能。 **服務商會改變 Coexistence 能做到的事情嗎？** 不會。這項功能屬於 Meta，因此各處限制都相同：相同的 4 項停用功能、相同的 14 天規則，以及不支援群組聊天。 **哪個選項最便宜？** 我們的公開入門價最便宜，而且號碼越多，差距越大，因為我們的按號碼收費會下降，而席位及計劃價格不會。 --- ## 最佳 WhatsApp Cloud API 供應商 https://easycoexistence.com/zh-hant/compare/best-whatsapp-cloud-api-providers 這裡每家供應商連接的都是同一個 Cloud API，因為它屬於 Meta，而且只有一個。不同之處在於收費方式，清楚分為三類：按訊息收費、按席位收費，或按已連接號碼收費。 ### 三種收費模式，真正需要選擇的是這個 由於底層 API 完全相同，功能清單看起來大同小異。帳單如何計算卻不一樣，並會隨業務增長決定您的支出。 - 按訊息收費：每則訊息均會產生費用，業務越成功，成本便按比例上升。 - 按席位收費：每位使用者均需付費，團隊越大成本越高，即使沒有登入也要付款。 - 按號碼收費：每個連接收費，號碼連接後費用便不再隨訊息量變動。 ### 按訊息收費的供應商 這是 CPaaS 類別。Twilio 公布每則入站及出站訊息 US$ 0.005，另加 Meta 的費用。Gupshup 公布標準費用為每則 US$ 0.001。Bird 報價為已包含 Meta 費用的綜合費率，因此加價確實存在，但無法與 Meta 公布的費率核對。Infobip 則按目的地國家由銷售團隊報價。四者都是具備能力的平台，但您的平台帳單都會隨訊息量變化。 ### 按席位收費的供應商 這是收件匣類別。SleekFlow、Wati 及 Respond.io 提供具備推廣活動和自動化功能的共享收件匣，按使用者及方案級別收費，部分更會按 WhatsApp 號碼另收附加費。如果您希望團隊全天候在同一個產品內工作，這是合適的選擇。如果團隊已有 CRM，這便不是合適選擇，因為無論是否有人開啟第二個收件匣，您都要付費。 ### 按號碼收費的供應商 這是基礎設施類別，也是規模最小的一類。EasyCoexistence 每個已連接號碼每月 US$ 9 起，隨號碼增加降至 US$ 1，不收取每則訊息費用，也不設席位。Dualhook 是另一家公布按號碼收費的專門供應商。這種模式適合已有系統、希望讓 WhatsApp 連接系統的企業，也適合持有大量客戶號碼的代理商，因為按號碼遞減的費率會逐步累積效益。 ### 三種模式在哪裡出現交叉 值得計算，不應靠估算，而計算很簡單。 - 按每則訊息 US$ 0.005 計算，按號碼收費 US$ 9 在每月約 1,800 則訊息以上更便宜。 - 按每則訊息 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-hant/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 個人檔案也會一併失效，而且沒有支援渠道可供申訴。若是您願意捨棄的個人號碼，這項取捨或許合理。若是企業用來回覆客戶的號碼，則不值得冒險。 ### 實際運行需要甚麼 除了風險之外，實際差異還有一項，通常在第二天便會遇到。 - 本機伺服器程序通常在電腦上執行，必須持續運作，助理才能正常工作。 - 需要掃描 QR 碼連接裝置，工作階段中斷時亦要重新掃描。 - 憑證會放在本機設定檔內，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-hant/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:: 每個已連接號碼收取固定費用。每月一萬則訊息與十則訊息的費用相同。業務越成功，每則訊息的平均平台成本越低，用量大時每個號碼的價格也會下降。 ### 誰持有 WhatsApp 帳戶 號碼及與 Meta 的關係存放在哪裏，決定任何一方能否輕易離開。 - Twilio:: 號碼透過 Twilio 的寄件者完成開通，訊息關係經由 Twilio 基礎設施運作，帳單關係亦由 Twilio 處理。 - EasyCoexistence:: 號碼保留在客戶自己的 Meta Business Portfolio 及 WhatsApp Business 帳戶內，由 Meta 直接向您收取對話費用。我們是負責連接的 Tech Provider，移除我們不會帶走號碼。 ### 訊息會傳送到哪裏 兩者都會將收到的訊息傳送至您控制的伺服器，差異在於傳送路徑及其上的環節。 - Twilio:: 收到的訊息會經 Twilio 抵達您的 Webhook，Twilio 會在處理每則訊息時收費。 - EasyCoexistence:: 我們會在 WhatsApp Business 帳戶上設定 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 有不同嗎？** 沒有。兩者的底層 Cloud API 都是 Meta 自己的。差異在於誰位於傳送路徑上、收取多少費用，以及誰向您收取 Meta 費用。 **之後可以移轉號碼嗎？** 可以。號碼會保留在您自己的 Business Portfolio 內，因此移除我們後，號碼仍會留在原來的位置。 --- ## EasyCoexistence 與 Gupshup https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-gupshup Gupshup 是按訊息收取公開費用的對話式訊息平台，另加 Meta 的對話費用。EasyCoexistence 按每個已連接號碼收取固定月費，不會在訊息賬單上加收費用，訊息量越大，差異越明顯。 ### 賬單的計算方式 一美仙的十分之一聽起來微不足道，但在大量使用時，它就是整段對話的成本。 - Gupshup:: 每則訊息收取 US$ 0.001 的標準費用，另加 Meta 的收費，訊息範本和工作階段訊息一律適用。每月 100,000 則訊息，未計 Meta 費用前，平台費已是 US$ 100。 - EasyCoexistence:: 每則訊息不收費。100,000 則訊息的費用與 10 則相同，因為費用按號碼而非流量計算。號碼越繁忙，我們攤分到每次對話的費用越低。 ### 產品的核心用途 兩者都能連接 WhatsApp，但服務的工作各不相同。 - Gupshup:: 這是一個對話式平台，提供機械人建立工具、推廣活動工具和多種渠道，針對需要大規模進行外展活動的企業。 - EasyCoexistence:: Coexistence 基礎設施。WhatsApp Business 應用程式繼續在手機上運作，Cloud API 在同一個號碼上運行，訊息事件會傳送至您現有的系統或 AI 代理。我們不要求您把團隊轉移到其他地方。 ### 對話資料存放在哪裏 這個問題決定了您的業務有多少部分會在別人的產品內運作。 - Gupshup:: 訊息會經過該平台，這也是機械人建立工具、推廣活動工具和分析功能得以運作的原因。如果您需要這些功能，這是合理的取捨。 - EasyCoexistence:: 訊息事件會由 Meta 直接經 Meta 自己的 Webhook 覆寫傳送至您的端點。我們從不查看對話內容，因此您離開時沒有資料需要匯出，傳送路徑上也沒有可供計量的內容。 ### 連接已經使用應用程式的號碼 這正是 Coexistence 存在的原因。 - Gupshup:: 他們公布的定價頁面沒有提及 Coexistence。這並不代表他們不支援，您應直接向他們提出這個問題。 - EasyCoexistence:: 這就是整個產品的用途。已經運行 WhatsApp Business 應用程式的號碼，可透過 Meta 自己的 Embedded Signup 連接，應用程式繼續運作，並在數分鐘內於同一個號碼上取得 Cloud API。 - 不要把 US$ 0.001 視為微不足道。決定前，先按一整年的實際訊息量計算。 - 不要為不會使用的推廣活動工具付費。平台費涵蓋整個產品，不論您是否使用。 - 不要假設任何供應商都支援 Coexistence。無論選擇誰，都要明確詢問。 **按訊息收費實際要多少？** 每月 100,000 則訊息時，Gupshup 公布的 US$ 0.001 會產生 US$ 100 平台費。我們一個號碼的費用在任何訊息量下都是 US$ 9。 **Gupshup 支援 Coexistence 嗎？** 他們的定價頁面沒有提及。Coexistence 正是我們全部的服務。 **使用您們的服務會失去推廣活動功能嗎？** 我們不是推廣活動工具，也不按這種方式定價。訊息會傳送至您自己的系統，因此推廣活動可在您現有的系統中進行。 **誰向 Meta 付款？** 由客戶直接使用自己的 WhatsApp Business 帳戶付款。我們從不在 Meta 收費上加價。 --- ## EasyCoexistence 與 Infobip 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-infobip Infobip 是面向企業的通訊平台，其 WhatsApp 價格按國家報價，並由銷售團隊安排。EasyCoexistence 公開價格，首 3 天免費，無需聯絡任何人即可連接號碼，這是面向不同買家的不同產品。 ### 每項產品適合誰 沒有哪項產品較差。它們面向不同客戶，而這幾乎決定其餘一切。 - Infobip:: 企業 CPaaS，提供全渠道路由、聯絡中心工具及全球電訊商關係，由客戶團隊向設有採購流程及承諾用量的機構銷售。 - EasyCoexistence:: 已經擁有 WhatsApp Business 號碼，並希望在今天下午將其連接至 Cloud API 的小型企業或代理商。註冊、連接，完成。無需聯絡任何人，因為沒有需要協商的事項。 ### 作出承諾前可查明甚麼 最實際的差異，也是人們最先感受到的差異。 - Infobip:: 價格按目的地國家報價，並與銷售團隊安排。這是企業 CPaaS 的常見做法，適合協商年度用量的買家。 - EasyCoexistence:: 完整價目表列於定價頁面，以您的貨幣顯示，並列出清晰的用量級別。您可在建立帳戶前計算費用，而首 3 天完全免費。 ### 由決定到號碼可用需時多久 對只有一個號碼並正面對實際問題的企業而言，這是最重要的比較。 - Infobip:: 企業啟用流程會提供專屬支援及設定協助，大型部署確實需要這些服務。 - EasyCoexistence:: 數分鐘。Meta 自家的 Embedded Signup 會選取 Business Portfolio、帳戶和號碼，WhatsApp Business 應用程式全程維持運作，監察亦會立即開始。 ### 連接中斷時會發生甚麼 每個 Coexistence 連接最終都會遇到不順的一天。不同之處在於誰會察覺。 - Infobip:: 企業支援渠道及客戶團隊。當背後有合約和指定聯絡人時，這是合適的模式。 - EasyCoexistence:: 我們持續監察連接，並讀取 Meta 自家的中斷原因，因此可分辨號碼因 14 天沒有活動而被停用，還是客戶確實已離開。警報會在客戶察覺前送達。 - 只按功能比較企業 CPaaS 與按號碼收費的工具。它們回答的是不同問題。 - 為一個號碼啟動採購流程。所花時間的成本，比工具一年的費用更高。 - 以為小量用量的報價會低於公開價格。這種情況並不常見。 **為甚麼 Infobip 不公開統一價格？** 其價格按目的地國家報價，適合協商用量的企業買家。我們公開價格，因為客戶希望今天就作出決定。 **大型企業使用 Infobip 會較好嗎？** 它們面向這類買家而設，具備全球電訊商覆蓋及客戶團隊。對於連接自有號碼的企業，我們是更快且價格更低的途徑。 **開始使用前需要聯絡任何人嗎？** 不需要。首個已連接號碼可免費試用 3 天，並透過 Meta 自家的 Embedded Signup 完成連接。 **誰會向我收取訊息費用？** Meta 會直接向您的 WhatsApp Business Account 收取。我們從不經手這張帳單。 --- ## EasyCoexistence 與 YCloud 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-ycloud YCloud 支援 Coexistence，並與我們一樣不在 Meta 的訊息費率上加價。差別在於您購買的是甚麼：他們的付費方案是按席位、頻道及 AI 額度收費的平台訂閱，而我們提供按已連接號碼定價的基礎設施。 ### 兩者做對了甚麼 值得直接說明，因為這可把比較範圍收窄至真正不同之處。 - YCloud:: 兩者均支援 Coexistence，並公開承諾不對 WhatsApp 訊息加價。在供應商最重要的兩項承諾上，他們都符合要求。 - EasyCoexistence:: 同樣是兩項承諾：透過 Meta 自己的流程提供 Coexistence，不在 Meta 訊息上加收費用。我們的差別在於其他所有部分。 ### 訂閱實際買到甚麼 這是真正的分歧，也決定哪一個對您較便宜。 - YCloud:: 一個平台。他們的付費方案由每月 US$ 39 起，按用戶席位、頻道及 AI 額度區分。若您希望團隊在他們的產品內工作，這種模式便合適。 - EasyCoexistence:: 基礎設施。每個已連接號碼每月 US$ 9 起，不用計算席位，沒有頻道級別，也沒有會用盡的額度。一個號碼的企業只需為一個號碼付費，擁有 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-hant/compare/easycoexistence-vs-sleekflow SleekFlow 是按使用者座位銷售的全渠道訊息平台，設有最低座位數，並按每個 WhatsApp 號碼收取附加費。EasyCoexistence 按已連接號碼收費，完全沒有座位概念，因此費用取決於您持有的號碼，而不是團隊人數。 ### 您實際支付的是甚麼 兩種定價模式回答不同問題，其中一種會根據您的組織架構收費。 - SleekFlow:: 共用收件匣及推廣訊息平台按不同方案級別，以使用者座位定價。當產品就是團隊每天工作的地方時，這種模式確實合理。 - EasyCoexistence:: 一個連接。計費單位是已連接號碼，而不是人員，因此新增同事不會產生費用，團隊人數增減也不會改變帳單。 ### 您的團隊在哪裏工作 定價模式背後的決定，也是最難逆轉的一項決定。 - SleekFlow:: 在 SleekFlow 內。這就是它的產品：把收件匣、自動化功能和推廣訊息集中於一處，對想要一站式工具的團隊確實有用。 - EasyCoexistence:: 在團隊原本工作的地方。訊息事件會透過 Meta 自有的 Webhook 覆寫，從 Meta 直接傳送至您的 CRM、服務台、內部工具或 AI 代理程式。沒有人需要學習新的收件匣，也不需要遷移任何資料。 ### 新增第二或第三個號碼 對擁有多個地點的企業很常見，而兩種模式在這裏的差異非常明顯。 - SleekFlow:: 額外 WhatsApp 號碼會在按座位計費的方案之外另行附加，因此第二個號碼代表訂閱之上又一項決定。 - EasyCoexistence:: 第二個號碼就只是第二個號碼，按公布費率收費，新增越多，費率越低。一個帳戶擁有 20 個號碼，不需要更改方案，也不需要進行任何對話。 ### 停止付款後會怎樣 任何保存您訊息的產品，都值得先問清楚這一點。 - SleekFlow:: 收件匣、歷史紀錄和自動化功能都存在平台內，這正是它們能運作的原因，也是離開時需要遷移的原因。 - EasyCoexistence:: 我們不會保存任何需要由您遷移的資料。訊息送達時便已傳送至您的系統，而號碼位於您自己的 Meta Business Portfolio，因此移除我們後，號碼仍會留在原來的位置。 - 比較按座位收費與按號碼收費時，沒有同時計算兩者。3 個座位和 1 個號碼，與 1 個座位和 3 個號碼，帳單可能完全不同。 - 為團隊不會開啟的收件匣付費。無論是否使用，座位都會產生費用。 - 為多地點企業計算費用時，忘記加入每個號碼的附加費。 **哪一個較便宜？** 我們較便宜，除非您特別需要收件匣。他們公布的定價按座位計算，設有最低座位數，並按每個 WhatsApp 號碼每月收取附加費。我們每個已連接號碼收費 US$ 9，隨號碼增加降至 US$ 1，完全不設座位。 **我會獲得共用收件匣嗎？** 不會，而您也不需要為此付費。訊息會送達您的系統，團隊原本就在那裏工作。 **多個地點怎樣處理？** 每個號碼按公布費率收費，新增越多，費率越低。不需要更改方案，也沒有需要協商的附加費。 **我的資料會被鎖定嗎？** 使用我們不會。訊息會從 Meta 直接傳送至您的端點，而號碼會留在您自己的 Business Portfolio。 --- ## EasyCoexistence 與 Bird 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-bird Bird 按已發送的每則 WhatsApp 訊息收費，並把 Meta 自己的費用併入報價。EasyCoexistence 按每個已連接號碼收取固定費用，從不出現在訊息帳單上，因此 Meta 收取的費用清晰可見且獨立計算。 ### 綜合費率隱藏了甚麼 這並不代表不誠實，而且對方在自己的頁面上已公開說明。不過，這仍會改變您可核對的內容。 - Bird:: 每則已發送訊息一個費率，當中已包含 Meta 的部分。對方頁面說明，Bird 會在處理期間收取發送費，並根據送達回條記錄 Meta 的部分。 - EasyCoexistence:: 兩張完全分開的帳單，互不混合。Meta 就其 WhatsApp Business 帳戶上的對話直接向客戶開立帳單，我們則就連接開立帳單。由於兩者從未合併，您可分別對照來源核對。 ### Meta 更改費率時會怎樣 Meta 會定期修訂對話收費，而兩種模式以不同方式反映這些變更。 - Bird:: 當基礎費率變動時，綜合費率也必須修訂，這代表您獲報的數字會改變。 - EasyCoexistence:: 我們這邊不會有任何變動。Meta 的更改會在 Meta 採用新費率的日期，按 Meta 自己的費率出現在客戶的 Meta 帳單上。我們收取的是連接費，與每則訊息的費用無關。 ### 每個產品圍繞甚麼而設 兩者都會發送 WhatsApp 訊息，但並非為相同用途而競爭。 - Bird:: 跨越電郵、SMS 及 WhatsApp 的營銷及客戶互動平台，為需要在多個渠道大規模執行活動的團隊而設。 - EasyCoexistence:: 為已運行 WhatsApp Business 應用程式的號碼提供 Coexistence 基礎設施。應用程式繼續運作，Cloud API 同時運行，而事件會傳送至您自己的系統。一個號碼，一項用途，妥善完成。 ### 對話屬於誰 這是兩種收費模式背後的結構性問題。 - Bird:: 訊息會經由平台處理及收費，這正是平台能夠提供活動及分析工具的原因。 - EasyCoexistence:: 訊息事件會透過 Meta 自己的 override，由 Meta 直接傳送至您的端點。事件不會經過我們，我們也不會儲存，因此我們沒有按每則訊息收費的理由。 - 把綜合費率與 Meta 公布的費率比較，彷彿兩者是同一個數字。其實其中一個已包含另一個。 - 以為合併價格代表沒有加價。實際上，這代表加價沒有逐項列明。 - 為一個號碼及一個 Webhook 的用途，選擇營銷活動平台。 **Bird 的收費是否不誠實？** 不是。對方已清楚說明 Meta 的費用已包含在內。重點是，合併費率無法與 Meta 自己公布的費率直接核對。 **使用您的服務時，誰會就訊息向我開立帳單？** Meta 會直接向您開立帳單，使用的是您自己的 WhatsApp Business 帳戶。我們從不對 Meta 的費用加價或轉售。 **如果 Meta 提高費率，會怎樣？** 這會按 Meta 的費率出現在您的 Meta 帳單上。我們的費用不受影響，因為它與訊息無關。 **Bird 支援 Coexistence 嗎？** 對方的 WhatsApp 收費頁面沒有提及這項功能，而這正是我們全部的工作。 --- ## EasyCoexistence 與 Zenvia 比較 https://easycoexistence.com/zh-hant/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 支付。我們不會在 Meta 收費上加價。 --- ## EasyCoexistence 與 8x8 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-8x8 8x8 是企業通訊服務供應商，其 Coexistence 文件在同類資料中相當清晰，因此經常獲得引用。EasyCoexistence 為閱讀這些文件後希望立即連接號碼的企業而設，毋須經歷企業銷售流程。 ### 兩者的共通之處 兩者共享相同的技術基礎，在說明差異前，先說明這一點是值得的。 - 8x8:: 其 Coexistence 文件準確，而且對限制的說明異常清晰，包括連接號碼後哪些 WhatsApp 功能會被停用。這確實是一份實用參考。 - EasyCoexistence:: 這些限制來自 Meta，而不是任何服務供應商，因此兩者相同。我們也會說明這些限制，並以應對限制為核心建立產品，包括 14 天非活躍規則、同步時間窗，以及會失效的功能。 ### 由閱讀到完成連接 文件未能解決的落差。 - 8x8:: 這是一項企業 CPaaS 服務，設有客戶團隊、聯絡中心產品及電訊商服務，面向需要採購流程的機構銷售。大型部署所需的支援會在入門過程中提供。 - EasyCoexistence:: 註冊並連接即可。Meta 自家的 Embedded Signup 會選取 Business Portfolio、帳戶及號碼，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-hant/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-hant/docs/coexistence-error-number-already-registered 當號碼已註冊在某處，而該註冊會阻止目前嘗試的步驟時，Meta 的註冊彈出視窗就會顯示此訊息。這個地方可能是個人版 WhatsApp、WhatsApp Business API 帳戶，或另一個平台上的帳戶。您必須先將號碼從該帳戶解除連接。解除後，Meta 表示號碼可能需要幾分鐘才能再次使用。 ### Meta 的文件如何解釋這則訊息？ Meta 的 Embedded Signup 錯誤參考將此訊息列為「This number is registered to an existing WhatsApp account. To use this number, disconnect it from the existing account. Then, return to this page and re-enter the number.」，並補充號碼最多可能需要 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 表示號碼最多可能需要三分鐘才可使用。 - 為應用程式號碼執行一般的新號碼註冊。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-hant/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 帳戶的訊息，輕按「連接」，然後在應用程式內完成驗證步驟。 因此，索取驗證碼持續失敗，是提示您檢查彈出視窗走的是哪一條途徑。如果從未出現提供連接現有 WhatsApp Business 應用程式帳戶的畫面，代表流程把該號碼當作新註冊處理，並要求 SMS 或語音驗證碼，而這正是這些限制生效的地方。 ### 如何重試而不令情況惡化？ 完整等候訊息要求的 1 小時，期間不要再索取另一個驗證碼。Meta 表示系統會限制在一段時間內可索取驗證碼的次數，因此在等候期間發出的請求只會對您不利。 1 小時過後，請關閉舊的彈出視窗，重新開始流程，而不是在一直開著的視窗中按重新發送。選擇連接現有 WhatsApp Business 應用程式帳戶的選項，讓存有該號碼的手機保持解鎖並放在身邊，驗證訊息一到就立即在應用程式內完成驗證。 如果是多次輸入錯誤驗證碼，Meta 的指引有所不同：系統只容許有限次數的驗證嘗試，並建議等候約 12 小時才重試。 - 在這 1 小時內重複按重新發送。Meta 會限制一段時間內可索取驗證碼的次數。 - 以為服務中斷是永久性的而更換號碼。訊息所指的只是暫時的等候。 - 為應用程式號碼進行新號碼註冊。Coexistence 是透過 WhatsApp Business 應用程式驗證，而不是重新以 SMS 註冊。 **等候超過 1 小時會有幫助嗎？** 1 小時是訊息所列明的時間。等候更久並無壞處，但在這 1 小時內索取驗證碼就有影響。 **我的服務供應商可以重設限制嗎？** 不可以。驗證碼限制由 Meta 套用在該號碼上，沒有任何供應商可以解除。 **WhatsApp Business 應用程式會受影響嗎？** 不會。應用程式在手機上仍然正常運作。這項拒絕只與瀏覽器中的註冊步驟有關。 **我如何知道是否真的是服務中斷？** 請查看 Meta 的 WhatsApp Business Platform 狀態頁面。如果沒有顯示任何事故，請把這則訊息視為驗證碼索取限制。 --- ## Coexistence QR 碼掃描在 WhatsApp Business 應用程式失敗 https://easycoexistence.com/zh-hant/docs/coexistence-error-qr-code-pairing-failed Coexistence 註冊時代碼掃描失敗，原因通常出在手機上：WhatsApp Business 應用程式版本過舊、用錯應用程式或裝置掃描，或掃描後出現的提示沒有回應。解決方法是更新應用程式，在持有該號碼的手機上用 WhatsApp Business 應用程式掃描，並完成每一項提示。 ### 手機上應該發生甚麼事？ Meta 的文件將手機端分為四個動作。商戶在 WhatsApp Business 應用程式內收到 Facebook Business 官方帳戶發出的訊息，並點選 Connect。接着點選 Connect to the Business Platform。然後點選 Confirm，並在此選擇是否分享聊天記錄。最後完成驗證碼步驟，返回瀏覽器完成流程。 瀏覽器顯示的代碼，用來啟動應用程式內的這段對話。因此，若掃描後毫無反應，或手機一掃描就顯示錯誤，就代表其中一個動作無法開始。在瀏覽器內之前的步驟，已經順利完成。 ### 為何掃描會失敗？ 有四個原因值得按以下順序檢查。 應用程式版本過舊。Meta 要求 WhatsApp Business 應用程式為 2.24.17 或以上版本，並設有 Embedded Signup 錯誤 4563015，內容就是要求將應用程式更新至最新版本。 用錯應用程式掃描。代碼必須由主要手機上持有該號碼的 WhatsApp Business 應用程式處理。一般 WhatsApp、手機的相機應用程式，或 WhatsApp Web、桌面版等已連結的裝置，都不相同。 提示沒有完成。掃描只是開啟這個步驟，點選 Connect、Connect to the Business Platform 和 Confirm 才會讓流程繼續。 彈出視窗被關閉。瀏覽器視窗一旦消失，手機正在完成的流程也隨之消失。 ### 如何乾淨地重試？ 先從應用程式商店更新 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-hant/docs/coexistence-error-inaccessible-business-portfolio 如果號碼已連結到另一個 Meta Business Portfolio，而不是您在註冊彈出視窗中選取的那一個，Meta 就會拒絕，並顯示該號碼與您所選的企業沒有關聯。您必須在另一個 Business Portfolio 內解除號碼的連結，這需要該處的管理員協助；或者改為在那個 Business Portfolio 內執行註冊流程。 ### 出現這種情況時，Meta 會顯示什麼？ Meta 的 Embedded Signup 錯誤參考列出代碼 3441041：「The phone number you have entered is not associated with the business you selected. To continue, you need to unlink this phone number from that business or enter a different number.」 所謂您選取的企業，是指彈出視窗第一個畫面中選擇的 Business Portfolio。這則訊息表示 Meta 已把該號碼與另一個 Business Portfolio 關聯。這個連結可能來自較早的設定：曾經連接過該號碼的代理商、前員工的 Business Manager，或是為了廣告而建立的舊 WhatsApp 帳戶。今天執行流程的人往往完全不知道它存在。 ### 如何從另一個 Business Portfolio 解除號碼的連結？ Meta 文件記載的解決方法分為兩部分，都要在目前持有該號碼的 Business Portfolio 內進行。 第一，移除與該號碼連結的 WhatsApp 帳戶：Meta Business Suite，設定，帳戶，WhatsApp 帳戶，移除帳戶。第二，在 WhatsApp Manager 的「電話號碼」分頁中刪除該電話號碼本身。 兩個步驟都在該 Business Portfolio 內進行，所以需要擁有管理員存取權的人。Meta 本來就要求具備管理員級別的權限，才能在 Business Portfolio 內建立 WhatsApp Business 帳戶。號碼釋出後，請重新執行註冊，並選取您實際控制的 Business Portfolio。 ### 如果沒有人能進入舊的 Business Portfolio，怎麼辦？ 那麼實際可行的選擇只剩兩個。 首先是重新取得存取權。建立該 Business Portfolio 的人，或任何仍在其中的管理員，可以把現任人員加為管理員。如果是由代理商持有的 Business Portfolio，就要請代理商授予存取權，或由他們自行解除連結。 另一個做法是，在恢復存取權後，直接在那個舊的 Business Portfolio 內執行流程，而不是把號碼移出來。Coexistence 會把轉換後的帳戶保留在客戶自己的 Business Portfolio 內，所以流程在哪個 Business Portfolio 內執行，號碼之後就會留在哪裡。請選擇一年後企業仍然掌控的那一個。 - 建立全新的 Business Portfolio 再重試。號碼仍連結在舊的那一個，同樣的拒絕會再次出現。 - 刪除 WhatsApp Business 應用程式帳戶來切斷連結。連結由 Meta 一方持有，位於另一個 Business Portfolio 內。 - 把號碼留在企業無法控制的 Business Portfolio 內。誰管理它，誰就控制這個連接。 **Meta 支援團隊可以代我移動號碼嗎？** Meta 文件記載的 3441041 修復方法，是由有權存取另一個 Business Portfolio 的人在其中解除連結。Meta 沒有說明會代您移動號碼。 **如何找出哪個 Business Portfolio 持有該號碼？** Meta 的訊息不會指明。請檢查企業內任何人用過的所有 Business Portfolio，包括代理商代為建立的。 **解除連結會影響 WhatsApp Business 應用程式嗎？** 這些步驟是在 Meta Business Suite 和 WhatsApp Manager 中，把 WhatsApp 帳戶和號碼從該 Business Portfolio 移除，並不是在手機應用程式內進行。 **這和號碼已連接到其他供應商是同一回事嗎？** 不是。那是號碼連接到另一個合作夥伴的應用程式，而這個情況是號碼屬於另一個 Business Portfolio。 --- ## 沒有顯示「連接現有 WhatsApp Business 應用程式」選項 https://easycoexistence.com/zh-hant/docs/coexistence-error-option-not-showing 只有當啟動 Meta Embedded Signup 的平台在程式碼中啟用了該設定，才會出現連接現有 WhatsApp Business 應用程式帳戶的選項。沒有這項設定，彈出視窗會顯示標準的帳戶選擇畫面，並把該號碼視為新註冊。企業本身無法開啟此選項，必須由平台啟用。 ### 誰控制這個選項會否出現？ 啟動彈出視窗的平台。Meta 的文件指示合作夥伴在啟動 Embedded Signup 時，加入設為 whatsapp_business_app_onboarding 的 featureType 屬性。Meta 也提供檢查方法：如果帳戶選擇畫面已被「連接現有 WhatsApp Business 帳戶」的畫面取代，即表示該功能已啟用。 因此，當企業看到的是一般畫面，也就是選擇或建立 WhatsApp Business 帳戶，再輸入要註冊的號碼，就代表彈出視窗在啟動時沒有這項設定。企業自己的 Meta 設定無法改變這一點。企業只能改用已啟用此功能的平台所提供的註冊連結。 ### 為何有些平台不提供此選項？ Meta 列出了平台方在啟用前必須符合的要求。平台必須已是 Solution Partner 或 Tech Provider，必須懂得使用 Cloud API，必須有能接收並處理 Webhook 的 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-hant/docs/coexistence-error-business-app-outdated Coexistence 要求持有該號碼的手機安裝 2.24.17 或以上版本的 WhatsApp Business 應用程式。版本低於此要求時，Meta 的註冊彈出視窗會拒絕該號碼，並提示將應用程式更新至最新版本。從應用程式商店更新後，由頭重新執行流程即可解決。 ### 訊息內容是什麼？ Meta 的 Embedded Signup 錯誤參考列出代碼 4563015，訊息為「Update your WhatsApp Business App to the latest version to use this phone number」，解決方法正是如此：將應用程式更新至最新版本。 背後的要求載於 Meta 的 Coexistence 接入文件：企業客戶必須使用 2.24.17 或以上版本的 WhatsApp Business 應用程式。訊息要求的是最新版本，而非最低版本，更新至最新可用版本即同時符合兩者。 ### 需要更新哪部裝置？ 主要手機，即在 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-hant/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 會向前一個平台傳送 account_update Webhook，其中包含 PARTNER_REMOVED 事件，舊供應商就是這樣得知的。與該供應商之間的任何訂閱，則是企業與對方之間的另一回事。 ### 斷開之後會怎樣？ 請等待。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-hant/docs/coexistence-error-authorization-code-expired Meta 的 Embedded Signup 完成後，會向啟動流程的平台交出一個短效代碼，平台必須在 30 秒內將它兌換成存取權杖。若兌換得太遲，或使用了先前嘗試留下的代碼，Meta 就會回覆授權碼已過期。重新執行流程即可取得新代碼。 ### 過期的是哪一個代碼？ 商家完成 Embedded Signup 後，Meta 會將資產 ID 和一個可兌換權杖的代碼返回給開啟彈出視窗的瀏覽器視窗。平台再將該代碼傳送到自己的伺服器，由伺服器以應用程式 ID 和應用程式密鑰呼叫 Meta 的 oauth access_token 端點，把它兌換成商家權杖。 Meta 的實作指南對時限說得很清楚：可兌換權杖的代碼存活時間為 30 秒，因此平台必須在它過期前完成兌換。超過這個時間才嘗試兌換，請求會被拒絕，而「此授權碼已過期」就是這次拒絕的顯示方式。商家慢慢完成彈出視窗並沒有做錯任何事；計時是從代碼返回的一刻開始。 ### 為甚麼彈出視窗拖延完成或重複執行後會出現？ 有幾種情況會令兌換超出時限。 流程完成時，瀏覽器分頁留在背景，或手提電腦進入休眠，代碼在發出很久之後才到達平台的伺服器。平台的伺服器把兌換排在其他工作之後，沒有立即處理。又或者使用者開啟了兩次流程並且都完成了，而平台在第二個視窗完成後，才去兌換第一個視窗的代碼。 測試時還有第四種：從瀏覽器主控台複製代碼，再用 cURL 或 Postman 手動兌換。Meta 的指南正正警告過這一點，並建議在開始前先備妥兌換請求。 ### 如何完成連接？ 在單一視窗內從頭再執行一次流程，並讓平台的頁面保持在前景直至完成。每次完成都會返回新代碼，平台只需盡快兌換這個代碼即可。 如果是 Coexistence 號碼，更要盡快處理。商家完成流程時，Meta 會轉換 WhatsApp Business 帳戶；平台接入客戶後有 24 小時同步訊息歷史記錄，過了這段時間，商家就必須先解除接入，再重新完成流程。 在平台一方，根本的解決辦法是代碼一到達，就先在伺服器上兌換，然後才進行任何其他接入步驟。 - 用同一個代碼重試權杖兌換。它在 30 秒後已經過期，不會復原。 - 同時在兩個視窗執行註冊。只有正在兌換的那次嘗試所產生的代碼才有效。 - 在瀏覽器內兌換代碼。Meta 要求以應用程式密鑰，透過伺服器對伺服器的請求進行兌換。 **商家到底有沒有連接好號碼？** 商家已完成 Meta 的流程，但平台未能把代碼變成可用的權杖，所以暫時還不能對該號碼執行操作。重新執行流程就會得到新代碼。 **代碼的有效時間可以延長嗎？** 不可以。30 秒的存活時間由 Meta 設定，沒有任何平台可以延長。 **WhatsApp Business 應用程式會受影響嗎？** 不會。問題處理期間，應用程式仍可在手機上正常使用。 **這和已過期的存取權杖是同一回事嗎？** 不是。這裡指的是短效的註冊代碼。運作中連接的存取權杖過期，會返回錯誤 190。 --- ## 「Your app is missing required Graph API permissions for Cloud API companion pairing」 https://easycoexistence.com/zh-hant/docs/coexistence-error-companion-pairing-permission 此訊息表示啟動註冊流程的平台，缺少 Meta 要求的 WhatsApp 權限，或權限未達 Meta 要求的存取層級，因而無法將 WhatsApp Business 應用程式號碼連接至 Cloud API。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.」Meta 的公開錯誤參考文件並未列出這段確切字句，但其中每個部分都對應到 Meta 有記載的內容。 「Your app」指的是執行註冊流程的平台所使用的 Meta 應用程式，而不是手機上的 WhatsApp Business 應用程式。Meta 沒有公開定義 companion pairing；依上下文理解，它指的是 Cloud API 加入一個仍登記在 WhatsApp Business 應用程式內的號碼，也就是 Coexistence 的運作方式。至於「advanced」WhatsApp Business 權限，指的是進階存取權限，即 Meta 透過 App Review 授予的層級。 ### 涉及哪些權限？ Meta 的權限文件列出 WhatsApp 整合一般都需要的兩項權限。whatsapp_business_management 涵蓋帳戶中繼資料、訊息範本、電話號碼、分析資料與帳戶 Webhook。whatsapp_business_messaging 涵蓋傳送訊息，以及接收訊息與狀態 Webhook。 對於由客戶使用其應用程式的合作夥伴，Meta 要求應用程式所需的每項權限都須通過 App Review 並取得進階存取權限。Meta 直接說明了後果：若某項權限沒有進階存取權限，客戶就無法透過 Embedded Signup 將該權限授予應用程式。在沒有進階存取權限的情況下，以 whatsapp_business_management 對應用程式並非擁有者的帳戶發出呼叫，會回傳錯誤 200。 平台可以使用 Meta 的 debug_token 端點檢查存取權杖，確認企業實際授予了哪些權限，已授予的權限會列在 scopes 之下。 ### 企業可以怎樣做？ 企業自身能做的很少，也不應嘗試更改 Meta 設定來消除這個錯誤。問題出在平台：平台必須是 Tech Provider 或 Solution Partner，Meta 將此列為接入 WhatsApp Business 應用程式用戶的要求，而且平台須為相關 WhatsApp 權限取得已獲批的進階存取權限。 企業可以做的是將確切的訊息回報給平台，待平台確認已取得存取權限後再重試，或改用已具備該資格的平台。在此之前，於同一平台重複同一流程只會得到相同結果，也不會影響手機上的 WhatsApp Business 應用程式。 - 在企業自己的 Meta 設定中授予更多權限。缺少的存取權限屬於平台的應用程式。 - 在開發者應用程式上自行架設工具，卻沒有通過 App Review。沒有進階存取權限，企業就無法授予所需的權限。 - 在同一平台反覆重試。只有該平台的存取權限改變，結果才會改變。 **我的 WhatsApp Business 應用程式出了問題嗎？** 沒有。這則訊息指的是平台的 Meta 應用程式，不是您手機上的應用程式，後者會繼續正常運作。 **我可以自行授予這項權限嗎？** 只有平台已取得進階存取權限的權限，才會顯示讓您授予。缺少的存取權限必須先為平台獲批。 **平台如何取得進階存取權限？** 作為由客戶使用其應用程式的合作夥伴，須為應用程式所需的每項權限，通過 Meta App Review。 **企業需要通過 App Review 嗎？** 不需要。Meta 指出，直接的開發者若只存取自己的企業資料，既不需要 App Review，也不需要進階存取權限。 --- ## WhatsApp 錯誤 0：無法驗證應用程式使用者 https://easycoexistence.com/zh-hant/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.」Meta 列出的可能原因全部與存取權杖有關：權杖已過期、已失效，或授予權杖的人更改了設定，阻止所有應用程式存取其資料。 清單中沒有任何一項涉及電話號碼、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-hant/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 而言，兩項權限已涵蓋幾乎所有情況。whatsapp_business_management 用於帳戶中繼資料、訊息範本、電話號碼清單、分析資料和帳戶 Webhook。whatsapp_business_messaging 用於傳送任何訊息，以及接收訊息和狀態 Webhook。只持有其中一項的權杖，在需要另一項的呼叫上會失敗。 ### 為什麼合作夥伴的應用程式會遇到錯誤 3，直接開發者卻不會？ 因為替其他企業提供服務的合作夥伴，多了一道關卡。 Meta 的權限指南指出，若合作夥伴的客戶透過其應用程式存取自己的資料，該應用程式必須通過 App Review，並為所需的每項權限取得進階存取權限（Advanced access）。只處理自家企業資料的直接開發者，則不需要 App Review 或進階存取權限。 因此，同一段程式碼可以在開發者自己的帳戶上順利運作，卻在客戶的帳戶上失敗。出現這種情況時，要問的不是權杖缺少哪項權限，而是應用程式是否已獲批准，可對不屬於自己的資產使用該權限。 - 以相同範圍產生新權杖。權限相同的新權杖，會在同一處失敗。 - 在應用程式設定中檢查權限名稱，而不是檢查權杖本身。重點是權杖實際獲授予什麼。 - 只用自己的帳戶測試。合作夥伴的應用程式必須先取得進階存取權限，客戶帳戶才會接受呼叫。 **錯誤 3 是我的電話號碼出了問題嗎？** 不是。它關乎應用程式權杖獲允許執行的操作。請求被拒絕之前，系統不會檢查號碼。 **錯誤 3 與錯誤 10 有什麼分別？** 代碼 3 是能力或權限問題。代碼 10 表示權限未獲授予或已被移除。兩者都可透過檢查權杖範圍來解決。 **傳送訊息需要哪項權限？** whatsapp_business_messaging。Meta 的權限指南指出，傳送任何類型的訊息都需要這項權限。 **重試有幫助嗎？** 沒有。權杖的權限不會在兩次嘗試之間改變，所以結果相同。 --- ## WhatsApp 錯誤 4：應用程式已達 API 呼叫速率上限 https://easycoexistence.com/zh-hant/docs/whatsapp-error-4 錯誤代碼 4 表示應用程式已達到 API 呼叫速率上限。Meta 的說明是「應用程式已達到 API 呼叫速率上限」。它計算的是應用程式在滾動 1 小時內發出的呼叫次數，而不是某個號碼發送的訊息數量。請在應用程式控制台查看用量，等待一段時間，並減少應用程式呼叫 API 的頻率。 ### WhatsApp 錯誤代碼 4 是什麼意思？ 這表示您的應用程式在目前時段內發出了過多 API 呼叫，在次數回落之前，後續呼叫都會被拒絕。 Meta 把代碼 4 列為節流錯誤，詳細說明為「應用程式已達到 API 呼叫速率上限」。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 小時內的呼叫次數降到上限以下為止。這段期間內繼續呼叫，會令時間延長。 **在哪裡可以查看應用程式距離上限還有多遠？** 在應用程式控制台的「應用程式速率限制」區段，以及回應中返回的 X-App-Usage 標頭。 **錯誤 4 與錯誤 80007 一樣嗎？** 不一樣。WhatsApp Business 帳戶達到速率上限時，Meta 使用 80007，而錯誤 4 計算的是應用程式自身的呼叫。 --- ## WhatsApp 錯誤 10：權限未授予或已被移除 https://easycoexistence.com/zh-hant/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 專屬的成因，而且都不涉及權限範圍，所以很容易被忽略。 對於 WhatsApp Flows with Endpoint，Meta 指示要確保用來設定商家公開金鑰的號碼已列入允許清單。即使存取權杖具備所有權限，使用清單以外的號碼也會產生此錯誤代碼。 Meta 亦指出，若帳戶不符合所呼叫 API 的資格要求，就會收到此代碼。在這種情況下，更換存取權杖也無濟於事，因為關卡在於帳戶的資格，而不是憑證。 ### 如何修正錯誤 10？ 先從存取權杖偵錯工具入手，Meta 將它列為首要檢查項目。 如果 `scopes` 清單缺少端點所需的權限，請讓商家重新授予。對於合作夥伴應用程式，這也代表要確認該權限已取得 Advanced access，因為 Meta 的權限指南規定客戶帳戶必須具備。 如果權限範圍看來完整，就轉而檢查這兩個 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-hant/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。 因此字面上指向應用程式 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，則引導您檢查建立請求的程式碼，因為憑證根本沒有離開過您的系統。 - 去找應用程式 ID 的問題。訊息雖然寫著應用程式 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-hant/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-hant/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-hant/docs/whatsapp-error-131037 錯誤 131037 表示訊息是從顯示名稱尚未獲批准的 555 商業電話號碼發出。Meta 的說明是：「用於發送請求的 555 商業電話號碼沒有已批准的顯示名稱。」555 號碼必須先由 Meta 批准顯示名稱才能發送訊息，因此解決方法是更改顯示名稱。 ### 什麼是 555 商業電話號碼？ 這是 Meta 透過 Embedded Signup 向符合資格的企業提供的號碼。 Meta 的 Embedded Signup 概覽指出，商業客戶最多可申領兩個 555 號碼。這類號碼使用美國國家碼 +1 及 555 區號，會自動驗證，不能遷移到另一個 WhatsApp Business Account，也不能在 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 Account。 **名稱獲批准時我如何得知？** 您會收到 phone_number_name_update Webhook，其中 decision 為 APPROVED，而 name_status 亦會變為 APPROVED。 **如果顯示名稱被拒絕怎麼辦？** 請按照 Meta 的顯示名稱指引修改名稱，或透過開發人員支援提出申訴。 --- ## WhatsApp 錯誤 131057：Business 帳戶處於維護模式 https://easycoexistence.com/zh-hant/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 名不重複用戶發送訊息，以及品質評級為中等或以上。 ### 錯誤 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-hant/docs/whatsapp-error-132005 錯誤 132005 表示所發送範本的文字，在所用的翻譯版本中過長。Meta 的說明為「翻譯文字過長」。Meta 建議先在 WhatsApp Manager 確認該範本已有翻譯，再查看範本的狀態。範本內文最多 1,024 個字元，頁尾文字最多 60 個字元。 ### WhatsApp 錯誤 132005 是什麼意思？ 這表示範本發送失敗，原因是所發送語言版本的文字超出平台允許的長度。 Meta 將 132005 列入範本錯誤，詳細說明為「翻譯文字過長」。建議的處理方式是到 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-hant/docs/whatsapp-error-133000 錯誤 133000 表示先前取消註冊電話號碼的嘗試失敗，在問題解決前，該號碼無法註冊。Meta 的說明是「A previous deregistration attempt failed.」。Meta 給出的解決方法是先再次取消註冊該號碼，然後再註冊。這兩個端點在 72 小時的滾動時段內，每個號碼均限 10 次請求。 ### WhatsApp 錯誤 133000 是什麼意思？ 這表示平台仍記錄着該號碼有一次未完成的取消註冊，因此不會在其上再註冊該號碼。 Meta 將 133000 列為 details 文字「A previous deregistration attempt failed」，並附上一行補救方法：註冊前先再次取消註冊該號碼。因此，這個錯誤通常出現在註冊呼叫上，但成因其實在較早的取消註冊呼叫。 取消註冊是向該電話號碼 ID 的取消註冊端點發出 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 應用程式，則不可使用取消註冊端點。 **嘗試 10 次後會怎樣？** API 會傳回 133016，並在隨後 72 小時內封鎖該號碼進行該操作。 **再次註冊時需要 PIN 嗎？** 需要。如果已啟用兩步驟驗證，註冊時須提供該號碼 6 位數字的兩步驟驗證 PIN。 --- ## WhatsApp 錯誤 133004：伺服器暫時無法使用 https://easycoexistence.com/zh-hant/docs/whatsapp-error-133004 錯誤 133004 表示處理該請求的伺服器暫時無法使用。Meta 的說明是「Server is temporarily unavailable.」，問題並非出在請求本身。Meta 建議先查看 WhatsApp Business Platform Status 頁面，並閱讀回應中的 details 值，然後延遲一段時間再重試。 ### WhatsApp 錯誤 133004 是什麼意思？ 這表示平台在當時無法處理該請求，因為有伺服器無法使用。 Meta 在 Cloud API 錯誤參考中列出 133004，details 文字為「Server is temporarily unavailable.」。關鍵在於「暫時」二字。存取權杖、號碼或訊息都沒有被拒絕，同一個請求在稍後可能便會成功。 它屬於 133 系列代碼，這一系列大多與註冊及取消註冊電話號碼有關，因此常在註冊呼叫時遇到。不過 Meta 並未將它限定於註冊，所以無論在哪裏出現，都應視為伺服器狀況。 ### 重試前應該檢查什麼？ 有兩項，都是 Meta 在處理建議中提到的。 第一，位於 metastatus.com 的 WhatsApp Business Platform Status 頁面。如果 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-hant/docs/whatsapp-error-133009 錯誤 133009 表示兩步驟驗證 PIN 的嘗試送到 Meta 的速度，超出 Meta 接受的範圍。Meta 的說明是「兩步驟驗證 PIN 輸入過快」。PIN 本身可能正確，也可能有誤。再次嘗試前，請先查看回應中的 details 值，並待其所示的等候時間過去後，才送出下一次嘗試。 ### WhatsApp 錯誤 133009 是什麼意思？ 意思是此號碼的 PIN 嘗試相隔太近，Meta 拒絕了最新一次嘗試，但並未判斷 PIN 是否正確。 Cloud API 參考文件為 133009 提供的 details 文字是「兩步驟驗證 PIN 輸入過快」，並只給出一項指示：再次嘗試前，請先查看回應中的 details 值。 這個代碼介乎兩個相鄰代碼之間。133005 表示 PIN 不正確，133008 表示該號碼的 PIN 猜測次數過多。133009 只與速度有關，因此當某個程序在短時間內連續送出 PIN 嘗試時就會出現，例如對註冊請求進行重試的迴圈。 ### 如何修正錯誤 133009？ 放慢速度，並且不要再猜。 下次嘗試前，請先查看 error_data 中的 details 值。Meta 的參考文件指 details 是最可能的錯誤原因，而對這個代碼而言，這是 Meta 要您首先檢查的項目。 然後確保下一次嘗試使用的是確實有人知道的 PIN。如果沒有人知道，Meta 的兩步驟驗證指南說明可在 WhatsApp Manager 中重設：開啟該電話號碼的設定，選擇「兩步驟驗證」，再按「變更 PIN」。設定一個已知的新 PIN，比連續猜測後落入 133008 並要等更久來得快。 ### PIN 會在哪裡用到？ 在為 Cloud API 註冊號碼時，以及其前後的少數帳戶操作中。 Meta 的兩步驟驗證指南指出，註冊電話號碼時，此設定需要六位數字的 PIN；啟用兩步驟驗證後，註冊請求亦以 PIN 為必填欄位。Meta 的電話號碼指南補充，變更 PIN 或從平台刪除號碼時，同樣需要 PIN。 由於很少用到，PIN 很容易被遺忘。請把它與企業的其他帳戶憑證一同保存，而不是只留在最初設定號碼的那個人手上。 - 在迴圈中立即重試註冊請求。快速連續的 PIN 嘗試，正是這個代碼所報告的情況。 - 每次重試都換一個 PIN 來猜。猜測次數過多會令錯誤由 133009 變成 133008。 - 忽略 details 值。Meta 明確指出，再次嘗試前應先查看它。 **錯誤 133009 是否代表我的 PIN 錯了？** 不一定。它只表示嘗試過於頻繁。PIN 不正確時，會以 133005 回報。 **遇到 133009 後應等候多久？** Meta 沒有公布固定時間。再次嘗試前，請先查看回應中的 details 值。 **可以透過 API 停用兩步驟驗證嗎？** 不可以。Meta 的兩步驟驗證指南指出，沒有可停用它的端點。您可以改為設定新的 PIN。 **忘記了 PIN，該如何重設？** 在 WhatsApp Manager 中開啟該電話號碼的設定，選擇「兩步驟驗證」，再按「變更 PIN」。 --- ## WhatsApp 錯誤 133015：號碼剛刪除，刪除尚未完成 https://easycoexistence.com/zh-hant/docs/whatsapp-error-133015 錯誤 133015 表示正在註冊的電話號碼剛被刪除，而該刪除程序尚未完成。Meta 的說明是：「您嘗試註冊的電話號碼剛被刪除，刪除程序尚未完成。」文件記載的解決方法，是等待 5 分鐘後再重新發送註冊請求。 ### WhatsApp 錯誤 133015 是什麼意思？ 這表示同一個號碼仍在刪除期間，卻收到了註冊請求。 Meta 的參考文件給出完整的詳細說明：「您嘗試註冊的電話號碼剛被刪除，刪除程序尚未完成。」解決方法同樣明確：等待 5 分鐘後再重試請求。 最常見的情況是轉移號碼。有人先從一個 WhatsApp Business 帳戶刪除號碼，隨即在另一個帳戶註冊，或者刪除後再重新新增以重頭開始，結果第二個步驟在第一個步驟於後台完成之前，已經送達 Meta。 ### 如何刪除商業電話號碼？ 只能在 WhatsApp Manager 中進行，而且只有 Business Portfolio 管理員可以操作。 Meta 的電話號碼指南指出，商業電話號碼無法透過 API 刪除。刪除須在 WhatsApp Manager 中完成；狀態為「已連接」的號碼，需要輸入兩步驟驗證 PIN 才能刪除；曾在過去 30 天內發送付費訊息的號碼，須在最後一則付費訊息發出 30 天後才能刪除。 刪除與取消註冊並不相同。Meta 的註冊指南說明，取消註冊只會令號碼無法再配合 Cloud API 使用，不會刪除號碼或其訊息記錄。錯誤 133015 專指刪除。 ### 轉移號碼時，如何避免錯誤 133015？ 把等待時間寫進操作程序，而不是等到出錯才發現。 刪除號碼後，請至少停頓 5 分鐘，才發出註冊呼叫。如果呼叫仍然返回 133015，請再等一會，不要立即重試。 要有耐性，原因在於註冊次數上限。Meta 允許每個號碼在 72 小時滾動期內，向註冊端點發送 10 次請求；超出後，API 會返回 133016，並在接下來 72 小時封鎖註冊。如果重試迴圈每隔幾秒就針對 133015 重發一次，可能在刪除完成之前，就已用盡這 10 次機會。 - 每隔幾秒就重試註冊呼叫。每次呼叫都會計入每 72 小時 10 次的上限。 - 混淆刪除與取消註冊。取消註冊不會刪除號碼，而這個代碼與刪除有關。 - 嘗試透過 API 刪除號碼。Meta 只支援在 WhatsApp Manager 中刪除。 **收到錯誤 133015 後應等待多久？** Meta 表示，應等待 5 分鐘後再重試註冊請求。 **可以透過 API 刪除商業電話號碼嗎？** 不可以。Meta 的電話號碼指南指出，只能在 WhatsApp Manager 中刪除。 **為什麼我完全無法刪除號碼？** Meta 會封鎖刪除曾在過去 30 天內發送付費訊息的號碼。您可在最後一則付費訊息發出 30 天後刪除。 **如果重試太頻密會怎樣？** 72 小時內發出 10 次註冊請求後，API 會返回 133016，並封鎖註冊 72 小時。 --- ## WhatsApp 錯誤 135000：請求參數出現未知錯誤 https://easycoexistence.com/zh-hant/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-hant/compare/easycoexistence-vs-z-api Z-API 是一款巴西的 WhatsApp API，按實例收費，以掃描 QR 碼連接號碼，方式與 WhatsApp Web 連結裝置相同。EasyCoexistence 透過 Coexistence 將號碼連接到 Meta 官方的 Cloud API，因此 WhatsApp Business 應用程式可繼續使用，而且連接方式完全不違反 WhatsApp 的條款。 ### 兩者如何接入 WhatsApp 本頁其餘內容都源自這項差異，所以先從這裏說起。 - Z-API:: 其文件指出，與 WhatsApp Web 一樣，連接時需要掃描 QR 碼或輸入電話號碼。其網站將官方 Cloud API 描述為另一條途徑，並將自己定位為市場上的替代方案。 - EasyCoexistence:: 使用 Meta 的 Cloud API，憑證由 Meta 發給企業自己的 WhatsApp Business Account，並透過 Meta 的 Embedded Signup 連接。號碼登記為 API 號碼，WhatsApp Business 應用程式仍可在同一部手機上繼續使用。 ### 每個號碼的費用 兩者都按號碼收費，所以這是少數單位一致、可直接比較的項目。 - Z-API:: Ultimate 方案每個實例每月 R$ 99,99；Partner 方案每個實例 R$ 89,99，最少 10 個實例，以上均為其網站公布的價格。試用期為 2 天。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9（1 至 5 個號碼），分 6 個級距，隨號碼增加降至每個 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 天規則），會即時發出警報。 - 將以 QR 碼連結的實例與 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。 **使用 EasyCoexistence 需要訊息範本審批嗎？** 只有在 24 小時時限以外主動開啟對話的訊息才需要，這是 Meta 對所有官方供應商的規定。在時限內的回覆屬於自由格式訊息。 **我可以將號碼從 Z-API 轉到 EasyCoexistence 嗎？** 可以。解除工作階段連結，繼續使用 WhatsApp Business 應用程式，然後透過 Embedded Signup 連接號碼。這需要應用程式版本 2.24.17 或以上，以及近期的真實使用紀錄。 --- ## EasyCoexistence 與 Blip 比較 https://easycoexistence.com/zh-hant/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:: 免費方案最多支援兩名客服人員，每月對話數量有限。付費方案沒有在頁面上定價，讀者會被引導去了解詳情，所以數字要經銷售洽談才知道。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9（1 至 5 個號碼），隨號碼增加降至每個 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 有公開價格嗎？** 只有免費方案，最多支援兩名客服人員，對話數量有限。付費方案沒有在價格頁上定價。 **哪一個比較便宜？** 我們的價格公開，對方沒有，所以可供您查證的是我們：每個已連接號碼每月 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-hant/compare/easycoexistence-vs-digisac Digisac 是巴西的多渠道客戶服務平台，按個別報價收費，每月 R$ 197 起，透過 Gupshup 和 360dialog 運行官方 WhatsApp API，並經由它們支援 Coexistence。EasyCoexistence 是 Meta Tech Provider，直接為您連接號碼，按每個號碼公開收費，中間沒有任何平台。 ### 價格如何釐定 一邊是報價單，一邊是價目表，這點決定了之後的一切。 - Digisac:: 沒有固定方案。其頁面指出起始價格為 R$ 197，會按客服人員數目、渠道、AI 模組等功能及整合項目而變，由銷售團隊整合成報價。 - EasyCoexistence:: 1 至 5 個號碼每個已連接號碼每月 US$ 9，分六個級別遞減，隨號碼增加降至每個 US$ 1。無須計算客服人員，也無須加購模組。首 3 天免費。 ### 誰夾在您與 Meta 之間 號碼背後的公司鏈，決定了出問題時誰能修復。 - Digisac:: 該平台透過 Gupshup 和 360dialog 運行 API，兩者都是 Meta 的合作夥伴。其 Coexistence 文章指出，須透過 360dialog 等官方供應商啟用，由 Digisac 協助客戶完成。 - EasyCoexistence:: 沒有任何一方。我們是獨立的 Meta Tech Provider，企業透過 Meta 自家的 Embedded Signup，以自己的 WhatsApp Business Account 註冊，Meta 的 Webhook 直接送到企業自己的系統。 ### 團隊在哪裏工作 服務平台與連接方式，改變的是工作日的不同部分。 - Digisac:: 這是一個共用的客戶服務平台，集中處理 WhatsApp、Instagram、Telegram、Messenger、電郵和網頁聊天，設有對話分派、內部聊天和銷售漏斗。團隊在平台內工作。 - EasyCoexistence:: 無須登入任何新工具。團隊繼續使用 WhatsApp Business 應用程式，自動化流程、CRM 或 AI 代理則透過 API 在同一個號碼上運作。 ### 號碼多久才能使用 小型企業往往單憑這一點作決定。 - Digisac:: 先要取得商業報價，然後與供應商啟用。其頁面把 CNPJ、Meta Business Manager 及遵守政策列為先決條件。 - EasyCoexistence:: 通常在兩分鐘內透過 Embedded Signup 完成：以 Facebook 登入，輸入號碼，在應用程式內掃描 QR code。號碼一連接，監察隨即開始。 - 把 Digisac 的起始價格與每個號碼的收費直接比較。其價格會隨客服人員、渠道和模組增加。 - 以為 Coexistence 是該平台的功能。它其實是 Meta 的功能，經由供應商在 Meta 一方啟用。 - 預算漏了 Meta 的收費。無論選哪一種，這些費用都由 Meta 收取。 **Digisac 支援 Coexistence 嗎？** 支援。其自家文章指出，須透過 360dialog 等官方供應商啟用，由 Digisac 協助整個過程。 **哪一個比較便宜？** 單一號碼的話，我們較便宜：每月 US$ 9，而對方起始價格為 R$ 197，並會隨客服人員、渠道和模組增加。我們的單價則隨號碼增加而下降。 **使用貴公司的服務，會失去共用收件箱嗎？** 我們不出售共用收件箱。團隊繼續使用 WhatsApp Business 應用程式，其他功能則在您選擇的工具中運行。 **誰向 Meta 付款？** 由企業直接以自己的 WhatsApp Business Account 支付。我們從不加價 Meta 的收費。 --- ## EasyCoexistence 與 Octadesk 比較 https://easycoexistence.com/zh-hant/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。一個月有 10,000 個對話，費用與清淡的月份相同。Meta 的訊息費用由 Meta 直接向您收取。 ### 兩者各是甚麼 兩者都讓號碼使用官方 API，分別在於其上建構的內容。 - Octadesk:: 一套客戶服務生態系統：聊天機械人、AI 代理、設有 SLA 和工單紀錄的客服台，以及 WhatsApp 群發功能，每個方案包含 1 個官方 WhatsApp API 號碼。 - EasyCoexistence:: 負責連接及其監察。號碼留在 WhatsApp Business 應用程式，API 同時在同一號碼上運作，訊息會送達企業已在使用的工具，包括透過我們的 MCP 伺服器連接的 AI 代理。 ### 新增第二個或第十個號碼 代理商和設有多間分店的企業，往往最先問這個問題。 - Octadesk:: 每個方案只列明包含 1 個官方 WhatsApp API 號碼。其定價頁面沒有公布額外號碼的價格。 - EasyCoexistence:: 每個帳戶的號碼數量不限，每個號碼按級距計價，號碼愈多單價愈低：6 個號碼起每個 US$ 7，隨號碼增加降至 US$ 1。 ### 手機是否仍可照常使用 這個問題決定小型團隊是否須要改變工作方式。 - Octadesk:: 其定價頁面沒有提及 Coexistence。請向對方確認，號碼接上其 API 後，是否仍可留在 WhatsApp Business 應用程式。 - EasyCoexistence:: 可以。我們只做 Coexistence：應用程式保留所有聊天記錄，約 6 個月的歷史紀錄可同步，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 與 Huggy 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-huggy Huggy 是巴西的全渠道客戶服務收件匣，按方案和已連接用戶數收費，WhatsApp 另按數量和類別收費。EasyCoexistence 就是 WhatsApp 連接本身：透過 Coexistence，在已使用 WhatsApp Business 應用程式的號碼上接入 Meta 的 Cloud API，每個已連接號碼收取一項公開定價的費用。 ### 每月帳單所為何事 Huggy 的帳單隨團隊增長，我們的只隨號碼增加。 - Huggy:: 方案包含 1 名已連接用戶，額外用戶另收費：Starter 每名 R$ 69,90；Intermediate（每月 R$ 579 起）每名 R$ 119,90；Custom（每月 R$ 989 起）每名 R$ 189,90。WhatsApp 另按數量和類別計費，實施服務為選購項目，收費 R$ 1.250。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9（1 至 5 個號碼），隨號碼增加降至每個 US$ 1，完全不計用戶數。首 3 天免費，Meta 的訊息費用直接向企業收取。 ### 兩者各是什麼 收件匣和連接，購買的原因不同。 - Huggy:: 服務收件匣，整合 WhatsApp、Instagram、Messenger、Telegram、電郵、SMS 和語音，附聊天機械人和報表。其頁面表示他們是啟用官方 API 的 Meta 官方合作夥伴。 - EasyCoexistence:: WhatsApp Business 應用程式號碼與 Meta 的 Cloud API 之間的連接，持續受到監察。訊息會透過 Meta 的 Webhook 或我們的 MCP 伺服器，送到企業現有使用的系統。 ### 團隊的工作方式會否改變 同意任何安排之前，老闆最關心的問題。 - Huggy:: 客服人員登入 Huggy 收件匣，各渠道的對話在其中分配和回覆。其定價頁面沒有說明是否支援與 WhatsApp Business 應用程式的 Coexistence。 - EasyCoexistence:: 沒有人需要搬遷。WhatsApp Business 應用程式繼續在同一個號碼上運作，聊天記錄保留，API 則並行運作，處理企業要自動化的工作。 ### 對話保存在哪裏 這個決定日後很難逆轉。 - Huggy:: 保存在他們的平台上，收件匣需要這樣做，才能向開啟對話的客服人員顯示內容。 - EasyCoexistence:: 不在我們這邊。我們從不儲存對話內容，Meta 可將收到的訊息直接傳送到企業自己的 Webhook。 - 計算 Huggy 費用時漏了 WhatsApp 一項。它與方案分開收費，按數量和類別計算。 - 只按現時的團隊人數估算。收件匣方案每增加一名用戶，就多一筆月費。 - 為了在一個號碼上取得 API 存取權而購買收件匣。這只需要連接。 **哪一個較便宜？** 對需要連接的企業來說，是我們。Huggy 的 Intermediate 方案每月 R$ 579 起，只含 1 名用戶，未計 WhatsApp；我們每個已連接號碼每月 US$ 9。 **Huggy 使用官方 API 嗎？** 其定價頁面表示他們是 Meta 官方合作夥伴，並啟用 Meta 的官方 API。 **Huggy 支援 Coexistence 嗎？** 其定價頁面沒有說明。請直接向他們查詢，不要只依賴本頁。 **你們有收件匣嗎？** 沒有。團隊繼續使用 WhatsApp Business 應用程式，這正是 Coexistence 的用途。 --- ## EasyCoexistence 與 Umbler Talk 比較 https://easycoexistence.com/zh-hant/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:: 一至五個已連接號碼，每個每月 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 可用兩個 WhatsApp 號碼，Impulso 最多三個，Escala 則稱為動態號碼上限。號碼增加，就要為每名客服升級至較高方案。 - EasyCoexistence:: 每個帳戶的號碼數目不設上限，每個按所屬級距計價，號碼愈多，單價愈低。第二十個號碼比第一個更便宜。 ### 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-hant/compare/easycoexistence-vs-whaticket Whaticket 是支援 WhatsApp 及其他渠道的多人協作收件匣，每月 US$ 49 起，最少 3 名使用者及 1 條 WhatsApp 線路，可用 QR 碼連接，或透過官方 API 配合 Coexistence 連接。EasyCoexistence 只提供官方連接：在 WhatsApp Business 應用程式所用的號碼上接入 Meta 的 Cloud API，每個號碼 US$ 9。 ### 兩者如何連接號碼 Whaticket 提供兩種連接 WhatsApp 的途徑，EasyCoexistence 只提供一種。 - Whaticket:: 可選擇 WhatsApp QR（像 WhatsApp Web 一樣掃描的工作階段），或配合 Coexistence 的 WhatsApp API。其官方網站提醒，使用 WhatsApp Business 大量發送訊息可能觸發封鎖，並建議改用 API 以降低風險。 - EasyCoexistence:: 只使用 Meta 的 Cloud API，透過 Meta 的 Embedded Signup 配合 Coexistence 連接，因此 WhatsApp Business 應用程式可繼續在同一號碼上使用。沒有 QR 工作階段選項，也就沒有非官方途徑可退而求其次。 ### 每月帳單包含甚麼 兩張帳單由不同的部分組成。 - Whaticket:: 基本方案每月 US$ 49，包含 3 名使用者及 1 條線路；每增加一條線路每月 US$ 20；專業方案為 US$ 109。透過 QR 連接發送推廣活動會消耗點數，1,000 則訊息起價 US$ 25；API 推廣活動則豁免。 - EasyCoexistence:: 1 至 5 個號碼，每個已連接號碼每月 US$ 9，隨號碼增加降至每個 US$ 1。沒有使用者收費，沒有點數。Meta 的訊息費用直接向企業收取，我們從不加價。首 3 天免費。 ### 兩者分別是甚麼產品 一個是客服人員工作的地方，另一個是底層的通道。 - Whaticket:: 多人協作收件匣，集中並自動化各個訊息渠道，附有推廣活動功能，讓團隊在其平台內回覆客戶。 - EasyCoexistence:: 連接加上全天候監察。團隊繼續使用 WhatsApp Business 應用程式，訊息會送到您自己的 Webhook，AI 代理則透過我們的 MCP 伺服器操作該號碼。 ### 第二個、第五個或第十個號碼的費用 代理商及多分店企業首先會計算這項開支。 - Whaticket:: 方案費用以外，每條額外線路 US$ 20，因此基本方案 5 條線路、3 名使用者，每月合共 US$ 129。 - EasyCoexistence:: 5 個號碼每月合共 US$ 45，而且每個號碼的費率會持續下降：由第 6 個起每個 US$ 7，隨號碼增加降至 US$ 1。 - 在業務號碼上使用 QR 連接。Whaticket 的官方網站提醒，在該連接上大量發送訊息可能觸發封鎖。 - 忘記訊息點數。透過 QR 連接發送的推廣活動，會在方案費用以外按每 1,000 則訊息另行收費。 - 以方案價格計算額外線路。每條額外線路每月要加 US$ 20。 **哪一個比較便宜？** 是，我們比較便宜。Whaticket 基本方案 1 條線路每月 US$ 49；在我們這裏 1 個已連接號碼是 US$ 9。5 個號碼時，是 US$ 129 對 US$ 45。 **Whaticket 支援 Coexistence 嗎？** 支援。其價格頁將配合 Coexistence 的 WhatsApp API 列為連接選項，與 QR 連接並列。 **QR 連接是官方的嗎？** 不是。它像 WhatsApp Web 一樣連結一個工作階段。Whaticket 的官方網站也建議改用 API，以降低被封鎖的風險。 **你們有像 Whaticket 那樣的收件匣嗎？** 沒有。團隊繼續使用 WhatsApp Business 應用程式，您要自動化的工作則在自己的工具中運行。 --- ## EasyCoexistence 與 Leadsales 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-leadsales Leadsales 是墨西哥的對話式 CRM，用於透過 WhatsApp、Facebook 和 Instagram 銷售。其 Basic 方案月費 US$ 97，以網頁版連接 WhatsApp，官方 API 則要由月費 US$ 133 的 Professional 方案起才提供。EasyCoexistence 透過 Coexistence 將號碼連接至 Meta 的 Cloud API，每個號碼 US$ 9。 ### 哪個方案才是官方連接 WhatsApp 在 Leadsales，連接方式視乎方案而定。在 EasyCoexistence，則沒有分別。 - Leadsales:: Basic 透過 Messenger 和網頁版連接 WhatsApp，並非 Business API。Professional 月費 US$ 133（或 MX$ 3,239.88），以及月費 US$ 247 的 Advanced，才使用官方 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-hant/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 應用程式繼續在同一個號碼上運作，並同步約六個月的對話記錄，同時 Cloud API 並行運作，負責自動化。 ### 費用是多少 目前只有一方的價格可以直接查閱，另一方需要洽談。 - Treble:: 沒有公開價格。首頁不顯示價格，價格頁面要求輸入密碼，所以金額要向他們的銷售團隊查詢。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9（1 至 5 個號碼），分六個級別遞減，號碼越多越便宜，最低每個 US$ 1。Meta 直接向企業收取訊息費用，我們不加價。 ### 兩款產品各是什麼 兩者都使用 Meta 的官方 API，但銷售的是不同的層面。 - Treble:: 這是一個用於自動化聊天流程、大量推廣活動和 AI 客戶服務的平台，內建 HubSpot 和 Salesforce 整合，並提供 API 以建立自訂連接。 - EasyCoexistence:: 我們提供連接本身，以及全天候 24/7 監察。Meta 會將 Webhook 直接傳送到您的系統，我們不會儲存對話內容，另有 MCP 伺服器讓 AI 代理可以用該號碼傳送訊息。 ### 號碼多久才能啟用 對小型企業來說，這往往是決定性的問題。 - Treble:: 須經銷售流程，因為方案和價格要先與他們的團隊議定，才開始啟用程序。 - EasyCoexistence:: 通常只需不到兩分鐘，透過 Meta 的 Embedded Signup 完成：以 Facebook 登入、輸入號碼，再在應用程式內掃描 QR 碼。要求是應用程式版本 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-hant/compare/easycoexistence-vs-botmaker Botmaker 是建基於 WhatsApp Business Platform 的拉丁美洲聊天機械人及客戶服務平台，每月 US$ 149 起可享 3,000 個對話，另須一次性支付 US$ 99 開設 WhatsApp 帳戶。它支援 Coexistence。EasyCoexistence 只提供 Coexistence 連接，每個已連接號碼每月 US$ 9，沒有對話套餐。 ### 每月帳單的收費對象 Botmaker 銷售對話，EasyCoexistence 銷售連接。 - Botmaker:: 標準方案 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-hant/compare/easycoexistence-vs-gallabox Gallabox 與 EasyCoexistence 解決的是不同的問題。Gallabox 是建基於官方 WhatsApp Business API 的團隊收件箱及自動化套件，按方案銷售，用戶數目固定。EasyCoexistence 則是連接本身：在與 WhatsApp Business 應用程式相同的號碼上使用 Meta 的 Cloud API，按號碼計價，沒有收件箱，也沒有席位。 ### 每月帳單支付的是甚麼 兩者的計價單位不同，而計價單位決定帳單如何增長。 - Gallabox:: 按月計價的方案，團隊人數固定。Basic 每月 ₹ 2,999，按季收費，供 3 位用戶使用，其頁面註明這是硬性上限，較大的團隊須升級至 Essential 或 Advanced。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9 起，隨號碼增加降至 US$ 1。沒有用戶數目，也沒有聯絡人數目，因此增聘人手或接待更多客戶，帳單都不會改變。 ### Coexistence 如何啟用 兩者都使用 Meta 的 Coexistence 功能，因此 WhatsApp Business 應用程式在手機上仍可繼續使用。但啟用的途徑不同。 - Gallabox:: 其文件指出 Coexistence 預設未啟用，開始前須聯絡 Gallabox 支援團隊，以便先啟用工作區。 - EasyCoexistence:: Coexistence 正是我們的產品。企業主約 2 分鐘內即可自助完成 Meta 的 Embedded Signup，條件是應用程式為 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 時，由您在自己的 WhatsApp Business 帳戶中直接向 Meta 支付，我們不加收任何費用。 --- ## EasyCoexistence 與 TimelinesAI 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-timelinesai TimelinesAI 是同步至 CRM 的共用 WhatsApp 收件匣，按席位收費，可透過 QR code、官方 WhatsApp Business API 或 Coexistence 連接號碼。EasyCoexistence 只透過 Meta 的 Cloud API 配合 Coexistence 連接號碼，按號碼收費，並把每則訊息傳送到您自己的系統，而不是收件匣。 ### 兩者如何連接號碼 連接方式決定號碼會暴露於哪些風險，所以先談這一點。 - TimelinesAI:: 每個方案均提供三種選項：QR code 連結（把號碼以已連結裝置的方式附加）、官方 WhatsApp Business API，或同時運行應用程式與 API 的 Coexistence。 - EasyCoexistence:: 只有一種方式：透過 Meta 自家的 Embedded Signup，以 Meta 的 Cloud API 配合 Coexistence 連接。我們不提供 QR code 連線選項，因此經我們連接的號碼，沒有一個依賴已連結裝置的連結保持運作。 ### 每月費用支付甚麼 按席位與按號碼收費，增長的原因各不相同。 - TimelinesAI:: Starter 每個席位每月 $35，按年結算則為 $28，Pro 每個席位 $49。他們的定價頁說明，每位連接 WhatsApp 帳戶的用戶都需要一個席位。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9 起，最多 5 個號碼，隨號碼增加降至 US$ 1。我們完全不計算人數，Meta 的訊息費用則直接向您收取。 ### 對話最終存放在哪裏 收件匣與連接把資料放在不同的地方。 - TimelinesAI:: 存放在他們的共用收件匣，再同步到您選擇的 CRM。收件匣就是產品本身，因此訊息會經過並顯示在他們的平台上。 - EasyCoexistence:: 直接傳送到您的端點。Meta 會把 Webhook 傳送到您指定的 URL，我們不會儲存任何對話，客戶的資料因此留在由您掌控的系統內。 ### 應該選擇哪一個 銷售團隊如果想在 CRM 內使用共用收件匣，要找的是收件匣，而 TimelinesAI 正是收件匣。 如果企業想以官方方式連接號碼，路徑上沒有任何 QR code 連線，也不由中間人儲存任何資料，要找的是連接服務。EasyCoexistence 就是這種連接服務，提供讀取 Meta 自身斷線原因的連接監察、供 AI 助手使用的 MCP 伺服器，以及不論團隊規模、每個號碼固定收費的方案。 - 因為速度較快而以 QR code 連結商業號碼。已連結裝置的連線並不屬於 Meta 的 Business Platform。 - 為由軟件而非真人回覆的號碼計算席位。 - 在同一個帳戶中混用 QR code 連結與 API 連接的號碼，卻沒有記錄哪個是哪個。 **EasyCoexistence 比 TimelinesAI 便宜嗎？** 就一個已連接號碼而言，是的。TimelinesAI Starter 每個席位每月 $35。EasyCoexistence 每個已連接號碼每月 US$ 9，而且不論多少人使用 WhatsApp Business 應用程式回覆，都不會額外收費。 **TimelinesAI 支援 Coexistence 嗎？** 支援。他們的定價頁列明，每個方案都提供 Coexistence、QR code 及官方 API。 **我可以用 QR code 透過 EasyCoexistence 連接號碼嗎？** 不可以。每個號碼都透過 Meta 的 Cloud API 配合 Coexistence 連接，絕不會以已連結裝置的方式連接。 **我仍然可以在手機上使用 WhatsApp 嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式在同一個號碼上繼續運作，而 API 同時在旁運行。 --- ## EasyCoexistence 與 Periskope 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-periskope Periskope 透過手機「連結裝置」畫面掃描 QR code 來連接 WhatsApp 號碼，其文件指明 WhatsApp API 號碼無法連結。EasyCoexistence 走相反的路線：號碼透過 Coexistence 在 Meta 的 Cloud API 登記，因此 WhatsApp Business 應用程式可繼續使用，而且連接方式是官方認可的。 ### 兩者如何接通 WhatsApp 本頁其餘所有差異，都源自連接方式。 - Periskope:: 您在手機上開啟 WhatsApp 設定，選擇「連結裝置」，再掃描 Periskope 顯示的 QR code。號碼會作為連結裝置接上，而其首頁宣稱這種做法不需要 Business API。 - EasyCoexistence:: Meta 的 Embedded Signup 會把號碼登記到 Cloud API，憑證由 Meta 發給您自己的 WhatsApp Business 帳戶。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 嗎？** 沒有。其文件指示透過「連結裝置」以 QR code 連接號碼，並指明 WhatsApp API 號碼無法連結。 **我可以透過 EasyCoexistence 使用群組嗎？** 不可以。群組聊天不在 Meta 的 Cloud API 範圍內，所有官方供應商都適用這項規則。 **我的應用程式還能繼續使用嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式在手機上繼續運作，而 Cloud API 在同一個號碼上運行。 --- ## EasyCoexistence 與 Wassenger 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-wassenger Wassenger 是團隊收件箱兼 WhatsApp API 平台，提供兩種連接器：QR 碼工作階段，以及 Meta 的 Cloud API（API 方面支援 Coexistence）。EasyCoexistence 只提供支援 Coexistence 的 Cloud API，沒有收件箱，每個已連接號碼每月 US$ 9 起計，而非按設有固定客服人員數目的方案收費。 ### 兩者如何連接號碼 Wassenger 自家的說明中心比較了其兩種連接器，是最清楚的起點。 - Wassenger:: QR 連接器，據說是透過工作節點服務建立基於工作階段的連接，需要手機保持在線，並受 WhatsApp 的反垃圾訊息偵測約束；另有經 Meta 驗證的 Cloud API 連接器。Coexistence 在 API 方面提供。 - EasyCoexistence:: 只有 Meta 的 Cloud API，透過 Meta 的 Embedded Signup 配合 Coexistence。產品內沒有工作節點，也沒有 QR 連接器，所以不會選錯。 ### 每月費用包含什麼 客服人員方案與按號碼收費，所依據的計費單位並不相同。 - 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 伺服器。 - 先用 QR 連接器測試，運作正常後卻把商業號碼留在上面。 - 比較 €39.90 的方案與按號碼收費時，沒有計算方案內包含的客服人員和收件箱。 - 在連接器之間轉移號碼，卻沒有先確認聊天記錄會否一併轉移。 **EasyCoexistence 比 Wassenger 便宜嗎？** 就連接而言，是的。Wassenger Professional 每月 €39.90，只含 1 個號碼。EasyCoexistence 每個已連接號碼每月 US$ 9，5 個號碼合共 US$ 45。 **Wassenger 支援 Coexistence 嗎？** 支援。Wassenger 設有 Coexistence 專頁和說明文章，介紹如何在同一個號碼上同時使用 WhatsApp Business 應用程式和其 API 平台。 **Wassenger 的 QR 連接器是官方的嗎？** Wassenger 形容它是基於工作階段，並受 WhatsApp 的反垃圾訊息偵測約束。經 Meta 驗證的是它的 Cloud API 連接器。 **使用 EasyCoexistence 需要伺服器嗎？** 您需要一個端點來接收 Webhook，或透過 MCP 伺服器連接 AI 助理。連接本身的代管已包含在內。 --- ## EasyCoexistence vs WANotifier https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-wanotifier WANotifier 是建基於官方 API 的 WhatsApp 推廣及通知平台，按方案和聯絡人級別定價，並設有每月訊息上限。EasyCoexistence 本身就是官方連接，支援 Coexistence，按已連接號碼定價，不設聯絡人或訊息上限。兩者都不加價轉嫁 Meta 的訊息費用，所以分別在於訂閱費用買到的是甚麼。 ### 每月費用買到的是甚麼 WANotifier 按受眾規模定價，EasyCoexistence 按號碼定價。 - WANotifier:: 在少於 1,000 個聯絡人的級別下，按月付費為 Essentials 每月 US$ 69、Advanced 每月 US$ 119、Premium 每月 US$ 199，每月發送上限分別為 4,000、8,000 和 12,000 則訊息。聯絡人名單愈大，級別愈高。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9 起（最多 5 個號碼），隨號碼增加降至 US$ 1。50,000 個聯絡人的名單，費用與 50 個聯絡人的名單相同。 ### Coexistence 如何配合 兩者都透過 Meta 的官方 API 連接，也都提供 Coexistence，因此 WhatsApp Business 應用程式可繼續留在手機上。 - WANotifier:: Coexistence 在每個方案中都列為功能之一，與推廣活動、聊天機械人、自動跟進序列和共用團隊收件匣並列。 - EasyCoexistence:: Coexistence 就是整個產品：約 2 分鐘即可自助完成 Embedded Signup、持續監察連接狀況，並根據 Meta 自身的中斷原因發出警報，包括 14 天應用程式活動規則。 ### 訊息流向哪裏 推廣工具會替您處理訊息，連接則是把訊息交給您。 - WANotifier:: 進入他們的控制台、收件匣和自動化建立工具；Advanced 和 Premium 提供 REST API 和 Webhook，用於整合。 - EasyCoexistence:: 每個號碼的訊息都直接送到您的端點，因為 Meta 會把 Webhook 發送到您指定的 URL。我們這邊不儲存任何內容，MCP 伺服器則讓 Claude、ChatGPT 或 Cursor 操作該號碼。 ### 該選哪一個 想在同一個控制台內使用廣播、自動跟進序列和聊天機械人建立工具的人，買的是推廣工具，與連接是不同的產品。 已經有軟件，或正在開發軟件的人，需要的是以官方方式連接號碼並保持連接。那就是 EasyCoexistence，費用不會隨聯絡人或發送量改變，而 Meta 自身的訊息費用在兩種情況下都直接記在您的帳戶。 - 只按價錢選擇方案，沒有核對隨附的每月訊息上限。 - 讓聯絡人名單在月內超越級別界線，卻沒有預留升級的預算。 - 以為 0% 加價就代表沒有平台費用。訂閱費用和 Meta 費用兩者都要支付。 **EasyCoexistence 比 WANotifier 便宜嗎？** 是，就連接而言是的。WANotifier Essentials 在最小聯絡人級別下每月 US$ 69。EasyCoexistence 每個已連接號碼每月 US$ 9，不設聯絡人或訊息限制。 **WANotifier 支援 Coexistence 嗎？** 支援。他們的定價頁面在每個方案都列出 WhatsApp Coexistence。 **兩者都不加價轉嫁 Meta 費用嗎？** 是。WANotifier 聲明 0% 加價，而使用 EasyCoexistence 時，Meta 直接向您自己的帳戶收費。 **我可以用 EasyCoexistence 發送推廣活動嗎？** 您可以從自己的系統或 AI 助理，透過 Cloud API 發送已獲批的訊息範本。沒有推廣活動建立工具。 --- ## EasyCoexistence vs Eazybe https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-eazybe Eazybe 是為銷售團隊而設的 CRM 層，以 Chrome 擴充功能形式安裝在 WhatsApp Web 上，Starter 方案按用戶數收費，較高方案則加入 WhatsApp API 號碼和 Coexistence。EasyCoexistence 只提供官方連接：Meta 的 Cloud API 加 Coexistence，按號碼收費，並把訊息送到您自己的系統。 ### 兩者如何接入 WhatsApp 兩款產品所處的位置不同：一個在銷售代表的瀏覽器內，一個在 Meta 的 API 上。 - Eazybe:: Chrome 擴充功能加在每位銷售代表已開啟的 WhatsApp Web 工作階段之上，提供標籤、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-hant/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 自助完成，約需兩分鐘，其後持續監察，讓失效的連接在客戶察覺前被發現。 ### 對話最終送到哪裏 收件匣為客服人員存放對話，連接則把對話轉交出去。 - 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 的訊息費用？** 由您直接向 Meta 支付，記在您自己的 WhatsApp Business 帳戶。EasyCoexistence 從不加價。 --- ## EasyCoexistence 與 Sinch 比較 https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-sinch Sinch 是企業通訊平台，除 SMS、語音及其他渠道外也轉售 WhatsApp，並按每位客戶的協議，在 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 的設定指南要求使用可接收國際 SMS 或來電、且未連接任何 WhatsApp 帳戶的號碼。其入門文章沒有說明 Coexistence 的做法。 - EasyCoexistence:: 已在 WhatsApp Business 應用程式上使用的號碼，透過 Coexistence 連接。對話、記錄和手機上的應用程式都會保留，Cloud API 在同一個號碼上運行。 ### 如何開始 一條路要經過銷售協議，另一條只需一個註冊頁面。 - Sinch:: Sinch Build 控制台上的 Embedded Signup，據其說法，目前只供直接企業客戶使用，價格亦視乎您的協議而定。 - EasyCoexistence:: 透過 Meta Embedded Signup 自助申請，約 2 分鐘完成，首 3 天免費。應用程式需為 2.24.17 或以上版本，並有近期的真實使用記錄。 ### 該如何選擇 企業若以議定條款，用一份合約購買 SMS、語音和 WhatsApp，買的是 CPaaS，與購買 WhatsApp 連接是兩回事。 如果您的客戶已經向您的 WhatsApp Business 應用程式發送訊息，或您是為客戶連接這些號碼的代理商，您需要的是 Coexistence、公開的價格，以及不在每則訊息上疊加費用。EasyCoexistence 正是為此而設，Webhook 由 Meta 直接傳送到您自己的系統，並提供供 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 vs Vonage https://easycoexistence.com/zh-hant/compare/easycoexistence-vs-vonage Vonage 是開發者通訊平台，其 Messages API 可同時傳送 WhatsApp、SMS、RCS 及其他渠道的訊息，並在 Meta 的收費之外，為每則訊息加收 Vonage 平台費。EasyCoexistence 透過 Coexistence，把 WhatsApp Business 應用程式的號碼連接到 Meta 的 Cloud API，按每個號碼收取固定費用，Meta 的訊息費用則直接向您收取。 ### 費用如何組成 用量計費與固定費用，會隨訊息量增加而出現不同走勢。 - Vonage:: Meta 按每則已送達訊息收費，另加 Vonage 平台費，每則訊息 0.0001 歐元起，並按用量及地區調整。通話另收 Vonage 費用，每分鐘 US$ 0.004。 - EasyCoexistence:: 每個已連接號碼每月 US$ 9，隨號碼增加降至 US$ 1。Meta 把訊息費用記在您自己的 WhatsApp Business Account，我們不會在每則訊息上加收任何費用。 ### 兩者各自為哪類號碼而設 小型企業日常使用的號碼，通常是 WhatsApp Business 應用程式的號碼。 - Vonage:: 其 WhatsApp 定價頁面及供合作夥伴使用的託管 Embedded Signup 指南，都沒有提及 Coexistence，即 Meta 讓應用程式在 API 號碼上繼續運作的功能。 - EasyCoexistence:: 專為 Coexistence 號碼而設。WhatsApp Business 應用程式保留聊天記錄，並可在手機上繼續使用，而 Cloud API 在同一號碼上運行，Coexistence 吞吐量為 Meta 規定的每秒 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-hant/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-hant/integrations/hubspot HubSpot 的 Communications 物件支援 WHATS_APP 頻道類型，專為記錄在 HubSpot 以外發生的訊息而設。將號碼的 Webhook 轉送到 n8n 工作流程，按電話號碼查找或建立聯絡人，再把每則訊息以 POST 送到 /crm/v3/objects/communications。對話便會出現在聯絡人的時間軸上，而團隊仍可繼續從 WhatsApp Business 應用程式回覆。 ### WhatsApp 訊息如何記錄到 HubSpot 聯絡人上？ 分三個步驟。Meta 將訊息傳送到您為該號碼設定的 Webhook 目的地，在這裡就是 n8n 的 Webhook 節點。工作流程會在 HubSpot 中以發送者的電話號碼搜尋聯絡人，找不到就建立新的。接着建立一筆通訊記錄，寫入訊息文字，並與該聯絡人建立關聯。 HubSpot 正是為這種情況設計了 Communications 物件。它代表在 HubSpot 以外收發的 WhatsApp、LinkedIn 或 SMS 訊息，並像已記錄的通話或電郵一樣顯示在記錄的時間軸上。必填屬性包括頻道類型、設為 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 建立通訊記錄時，HubSpot 要求它必須為 CRM。 - 以原始電話欄位搜尋聯絡人。Meta 的純數字格式很少與人手輸入的內容相符，每次找不到都會產生重複的聯絡人。 **我可以在 HubSpot 內直接回覆客戶嗎？** 不可以，Communications 物件只是記錄。回覆須從 WhatsApp Business 應用程式發出，或由呼叫 Cloud API 的工作流程發出，兩種方式都會記錄回該聯絡人。 **工作流程需要哪些 HubSpot 權限？** 聯絡人的讀取和寫入。HubSpot 列明 crm.objects.contacts.read 或 crm.objects.contacts.write 為 Communications API 的權限範圍，而建立聯絡人本來就需要寫入權限。 **同一個工作流程也可以傳送第一則訊息嗎？** 可以。另設一個 n8n 分支，用該號碼的電話號碼 ID 和存取權杖，透過 Cloud API 傳送已獲批准的訊息範本，再將它記錄為該聯絡人的外發通訊。 **EasyCoexistence 會在途中儲存訊息內容嗎？** 不會。Meta 直接將 Webhook 傳送到您的 n8n URL，EasyCoexistence 不會儲存任何對話內容。 --- ## 從 Coexistence 號碼將 WhatsApp 對話傳送至 Salesforce https://easycoexistence.com/zh-hant/integrations/salesforce 將號碼的 Webhook 轉送至 n8n 工作流程，以 SOQL 查詢按 phone 在 Salesforce 中找出寄件者，找不到就建立 Lead，再把每則訊息記錄為該記錄上的 Task 或備註。n8n 的 Salesforce 節點涵蓋這三個呼叫。團隊繼續使用 WhatsApp Business 應用程式回覆，歷史記錄則保存在 Salesforce。 ### n8n 工作流程是怎樣的？ 四個節點排成一列，另加每個 Meta Webhook 都需要的驗證分支。 Webhook 節點接收 Meta 為每則訊息發出的 POST。Salesforce 節點執行 SOQL 查詢，找出電話與寄件者相符的 Lead 或 Contact。IF 節點按是否有結果分流：有結果時，工作流程帶著記錄 id 繼續；沒有結果時，由另一個 Salesforce 節點以負載中的個人檔案名稱建立 Lead。最後一個 Salesforce 節點在該記錄上建立 Task，訊息文字放在描述欄，主旨註明這是一則 WhatsApp 訊息。 驗證分支負責回應 Meta 的 GET，以純文字內容回傳 hub.challenge 的值。沒有這一步，Meta 不會開始傳送，工作流程其餘部分只會閒置。 ### 訊息該放在 Task 還是備註？ 大多數團隊適合用 Task，因為它會出現在銷售人員本來就會查看的活動時間軸上，也可以用來製作報表。把狀態設為已完成，這樣就不會顯示為待辦事項；主旨寫明渠道名稱，要篩選 WhatsApp 活動只需一個條件。 n8n 節點的「Add note」操作適合另一種情況：只需要摘要，不需要每則訊息。有些團隊讓工作流程按聯絡人收集一天的訊息，晚上寫成一則備註，客戶即使發了二十行短訊，時間軸也依然易讀。 無論選哪一種，都要把 WhatsApp 訊息 id 寫入記錄。Meta 會重試傳送，工作流程寫入前先檢查該 id 是否已存在，就不會重複記錄同一則訊息。 ### 團隊還能用手機回覆嗎？Salesforce 看得到嗎？ 兩者皆可。Coexistence 讓 WhatsApp Business 應用程式在同一個號碼上繼續運作，昨天回覆客戶的同事今天照常回覆。當他們從應用程式回覆時，Meta 會把發出訊息的回音，以 smb_message_echoes 欄位傳送到同一個 Webhook 目的地。 在工作流程中為這些回音加一條路徑，並把它們記錄為外發 Task。銷售人員打開 Lead 時，就能按先後次序看到客戶的提問和店方的回覆，無須任何人手動複製對話。 工作流程自己發出的回覆，是透過 HTTP Request 節點呼叫 Cloud API，應在發送的當下記錄。此時文字和記錄 id 都已在工作流程手上。 ### 如何避免重複的 Lead？ 要比對標準化的電話號碼，而不是人手輸入的欄位原值。Meta 傳來的寄件者是含國家或地區代碼、不帶加號的純數字。Salesforce 的電話欄位則保留建立記錄的人所輸入的內容，可能有空格、括號和連字號。 可靠的做法是新增一個自訂文字欄位存放純數字號碼：工作流程建立 Lead 時填入，現有記錄則以回填方式補上。SOQL 查詢便可直接比對該欄位是否相等，既快速又準確。 也要檢查 Contact，不要只查 Lead。已轉換的客戶是 Contact，如果工作流程只搜尋 Lead，每位來訊的現有客戶都會被建立一個新的 Lead。 - 只搜尋 Lead 物件。現有客戶是 Contact，每位來訊的客戶都會變成重複的 Lead。 - 把訊息記錄為未完成的 Task。銷售人員會為客戶的每一行訊息收到待辦事項；建立時請把狀態設為已完成。 - 工作流程漏掉驗證用的 GET 分支。Meta 無法確認目的地，也就不會傳送任何訊息。 **這需要 Salesforce AppExchange 套件嗎？** 不需要。n8n 內建的 Salesforce 節點可處理搜尋、Lead 和 Task；它沒有涵蓋的功能，可以用同一組憑證透過 HTTP Request 節點完成。 **Make 也能做到同樣的事嗎？** 可以。Make 的自訂 Webhook 負責接收訊息，再由 Salesforce 模組寫入記錄。整個情境的結構與 n8n 工作流程逐步對應。 **Salesforce 可以向 Lead 發送 WhatsApp 訊息範本嗎？** 可以，經由工作流程進行。讓 Salesforce 呼叫 n8n 的 Webhook，再由 n8n 以該號碼的 phone number id 和存取權杖，透過 Cloud API 發送已獲批准的訊息範本。 **EasyCoexistence 會保存訊息的副本嗎？** 不會。Meta 把每個 Webhook 直接傳送到您的 n8n URL，EasyCoexistence 從不儲存對話內容。 --- ## 在 Coexistence 號碼上將 WhatsApp 連接到 Zoho CRM https://easycoexistence.com/zh-hant/integrations/zoho-crm 將號碼的 Webhook 轉送到 n8n 工作流程，以 phone 參數搜尋 Zoho CRM（它會檢查模組內的所有電話欄位），找不到相符記錄時建立 Lead，並把每則訊息作為備註加到該記錄。n8n 的 Zoho CRM 節點負責處理 Lead 與 Contacts；備註則使用同一組憑證，向 Zoho 的 Notes API 發出一次 HTTP 呼叫。 ### WhatsApp 訊息如何變成 Zoho CRM 記錄？ Meta 會把號碼上的每則訊息，傳送到您設定的 Webhook 目的地，這裡是 n8n 的 Webhook 節點。工作流程從負載中取出寄件人的號碼，把 phone 設為該號碼，先後對 Leads 和 Contacts 呼叫 Zoho 的搜尋端點。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 和多種銷售文件，支援建立、upsert、取得、取得全部、更新和刪除。Notes 不在其資源之列，所以備註要透過 HTTP Request 節點發送。n8n 允許該節點沿用您已連接的 Zoho 憑證，因此只需管理一份 OAuth 授權，而不是兩份。 請把 API 網域設為您的 Zoho 資料中心。在歐洲地區建立的憑證要呼叫 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-hant/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 呼叫按每位使用者計算，在滾動 2 秒視窗內，Lite 方案配合 API 存取權杖為 20 個請求，Ultimate 方案則高達 120 個。Search API 在所有方案都限制為每 2 秒 10 個請求。 平時安靜的號碼不會察覺。但如果號碼向數百位客戶發出訊息範本，一分鐘內收到 50 個回覆，就會觸及上限，因為每個回覆都由一次搜尋開始。工作流程隨後收到 429 回應，若沒有重試，備註便會遺失。 有兩個解決辦法。在 Pipedrive 搜尋節點開啟重試並設定等待時間；另外，把電話號碼對應聯絡人 ID 的關係快取在 n8n 的工作流程靜態資料或一個小型資料表中，這樣客戶連續發 6 則訊息，只需搜尋 1 次，而不是 6 次。 ### 在手機上輸入的回覆也能記錄嗎？ 可以。Coexistence 讓 WhatsApp Business 應用程式在同一個號碼上繼續運作，當團隊成員從應用程式回覆時，Meta 會以 smb_message_echoes 欄位，把這則外發訊息的回顯發送到同一個 Webhook 目的地。 為這些回顯加一個分支，記為標示為外發的備註；如果團隊以活動數量作報告，也可以記為已完成的活動。業務人員打開交易時，就能按次序看到客戶問了甚麼、店舖如何回答。 至於工作流程自己發出的訊息，例如交易移到新階段時發出的訊息範本，請在發送當下記錄備註。工作流程已有文字內容和交易 ID，不需要等待 Webhook。 ### 電話號碼應該如何標準化？ 只保留數字，包括國家代碼，不含其他符號，因為 Meta 發送的就是這種格式。發送者會以 14155550188 的形式出現，而人手輸入 Pipedrive 的聯絡人可能寫成 +1 (415) 555-0188。 工作流程建立聯絡人時，請以純數字格式儲存號碼，這樣自己的記錄永遠能互相匹配。對於人手建立的聯絡人，在 n8n 做一次性清理，把現有電話值改寫成同一格式，第一個星期就能回本。否則，精確比對搜尋會漏掉團隊自行輸入的聯絡人，工作流程便為每一位另建重複記錄。 如果團隊喜歡原本的格式，可以把它保存在第二個電話欄位。Pipedrive 聯絡人可以有多於一個電話。 - 每則訊息都搜尋一次，又沒有快取。連串回覆會觸及 Search API 每 2 秒 10 個請求的上限，備註因而遺失。 - 為每則訊息建立潛在客戶，而不是為每位新聯絡人建立。Leads Inbox 會塞滿同一位客戶的重複記錄。 - 有進行中的交易時，仍只把備註附加到聯絡人。負責交易的業務人員永遠看不到對話。 **訊息會出現在 Pipedrive 的 Messaging 收件匣嗎？** 不會。這個方法透過 Pipedrive 的 API 寫入備註和潛在客戶。對話由 WhatsApp Business 應用程式或工作流程回覆，並記錄到聯絡人或交易上。 **我可以用 Make 或 Zapier 代替 n8n 嗎？** 可以。自訂 Webhook 或 catch hook 接收訊息，再用它們的 Pipedrive 步驟或 HTTP 步驟，按相同次序寫入聯絡人、潛在客戶和備註。 **交易階段改變時可以發送 WhatsApp 訊息範本嗎？** 可以，透過工作流程實現。階段改變時呼叫 n8n 的 Webhook URL，n8n 就會以該號碼的 phone number ID 和存取權杖，經 Cloud API 發送已獲批准的訊息範本。 **EasyCoexistence 會儲存訊息嗎？** 不會。Meta 直接把每個 Webhook 發送到您的 n8n URL，EasyCoexistence 從不儲存對話內容。 --- ## 在 Coexistence 號碼上將 WhatsApp 連接到 Bitrix24 CRM https://easycoexistence.com/zh-hant/integrations/bitrix24 將號碼的 Webhook 轉送到 n8n 工作流程，再讓工作流程透過 Bitrix24 的傳入 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 之類的方法發出 POST。您無須完成 OAuth 流程，也無須發布應用程式。請只給予 Webhook CRM 權限範圍，並使用其權限涵蓋工作流程所需潛在客戶和聯絡人的用戶來建立它，因為 Bitrix24 是以該用戶的身分檢查存取權限。 ### 工作流程會呼叫哪些 Bitrix24 方法？ 共三個，在 n8n 的 Webhook 節點收到來自 Meta 的訊息後依次執行。 以 type 為 PHONE 和發送者號碼呼叫 crm.duplicate.findbycomm，會回傳持有該號碼的所有潛在客戶、聯絡人和公司的 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。 每則傳入訊息需要兩到三次呼叫，所以穩定的少量訊息絕不會觸及限制。突發大量訊息則會：五十位客戶在一分鐘內回覆同一則訊息範本，最多就是 150 次呼叫。請將 HTTP Request 節點設為失敗時短暫等待後重試，並讓工作流程一次只執行一個，這樣突發的請求會逐步流入 Bitrix24，而不是被拒於門外。 ### 在手機上輸入的回覆會傳到 Bitrix24 嗎？ 可以。在 Coexistence 號碼上，WhatsApp Business 應用程式仍然正常運作。有人從該應用程式回覆時，Meta 會把發出訊息的回聲，以 smb_message_echoes 欄位傳送到同一個 Webhook 目的地。 工作流程中的第二個分支以處理傳入訊息的相同方式處理這些回聲，並把備註標記為外發。記錄上就能按順序看到完整對話，包括客戶的發言和商店的回覆。 至於工作流程自己透過 Cloud API 發出的回覆，在發出時已經在工作流程手上，所以請在那一刻就記錄下來，無須等待 Webhook 回傳。 - 把傳入 Webhook URL 貼到用戶端程式碼或共用文件中。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-hant/integrations/rd-station 把號碼的 Webhook 導向 n8n 工作流程，然後針對每位寄件者，使用您的 API 金鑰向 api.rd.services/platform/conversions 發送 POST 請求，建立一個轉換事件。RD Station 接受以電話號碼代替電郵，所以沒有電郵的 WhatsApp 聯絡人同樣會成為潛在客戶，附上標籤，隨時可進入您的自動化流程。團隊繼續在手機上回覆。 ### WhatsApp 訊息如何變成 RD Station 潛在客戶？ Meta 會把號碼上的每則訊息發送到您設定的 Webhook 目的地，這裡是 n8n 的 Webhook 節點。工作流程從 `payload` 讀取寄件者的號碼和個人檔案名稱，然後向 RD Station Marketing 的轉換端點發送一次 HTTP POST，API 金鑰放在查詢字串中。 請求本文包含設為 CONVERSION 的 event_type、設為 CDP 的 event_family，以及帶有您自選 conversion_identifier（例如 whatsapp-inbound）的 payload。名稱、mobile_phone 和任何標籤都放在 payload 內。若聯絡人是新的，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-hant/integrations/gohighlevel 把號碼的 Webhook 轉送到 n8n 工作流程，用 n8n 的 HighLevel 節點將寄件人以「建立或更新」方式寫入 HighLevel 聯絡人，再透過 POST /contacts/{contactId}/notes 把每則訊息寫成備註。驗證使用子帳戶設定中的 Private Integration 存取權杖。只要把每個 phone_number_id 對應到各自的子帳戶，一個工作流程就能服務所有客戶。 ### WhatsApp 訊息如何進入 HighLevel 聯絡人？ Meta 會把號碼收到的每則訊息傳送到您設定的 Webhook 目的地，這裡是 n8n 的 Webhook 節點。工作流程把寄件人的號碼和 WhatsApp 個人檔案名稱交給 n8n 的 HighLevel 節點。該節點的聯絡人資源提供建立或更新操作，因此新寄件人會成為聯絡人，已有的寄件人則會被找出來，而不會重複建立。 取得聯絡人 ID 後，由 HTTP Request 節點把訊息內容 POST 到 /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 會把該則外發訊息的回音副本，以 smb_message_echoes 欄位傳送到同一個 Webhook 目的地。 為這些回音副本加一個分支，並把它們寫成標示為已傳送的備註。這樣聯絡人記錄就會按次序保存客戶的發言和商家的回覆，客戶打開 CRM 時期望看到的正是這樣。 當工作流程本身透過 Cloud API 傳送訊息時，例如預約成功後傳送已核准的訊息範本，請在傳送當下寫入備註，因為工作流程已經掌握文字內容和聯絡人 ID。 - 使用 v1 API 金鑰。HighLevel 的 v1 API 已終止服務，API v2 需要 Private Integration 存取權杖或 OAuth。 - 輪換 Private Integration 存取權杖後，沒有在 7 天重疊期內更新 n8n。舊存取權杖到期後，所有呼叫都會失敗。 - 用同一個子帳戶的存取權杖寫入所有客戶的訊息。請先把 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-hant/integrations/chatwoot Chatwoot 的 WhatsApp Cloud 收件匣需要三個值：WhatsApp Business Account id、phone number id 和存取權杖。Coexistence 號碼三者俱備。用它們建立收件匣，再把號碼的 Webhook 目的地設為 Chatwoot 的 Webhook URL，並填入相同的驗證權杖，團隊便可在 Chatwoot 和手機上回覆客戶。 ### 如何將 Coexistence 號碼連接到 Chatwoot？ 分兩個地方，按以下次序進行。 在 Chatwoot 中，新增收件匣，選擇 WhatsApp，然後選用 WhatsApp Cloud 供應商的手動設定。輸入號碼、phone number 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-hant/integrations/airtable Airtable 的 incoming webhook trigger 只接受 POST 請求，因此無法回應 Meta 的驗證 GET 請求，也不能直接成為號碼的 Webhook 目的地。請把目的地指向 n8n workflow，由它將每則訊息新增到資料表。傳送訊息可以在 Airtable 內完成：Run a script automation 可以用 fetch 呼叫 Cloud API，並把該號碼的存取權杖存放為 secret。 ### 為什麼 Airtable 不能直接接收 WhatsApp Webhook？ 因為 Meta 在傳送任何內容之前，會先檢查目的地。它會發出帶有 challenge 值的 GET 請求，並期望回應內容原樣返回同一個值。Airtable 的 When webhook received trigger 只接受 POST 請求，並以自己固定的 JSON 回應，所以驗證無法通過，Meta 也就不會開始傳送。 解決方法是在中間加一個步驟。由 n8n 的 Webhook node 處理驗證並接收每則訊息，再由 n8n 的 Airtable node 新增一列：寄件人、個人檔案名稱、內容、訊息 id、時間戳記，以及接收訊息的 phone number id。同樣的結構也適用於 Make 或 Zapier。 中間這一步還有另一個好處。Airtable 的 Webhook trigger 每秒只允許五個請求，而工作流程工具可以把突發的大量訊息排隊處理，否則這些請求會被拒絕。 ### 如何從 Airtable base 傳送 WhatsApp 訊息範本？ 使用動作為 Run a script 的 automation。觸發條件可以是記錄進入某個檢視、欄位變更或按下按鈕。腳本透過 input.config() 讀取記錄的電話號碼和欄位，再用 fetch 呼叫 Cloud API 的 messages 端點。Airtable 的 automation 腳本在伺服器端執行，所以不會受到瀏覽器的限制。 請把存取權杖存放為腳本編輯器中的 secret，而不要寫在程式碼裡。Airtable 會在主控台輸出中隱藏 secret，而且只有能存取腳本全部 secret 的人才可以編輯該腳本。 客戶在過去 24 小時內沒有主動來訊時，請一律使用訊息範本，因為自由格式訊息只會在該時段內送達。腳本可以把回傳的訊息 id 寫回記錄，讓每次傳送都能對應到相應的一列。 ### 訊息資料表應該怎樣設計？ 每則訊息一列，並以 WhatsApp 訊息 id 作為主欄位。Meta 會重試它認為失敗的傳送，而 workflow 在新增之前先查詢該 id，就不會重複寫入同一則訊息。 另設一個方向欄位，值為 inbound 和 outbound。在 Coexistence 號碼上，團隊在 WhatsApp Business 應用程式中輸入的回覆，會以 smb_message_echoes 事件送到同一個 Webhook。把這些記錄為 outbound 列，base 就能取得完整對話，而不只是其中一方。 把每則訊息連結到 Contacts 資料表，並以純數字電話號碼作為鍵，這正是 Meta 傳送的格式。然後用 rollup 顯示每位聯絡人最後一次 inbound 的時間，automation 只需這一個欄位，就能決定使用自由格式訊息還是訊息範本。 - 把 Airtable 的 Webhook URL 設為號碼的目的地。它只接受 POST，Meta 的驗證 GET 會失敗，因此完全不會有訊息送達。 - 把存取權杖直接貼進腳本內容。請存放為腳本 secret，讓它不會出現在程式碼和日誌中。 - 對 24 小時內沒有來訊的人，從記錄 automation 傳送自由格式訊息。只有已核准的訊息範本才能送達。 **Airtable 免費方案可以使用 Run a script 嗎？** Airtable 表示所有方案類型都有此動作，但限制各有不同，而且 Team 方案試用期間無法使用。 **可以不用 n8n，改用 Make 或 Zapier 嗎？** 可以。三者都能接收 Webhook、回應驗證並新增一列。Airtable 本身是唯一不能成為目的地的一環。 **Airtable 按鈕可以傳送 WhatsApp 訊息嗎？** 可以。使用 When a button is clicked trigger，搭配呼叫 Cloud API 的 Run a script action，並以該列的資料填入訊息範本。 **EasyCoexistence 會儲存這些訊息嗎？** 不會。Meta 會把每個 Webhook 傳送到您的 n8n URL，唯一的副本就是您的 workflow 寫入 Airtable 的那一份。 --- ## 將 WhatsApp 訊息記錄到 Google Sheets，並從試算表傳送訊息 https://easycoexistence.com/zh-hant/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 收集 30 秒內的訊息，再以一次請求寫入，把多次寫入合併為一次。 ### 如何從試算表傳送範本？ 使用 Apps Script，從試算表的「擴充功能」選單進入。函式會讀取尚未傳送的資料列，為每一列透過 UrlFetchApp 呼叫 Cloud API 的 messages 端點，並將回傳的訊息 ID 和時間寫回該列。您可以設定定時觸發器，每隔幾分鐘執行一次，也可以從自訂選單手動執行。 請將存取權杖儲存在指令碼屬性中，而不要寫在程式碼裡，這樣能檢視指令碼的人也看不到它。 請留意配額。一般 Google 帳戶每日有 20,000 次 URL Fetch 呼叫，Workspace 帳戶為 100,000 次，而每次執行在 6 分鐘後會停止。請分批處理資料列，並在繼續之前先將每列標記為已傳送，這樣中斷的執行可以從上次停下的地方繼續，不會重複傳送。 - 新增資料列時沒有以訊息 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-hant/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 是用擁有該訂閱的應用程式的應用程式密鑰簽署。請在目的地 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 key 嗎？** 只可在伺服器端使用，如本例所示，從函數的環境變數讀取。它會繞過列層級安全性，所以絕不可以到達瀏覽器。 **一個函數可以服務多個號碼嗎？** 可以。將每個號碼的 Webhook 目的地都指向它，再根據每個負載中的 phone_number_id 分流處理。 **EasyCoexistence 看得到這些訊息嗎？** 看不到。Meta 會把每個 Webhook 直接傳送到您的函數，而 EasyCoexistence 從不儲存對話內容。 --- ## 在 Coexistence 號碼上連接 WhatsApp 與 Activepieces https://easycoexistence.com/zh-hant/integrations/activepieces Activepieces 設有 WhatsApp Business piece，以存取權杖和 WhatsApp Business 帳戶 id 連接，而 Coexistence 號碼兩者皆可提供。其 New Incoming Message 觸發器會自行回應 Meta 的驗證，因此它的 URL 可直接用作該號碼的 Webhook 目的地。請將 piece 的選填應用程式密鑰留空，如此每則訊息都會啟動流程，而團隊仍可繼續使用手機。 ### 如何將 Coexistence 號碼連接到 Activepieces？ 在 Activepieces 建立 WhatsApp Business 連接，只需兩個值：存取權杖和 WhatsApp Business 帳戶 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 每個應用程式只接受一個回呼 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 帳戶下的號碼。 **同一個號碼還可以同時使用 n8n 或 Make 嗎？** 不能同時使用。Meta 只會把號碼的 Webhook 傳到一個目的地，因此請選定一個工具接收，或由它轉發給另一個。 **EasyCoexistence 會儲存訊息嗎？** 不會。Meta 會把每個 Webhook 直接傳到 Activepieces 觸發器，EasyCoexistence 從不儲存對話內容。 --- ## 透過 Coexistence 在 WhatsApp 上運行 Typebot 流程 https://easycoexistence.com/zh-hant/integrations/typebot Typebot 的 WhatsApp 頻道需要存取權杖、WhatsApp Business Account ID 和 Phone number ID，然後提供回呼 URL 和驗證權杖。請從已連接的號碼填寫前三項，將 Typebot 的選填 app secret 留空，並把其回呼 URL 和驗證權杖設為該號碼的 Webhook 目的地。 ### Typebot 的哪些欄位使用已連接號碼的值？ Typebot 的 WhatsApp 精靈位於機械人的 Share 分頁之下，需要四項資料：app secret、System User Token、WhatsApp Business Account ID 和 Phone number ID。 其中三項直接來自連接。控制台會顯示該號碼的 WABA ID、Phone number ID 和存取權杖；如果由助理代您取得，get_api_credentials 工具會傳回相同的值。請把它們貼到對應的欄位。 app secret 是要留空的一項。Typebot 對傳入流量只用它做一件事：檢查 Meta 為每次傳送加上的 X-Hub-Signature-256 標頭。對於透過 Tech Provider 連接的號碼，Meta 使用提供者的 app secret 簽署，而這個密鑰不會與任何人共用，因此您在該欄位輸入任何值，都會令 Typebot 拒絕每一則真正的訊息。欄位留空時，Typebot 會略過此項檢查並接受傳送的內容。 ### Typebot 的回呼 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 的 app secret 貼到 Typebot。傳送的內容是以 Tech Provider 的密鑰簽署，因此 Typebot 會因簽署無效而拒絕每一則訊息。 - 重複使用舊的 Typebot 驗證權杖。它在一次驗證成功後就會被刪除，所以再次設定目的地時，需要從精靈取得新的權杖。 - 分享回呼 URL。在簽署檢查關閉的情況下，只要知道該 URL 就可以送入請求，因此請像密碼一樣妥善保管。 **使用 Typebot 需要自己的 Meta 應用程式嗎？** 不需要。Typebot 的指南假設您有一個，因為多數人自行連接號碼。透過 Tech Provider 使用 Coexistence 時，存取權杖和 ID 來自連接，Meta 會把 Webhook 傳送到 Typebot。 **團隊在手機上仍能看到機械人的訊息嗎？** 可以。透過 Cloud API 傳送的訊息，會顯示在同一號碼的 WhatsApp Business 應用程式中，因此團隊成員可以閱讀對話並接手。 **Typebot 和 n8n 可以同時接收同一號碼的訊息嗎？** 不可以。一個號碼只有一個 Webhook 目的地。如果兩者都需要這些事件，請把目的地指向 n8n，再讓工作流程把原始負載轉發到 Typebot 的回呼 URL。 **Typebot 會儲存對話嗎？** Typebot 會保存自己的工作階段和結果資料，在任何頻道上都是如此。EasyCoexistence 從不儲存訊息內容：Meta 直接把訊息傳送到您設定的目的地。 --- ## 透過 Coexistence 將 Botpress 機械人連接到 WhatsApp https://easycoexistence.com/zh-hant/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。系統會要求填寫驗證權杖、存取權杖、預設機械人電話號碼 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-hant/integrations/dify 將號碼的 Webhook 指向一個小型接收器，例如 n8n 工作流程或您自己程式碼中的一條路由，由它把每則訊息交給 Dify 的 Send Chat Message API，再透過 Cloud API 把答案送回。在 Dify 內，可把 EasyCoexistence MCP 伺服器加入為工具，讓 Agent 直接操作該號碼。 ### Meta 可以直接把 WhatsApp 訊息送到 Dify 嗎？ 無法完成驗證握手。Meta 在傳送任何內容之前，會先以 GET 請求呼叫目的地，並期望回應本文原樣帶回 hub.challenge 的值。Dify 的 Webhook Trigger 每個觸發器只接受一種 HTTP 方法，其文件亦指出非 JSON 的回應本文會自動轉換成 JSON，所以 OK 會變成一個訊息物件回來。challenge 永遠無法原樣回傳，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 的 Agent 無需您逐一串接每個呼叫，就能直接操作該號碼。Dify 透過 HTTP 連接 MCP 伺服器，並預設以 OAuth 動態客戶端註冊向伺服器登記，而 EasyCoexistence MCP 伺服器正支援這種方式。在「工具」下加入它，登入一次，Agent 就能使用這些工具：列出號碼、檢查號碼的健康狀態、傳送訊息、傳送已核准的訊息範本、讀取訊息範本狀態。 主動跟進正適合這樣做：隔天跟進的 Dify 工作流程必須使用 send_template，因為在時限以外傳送自由格式訊息會回傳錯誤 131047，工具說明也已向模型註明這點。 MCP 做不到的，是在客戶來訊時喚醒 Dify。此協定屬於請求與回應模式，所以來訊仍須經由 Webhook 和前面的接收器進入。 - 把 Dify Webhook Trigger 的 URL 當作 Webhook 目的地。challenge 會被包成 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-hant/integrations/flowise 把號碼的 Webhook 目的地設為一個小型接收器，例如 n8n 工作流程或您自己程式碼中的一條路由。接收器將每則訊息交給 Flowise 的 Prediction API，並以發送者的號碼作為工作階段 ID，再用該號碼的存取權杖和 phone number 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 agent 可以使用 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-hant/integrations/langchain LangChain 代理要使用 WhatsApp，需要兩個部分。收到的訊息經由號碼的 Webhook 送到您的網頁路由，再由路由呼叫代理。代理要執行操作時，可透過 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 的訊息端點發送請求會更簡單。這樣窗口檢查就放在您的程式碼中，而絕不能違反的規則本來就應該放在這裡。窗口外傳送自由格式訊息會傳回錯誤 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 工具只讀取帳戶和號碼的狀態。 --- ## 在 WhatsApp 號碼上運行 OpenAI Agents SDK 代理程式 https://easycoexistence.com/zh-hant/integrations/openai-agents-sdk 將號碼的 Webhook 目的地設為您 Python 應用程式中的一條路由。每收到一則訊息，就以 Runner.run 執行代理程式，並使用以發送者號碼作為鍵的工作階段，然後憑該號碼的存取權杖和電話號碼 ID，透過 Cloud API 把 result.final_output 發送回去。WhatsApp Business 應用程式在同一號碼上照常使用。 ### WhatsApp 訊息如何變成一次代理程式運行？ 透過您自己應用程式中、由 Meta 呼叫的一條路由。將號碼的 Webhook 目的地設為該路由，並在路徑中加入一段較長的隨機密鑰。路由以純文字回傳 hub.challenge 來回應 Meta 的驗證 GET，接受每個 POST，立即回應 200 並把工作加入佇列，因為 Meta 會重試回應過慢的請求，否則代理程式會被執行兩次。 之後由背景工作程式從負載中讀取發送者和文字，並呼叫 Runner.run。傳入一個以發送者號碼作為 ID 的工作階段：SDK 會按該 ID 儲存對話，所以同一位客戶的下一則訊息會接續上一次的內容，兩位客戶也不會共用記錄。起步時使用 SQLiteSession 已足夠；如有多個背景工作程式，SDK 亦提供 Redis 和 SQLAlchemy 工作階段。 這裡的驗證靠的是網址中的密鑰。Meta 使用 Tech Provider 的應用程式密鑰為傳送內容簽署，因此客戶無法驗證簽署標頭。 ### 為甚麼應由您的程式碼而非代理程式發送回覆？ 因為絕不可違反的那條規則是時間規則，由程式碼執行比由提示詞執行更可靠。客戶發訊息時，Meta 會開啟 24 小時的客戶服務時段。在時段內可以發送自由格式訊息；時段外只能發送已核准的訊息範本，否則自由格式訊息會返回錯誤 131047。 回覆剛剛收到的訊息的背景工作程式必然處於時段內，所以把 result.final_output 當作文字發送，在設計上是安全的。之後才發生的工作，例如翌日早上的跟進或提醒，應走另一條只發送訊息範本、絕不發送自由格式訊息的路徑。 代理程式仍然可以使用工具。您可以提供函式工具讓它查詢資料，例如訂單或預約，而 WhatsApp 的發送則留在背景工作程式內。這樣也能令存取權杖遠離模型可用任意參數呼叫的任何工具。 ### 代理程式可以使用 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 之間選擇。如果只是負責回覆的前台，上面的背景工作程式寫法更短，出錯的機會也更少。 無論哪種做法，Webhook 都要保留。MCP 是請求與回應模式，客戶的訊息只能經由 Meta 呼叫的路由到達代理程式。 - 在向 Meta 回傳 200 之前就執行代理程式。回應過慢會被重試，客戶便會收到兩個回覆。 - 所有客戶共用同一個工作階段。請以發送者號碼作為鍵，否則記錄會混在一起。 - 讓延遲的跟進發送自由格式訊息。超過 24 小時後會以 131047 失敗，請改為發送訊息範本。 **這需要使用 OpenAI Responses API 的託管 MCP 工具嗎？** 不需要。背景工作程式以 Runner.run 在本機執行代理程式，WhatsApp 一方只是您的程式碼發出的普通 HTTPS 呼叫。 **我應該使用哪個 Graph API 版本？** Meta 現行範例使用 v25.0。請在程式碼中的單一位置固定版本，升級時只需改一行。 **可以由真人在手機上接手嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式保持可用，而在手機上的回覆會以 echo 事件送到您的路由，背景工作程式可據此暫停代理程式。 **EasyCoexistence 會儲存對話嗎？** 不會。Meta 直接將訊息傳送到您的路由。工作階段儲存的任何內容，都保存在您自己的資料庫中。 --- ## 用 Vercel AI SDK 建立 WhatsApp 智能代理 https://easycoexistence.com/zh-hant/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 應用程式在該號碼上照常運作，在手機上輸入的每則回覆，都會以 echo 事件送到路由。處理器若在收到 echo 後暫停對該聯絡人使用模型，就不會搶在真人之前回覆。 第二，該號碼的傳送速率固定上限為每秒 20 則訊息。對話式代理不會接近這個數字，但用 Promise.all 對聯絡人清單寫成的群發迴圈會超出，所以請分批傳送。 其餘都是一般的 Cloud API 規則。客戶最後一則訊息的 24 小時內，可以傳送自由格式訊息。之後只有已核准的訊息範本能送出，自由格式訊息會回傳錯誤 131047，客戶也不會看到任何內容。 - 用 JSON 回應輔助函式回傳 challenge。多出的引號會令 Meta 的檢查失敗。 - 先執行 generateText 才回應 Meta。冷啟動時，重試會產生第二則回覆。 - 忘記關閉 MCP 用戶端。每個請求都會留下一個連接，直到平台將其終止。 **這只能在 Vercel 上運作嗎？** 不是。AI SDK 是 TypeScript 程式庫，只要主機支援 HTTPS，並能回應 GET 和 POST，路由就可以在任何主機上運行。 **我一定要用 MCP 用戶端嗎？** 回覆訊息不需要。用該號碼的存取權杖向 Cloud API 的 messages 端點發出 fetch 請求即可。當模型要自行決定做什麼時，MCP 才有用處。 **模型可以用哪個供應商？** AI SDK 支援的都可以。WhatsApp 這一端與模型無關，所以更換供應商不需要修改路由或 Cloud API 呼叫。 **EasyCoexistence 看得到訊息嗎？** 看不到。Meta 直接傳送到您的路由，訊息內容絕不會儲存在我們這邊。 --- ## 從 Shopify 發送 WhatsApp 訂單訊息 https://easycoexistence.com/zh-hant/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 向對方發送訊息：即對方提供了號碼，並同意接收該企業的訊息。最常見的做法是在結帳頁加入勾選框，工作流程在發送前應先檢查這一項。 ### 如果店舖的方案不含 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-hant/integrations/woocommerce 為訂單事件建立一個 WooCommerce Webhook，指向一個接收器，例如 n8n 工作流程或一個小型 PHP 路由。接收器驗證 WooCommerce 的簽章，確認客戶同意接收 WhatsApp 訊息，再用已連接號碼的電話號碼 ID 和存取權杖，透過 Cloud API 傳送已核准的訊息範本。 ### WooCommerce 訂單如何觸發 WhatsApp 訊息？ 透過 WooCommerce Webhook 和一個接收器。在 WooCommerce 的設定 > 進階 > Webhooks 中，新增一個 Webhook，選擇訂單主題（例如訂單已建立或訂單已更新），並填入傳送 URL 和密鑰。之後每次事件發生，WooCommerce 都會把訂單以 JSON 格式 POST 到該 URL。 負載格式是固定的，因此無法直接指向 Cloud API，中間需要一個接收器：n8n 的 Webhook 節點、店舖自己 PHP 程式中的一個路由，或任何小型服務均可。它讀取訂單，取出客戶的電話號碼和訊息所需的資料，然後向已連接號碼的 Cloud API 訊息端點發出一個 HTTPS 請求，並以該號碼的存取權杖作為 bearer 權杖。 order.updated 主題並不限於單一狀態，所以接收器應讀取訂單的 status 欄位，只在它關心的每次狀態轉換時傳送一次。WooCommerce 預設透過 wp-cron 在背景傳送，因此訊息可能比訂單稍遲一點送出。 ### 接收器如何得知請求來自店舖？ 靠 WooCommerce 的簽章。每次傳送都帶有 X-WC-Webhook-Signature 標頭，內容是以您在 Webhook 上設定的密鑰，對原始負載計算出的 base64 編碼 HMAC-SHA256。接收器對收到的內容計算同一個雜湊並比對，不符的一律拒絕。 這是店舖自己的密鑰，因此與 Meta 對收到的 WhatsApp 訊息所附的簽章不同，這個簽章是可以驗證的。請以恆定時間比對，並且在任何框架解析之前，先對原始內容計算雜湊，因為重新編碼後的 JSON 會產生不同的雜湊。 請盡快回應 2xx。WooCommerce 會把不是 2xx、301 或 302 的回應視為失敗，連續失敗超過 5 次便會停用該 Webhook。接收器因部署而停機，或因為等待 Meta 回應而太慢，都可能令店舖的訊息在無人察覺下停止傳送。 ### 店舖可以傳送什麼，何時傳送？ 只要是店舖先開口，就必須使用已核准的訊息範本。Meta 的 24 小時客戶服務時段，只會在客戶向該號碼傳送訊息時開啟，所以訂單確認或出貨更新屬於商戶主動發起，自由格式訊息會被拒絕。請為每種更新建立一個實用類訊息範本，等待核准後，以名稱和語言傳送，並把訂單編號等資料作為參數。 Meta 還要求取得同意：客戶提供了號碼，並同意透過 WhatsApp 接收該商戶的訊息。在結帳頁加入一個勾選框，並把結果記錄在訂單上，是最簡單的做法，接收器在傳送前應先檢查。 客戶一旦回覆，對話就是一般的 Coexistence。回覆會出現在店舖手機的 WhatsApp Business 應用程式中，時段開啟後可傳送自由格式訊息，團隊也一如既往在應用程式中回覆。 - 先呼叫 Cloud API，才回應 WooCommerce。傳送緩慢或失敗都會計入該 Webhook 的失敗次數，超過 5 次便會被停用。 - 對已解析的 JSON 計算雜湊，而不是對原始內容。簽章永遠不會相符，每一個真實的傳送都會被拒絕。 - 每次收到 order.updated 都傳送。該主題並不限於單一狀態，若不記錄已通知過哪一次狀態轉換，客戶會收到重複的訊息。 **我需要為此安裝 WordPress 插件嗎？** 不需要。WooCommerce 內建的 Webhook 加上一個接收器已經足夠，接收器可以是同一個 PHP 應用程式中的一個路由。 **訂單訊息的費用由誰支付？** Meta 直接向商戶在其自己的 WhatsApp Business 帳戶收取訊息費用，EasyCoexistence 絕不加價。 **團隊仍然可以使用手機嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式繼續在店舖的號碼上運作，店舖傳送的訊息範本也會顯示在對話中。 **如果 Webhook 被停用了怎麼辦？** 先修復接收器，再在 WooCommerce 把該 Webhook 的狀態改回啟用。停用期間建立的訂單不會觸發訊息。 --- ## 從 PHP 和 Laravel 傳送及接收 WhatsApp 訊息 https://easycoexistence.com/zh-hant/integrations/php-laravel 接收只需一條 Laravel 路由：回應 Meta 的驗證 GET 請求，並接受 POST。由於 PHP 會把點號轉成底線，參數要以 hub_mode、hub_verify_token 和 hub_challenge 讀取。傳送則是一次 Http::withToken() POST，目標是 Cloud API 的 messages 端點，並帶上該號碼的電話號碼 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 用戶端：向該電話號碼 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 嗎？** 我們沒有提供，也不需要。這個 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-hant/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 country 為巴西的 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 country 為巴西，卻在 2027 年 6 月 30 日後仍保留 USD 的 Messaging 帳戶。Meta 會由 2027 年 7 月 1 日起停止傳送該帳戶的訊息。 - 把所有回覆都當作免費。自 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-hant/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 亦同時公布與 USD 並列的完整 MXN 費率表。 貨幣在建立訊息帳戶時選定，之後不能直接切換。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-hant/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 顯示。 貨幣在建立 Messaging 帳戶時設定，之後不會改變。日後如需更換，須使用 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-hant/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 費率表。至於實用及驗證訊息，當 Business Portfolio 每月向阿根廷發送足夠數量的訊息時，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 的費率表上有獨立一行，數字與 Rest of Latin America 不同。 - 把實用訊息範本當作回覆發送，並預期免費。自 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-hant/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 方面，每個商業電話號碼每月首 1,000 則服務訊息免費，即在 24 小時客戶服務窗口內傳送的非範本回覆。此外，由 Click to WhatsApp 廣告開始的對話會開啟最長 7 天的免費入口窗口，窗口內除 Meta Business Agent 訊息外，各類別均不收費。 以智利的推廣類費率計算，免費入口窗口是在當地傳送推廣訊息最便宜的途徑。 ### Meta 提供智利比索結算嗎？ 提供，屬於可選項目。CLP 於 2026 年 4 月 1 日啟用，是 Meta 當年新增的貨幣之一。Meta 公布的 CLP 費率表涵蓋所有市場，因此傳送給海外客戶的訊息也會以比索顯示。 結算貨幣在建立訊息帳戶時選定，之後固定不變，除非企業使用 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-hant/docs/whatsapp-coexistence-peru Coexistence 在秘魯可用，因為 Meta 針對 WhatsApp Business 應用程式用戶的接入文件並無任何國家限制。傳送至 +51 號碼的訊息按秘魯費率表計算：自 2026 年 10 月 1 日起，每則行銷範本 USD 0.0703，每則實用類或驗證類範本 USD 0.03；按 Meta 的索爾費率表則分別為 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-hant/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-hant/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）是獨立列出的市場，與涵蓋葡萄牙、愛爾蘭等地的其他西歐地區不同。以下為 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 公布完整的歐元費率表，所有市場（不只西班牙）均以歐元定價。 貨幣在建立訊息帳戶時選定，之後固定不變，只能透過 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）屬於其他西歐地區，費率不同。 - 沿用 2026 年 7 月 1 日之前的行銷費率。Meta 在該日調高了西班牙的行銷費率。 **歐盟是否曾經無法使用 Coexistence？** 早期推出階段的名單曾將其排除。Meta 現行針對 Business 應用程式用戶的接入文件沒有列明地域限制，因此以接入流程能否完成為準。 **從西班牙向拉丁美洲傳送訊息，是否按西班牙費率計算？** 不是。Meta 按收件人的國際電話區號收費，所以傳送至墨西哥號碼的訊息，會按墨西哥的費率計算。 **客戶傳給我的訊息需要付費嗎？** 不需要。Meta 只對企業送達用戶的訊息收費。 **連接後應用程式還能繼續使用嗎？** 可以。WhatsApp Business 應用程式及其聊天記錄會保留在手機上，而該號碼同時獲得 API 存取權。 --- ## 印度的 WhatsApp Coexistence：可用性、Meta 費率與 INR 帳單 https://easycoexistence.com/zh-hant/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 帳戶轉為 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 帳戶轉為 INR。Meta 表示，自 2027 年 1 月 1 日起，將不再送達符合資格客戶旗下非 INR 帳戶的訊息。 在 Coexistence 號碼上，這會影響透過 API 發送的付費訊息，因為付款方式設定在企業自己的 WhatsApp Business 帳戶上。印度另設驗證國際費率，適用於位於印度以外的合資格企業，Meta 會在訂定開始日期時提前 30 天通知。 ### 如何把印度號碼連接到 API 並保留應用程式？ 透過 Meta 的 Embedded Signup 並選擇 Coexistence 選項，由 Tech Provider 執行。企業以 Facebook 登入，選擇其 Business Portfolio，輸入已在 WhatsApp Business 應用程式註冊的 +91 號碼，再掃描應用程式中顯示的 QR 碼確認。之後可以同步應用程式的聊天記錄，其中媒體檔案只提供最近兩星期的內容。 號碼會繼續在應用程式中使用，同時獲得 Cloud API 存取權，吞吐量固定為每秒 20 則訊息。完整步驟及每個畫面所需的資料，請參閱連接號碼頁面。 - 在 Sold-To 國家為印度的情況下，於 2026 年 12 月 31 日後仍讓 WhatsApp Business 帳戶使用 USD。Meta 已表示會停止送達這些訊息。 - 按發送方所在國家為推廣活動定價。Meta 按收件人的國際電話區號收費，因此 +91 收件人適用印度費率。 - 把所有範本都當作實用範本。在印度，Meta 歸類為推廣的範本，費用超過實用範本費率的 8 倍。 **回覆印度客戶是否免費？** 在 24 小時客戶服務時段內回覆的非範本訊息免費，在 WhatsApp Business 應用程式中手動輸入的訊息也免費。時段以外發送的範本則須收費。 **Meta 以哪種貨幣向印度企業收費？** Billing Hub 的 Sold-To 國家為印度的企業正轉用 INR，所有帳戶須在 2026 年 12 月 31 日前轉為 INR。Meta 已為此公布 INR 費率表。 **我的企業在海外，也要付印度費率嗎？** 推廣及實用範本須要，因為費率按收件人的 +91 區號計算。驗證範本在 Meta 為您的企業訂定開始日期後，可轉用驗證國際費率。 **我還可以在手機上繼續使用應用程式嗎？** 可以。只要應用程式版本為 2.24.17 或以上，並且定期開啟，Coexistence 就會讓 WhatsApp Business 應用程式在同一個號碼上繼續運作。 --- ## 印尼的 WhatsApp Coexistence：可用性、Meta 費率與設定 https://easycoexistence.com/zh-hant/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 及其他十四種貨幣，因此印尼企業可直接在 Meta 的費率表以印尼盾查看成本，無須自行換算。 印尼亦在 Meta 設有國際驗證費率的國家名單內。營運地點在印尼境外的企業，若向 +62 號碼發送一次性密碼，可能會被轉為每則驗證訊息範本 US$ 0.136，超過本地費率的五倍。Meta 按每間企業分別訂定開始日期，並提前 30 天通知，因此向印尼用戶進行驗證的海外應用程式，應在擴大註冊規模前做好預算。 ### 如何在不失去應用程式的情況下連接印尼號碼？ 透過 Meta 的 Embedded Signup，選擇現有 WhatsApp Business 應用程式號碼的選項。企業以 Facebook 登入，選擇其 Business Portfolio，輸入 +62 號碼，並掃描應用程式顯示的 QR 碼。完成後，合作夥伴須在 24 小時內開始同步聯絡人及聊天記錄，否則企業須重新進行流程。 接入後，手機照常運作，號碼同時透過 Cloud API 回應，兩者共用固定的每秒 20 則訊息。連接號碼頁面會逐個畫面說明整個流程。 - 自行將美元價格換算成印尼盾。Meta 已發佈 IDR 費率表，IDR 帳戶實際按該數字收費。 - 為營運地點在海外的企業，以本地費率編列一次性密碼的預算。印尼設有 US$ 0.136 的國際驗證費率。 - 掃描 QR 碼後放棄流程。同步必須在 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-hant/docs/whatsapp-coexistence-uae Coexistence 適用於阿拉伯聯合酋長國的號碼，因為 Meta 為 WhatsApp Business 應用程式用戶提供的接入文件，沒有列明任何國家限制。自 2026 年 10 月 1 日起，Meta 對每則送達 +971 號碼的行銷訊息範本收取 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，當中沒有任何國家、地區或國際電話區號的排除。正在 WhatsApp Business 應用程式上使用的 +971 號碼符合資格。 阿聯酋號碼失敗的原因與其他地方相同：號碼在一般 WhatsApp 應用程式上、應用程式版本過舊，或號碼仍連接着另一個服務供應商。Embedded Signup 本身就是最可靠的測試，因為它會接受該號碼，或說明不接受的原因。 ### Meta 在阿聯酋每則訊息收費多少？ Meta 按每則送達的訊息範本收費，並按收件人的國際電話區號定價。任何送達 +971 號碼的訊息範本，都按阿聯酋費率計費，與發送企業在何處註冊無關。阿聯酋在 Meta 費率表上有獨立一行，並非與其餘中東地區共用費率。 以下數字取自 Meta 於 2026 年 10 月 1 日生效的 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 號碼，並以應用程式內顯示的 QR 碼確認。已同步聊天記錄中的媒體，只提供最近兩星期的內容。 之後 WhatsApp Business 應用程式在手機上繼續運作，同一個號碼透過 Cloud API 以固定每秒 20 則訊息的速度收發。「連接號碼」頁面列出每個步驟及各步驟所需的條件。 - 以為阿聯酋按其餘中東地區定價。其實它在 Meta 費率表上有獨立而且較高的一行。 - 自行用手算把 USD 費率換算為迪拉姆。自 2026 年 4 月 1 日起，Meta 已發布有獨立數字的 AED 費率表。 - 從海外向 +971 號碼發送密碼，卻按本地預算估算。國際驗證費率高出三倍以上。 **Meta 可以用迪拉姆向阿聯酋企業計費嗎？** 可以。AED 於 2026 年 4 月 1 日成為 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-hant/docs/whatsapp-coexistence-saudi-arabia 沙特號碼可以使用 Coexistence：Meta 為 WhatsApp Business 應用程式用戶提供的接入文件，沒有設定任何國家限制。自 2026 年 10 月 1 日起，Meta 對每則送達 +966 號碼的推廣範本收費 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 號碼，並掃描應用程式顯示的 QR 碼。其後合作夥伴須在 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-hant/docs/whatsapp-coexistence-turkey 土耳其號碼可以使用 Coexistence，因為 Meta 針對 WhatsApp 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 號碼的範本都按土耳其的費率計算。土耳其在費率表上有獨立一行。 在 Meta 自 2026 年 10 月 1 日起生效的美元費率表上，這些數字屬於表中最低之列：行銷範本 US$ 0.0109，實用及驗證範本 US$ 0.0009。歐元費率表列出 €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）結算，成本應直接參照該費率表，而不是自行換算。 最值得留意的是近期的費率變動。Meta 於 2026 年 4 月 1 日調低了土耳其的實用及驗證費率，令發送至 +90 號碼的訂單更新和一次性驗證碼每則只需不到一美仙。在該日期之前訂立的舊預算會高估這些成本。 ### 如何連接土耳其號碼並保留應用程式？ 透過 Meta 的 Embedded Signup，選擇適用於已在 WhatsApp Business 應用程式中使用的號碼的選項，並由 Tech Provider 負責託管。商戶以 Facebook 登入，選擇其 Business Portfolio，輸入 +90 號碼，然後在應用程式中掃描 QR 碼確認。同步必須在 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-hant/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 號碼傳送一則推廣訊息範本的成本超過 0.13 美元，實用訊息範本則為 0.055 美元，所以在德國最划算的訊息，就是 Meta 完全不收費的那些。 因此，客戶服務時段是控制成本的主要手段。在 24 小時內回覆主動來訊的客戶的工作流程，每則訊息都不用付費；時段開啟期間傳送的實用訊息範本同樣免費。費用主要來自以訊息範本主動開啟對話的推廣。在 Coexistence 號碼上，職員在 WhatsApp Business 應用程式中手動輸入的訊息也是免費的，因此 API 可以只用於自動化傳送。 ### 如何連接德國號碼並保留應用程式？ 使用 Meta 的 Embedded Signup，並選擇適用於已在 WhatsApp Business 應用程式中使用的號碼的選項。由 Tech Provider 提供流程，企業以 Facebook 登入，選擇其 Business Portfolio，輸入 +49 號碼，再以應用程式中顯示的 QR 碼確認。同步須在完成後 24 小時內開始，否則需要重新進行流程。 之後手機仍可正常使用，同一個號碼透過 Cloud API 收發訊息，速率固定為每秒 20 則。每個畫面都在連接號碼的頁面中有詳細說明。 - 按「其他西歐」的收費預算德國收件人。德國有自己的收費項目，推廣訊息的收費超過其兩倍。 - 在 24 小時時段內回覆已足夠時，仍以訊息範本開啟對話。在德國，免費與收費之間的差距很大。 - 為了少付費而將推廣訊息歸類為實用訊息。Meta 會審核訊息範本類別，並按推廣訊息的收費計算。 **Meta 可以用歐元向德國企業收費嗎？** 可以。歐元是 Meta 發布收費表的結算貨幣之一，在 2026 年 10 月 1 日的收費表上，德國的推廣訊息收費為 €0.1131。 **Coexistence 在歐盟有額外條件嗎？** Meta 現行為 WhatsApp Business 應用程式用戶提供的接入文件沒有列明任何額外條件。各地要求相同：應用程式 2.24.17 或更新，以及一個 Embedded Signup 合作夥伴。 **回覆德國客戶會收費嗎？** 在 24 小時客戶服務時段內以自由格式訊息回覆，不收費。時段以外的訊息範本，則按每則送達收費。 **從手機傳送的訊息仍然免費嗎？** 是。Meta 表示，接入後從 WhatsApp Business 應用程式傳送的訊息維持免費。只有透過 Cloud API 傳送的訊息，才按 Cloud API 定價收費。 --- ## 意大利的 WhatsApp Coexistence：可用性、Meta 費率與設定 https://easycoexistence.com/zh-hant/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 進行，當中沒有任何國家、地區或國際區號的排除。文件也沒有為歐盟號碼增設條件。只要 +39 號碼正在 WhatsApp Business 應用程式上使用，便符合資格。 意大利號碼被拒絕，只會基於一般原因：號碼仍在個人版 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 號碼，並掃描應用程式內顯示的 QR 碼。同步的聊天記錄中，媒體檔案只涵蓋最近兩星期。 接入後，手機仍可照常使用，同一個號碼亦會透過 Cloud API 以固定每秒 20 則訊息的速度收發訊息。連接號碼頁面會逐步說明。 - 沿用 2026 年 7 月 1 日前為 +39 收件人編制的推廣預算。Meta 在該日調高了意大利的推廣費率。 - 將其餘西歐地區的費率套用在意大利號碼上。意大利在 Meta 費率表上有獨立一行。 - 在仍使用個人版 WhatsApp 應用程式的號碼上開始接入。必須先轉移到 Business 應用程式。 **Meta 可以用歐元向意大利企業收費嗎？** 可以。歐元是 Meta 的結算貨幣之一，其歐元費率表列明意大利的推廣訊息為 €0.0658，實用及驗證訊息為 €0.0248。 **2026 年意大利的實用訊息費率有調整嗎？** 沒有。2026 年 7 月 1 日的更新只調高了意大利的推廣訊息費率。 **回覆意大利客戶需要收費嗎？** 在 24 小時客戶服務時段內的自由格式回覆免費。在該時段以外發送的訊息範本，於送達時收費。 **我的員工還可以繼續使用應用程式嗎？** 可以。Coexistence 讓 WhatsApp Business 應用程式在同一個號碼上繼續運作，而經應用程式發出的訊息仍然免費。 --- ## 如何停用 Coexistence，改為只使用 WhatsApp Business 應用程式 https://easycoexistence.com/zh-hant/docs/disconnecting-coexistence Coexistence 須在 WhatsApp Business 應用程式內停用：設定、帳戶、Business Platform，然後選擇「中斷帳戶連接」。應用程式會繼續使用該號碼，供應商的存取權限隨即終止，並會發送帶有 PARTNER_REMOVED 的 account_update Webhook。Cloud API 的 Deregister 端點不能用於同時在兩邊運作的號碼。 ### 如何停用 Coexistence？ 請在持有該號碼的手機上操作。當號碼與 WhatsApp Business 應用程式共用時，Meta 只記載了一個讓商家退出 Cloud API 的途徑，而這個途徑是透過應用程式進行，並非透過任何控制台或端點。決定權在持有主要手機的人手上，因此代理商或開發人員須請商家自行操作。 - 在主要裝置上開啟 WhatsApp Business 應用程式。 - 前往「設定」，然後選擇「帳戶」，再選擇 Business Platform。 - 點選「中斷帳戶連接」並確認。 - 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 停用的功能，例如廣播清單，請參閱有關已停用功能的頁面。 ### 日後可以再次連接該號碼嗎？ 可以，從頭重新進行 onboarding 流程即可。Meta 的文件也將解除連接後重新完成流程視為重設連接的正常做法，例如錯過了 24 小時內同步聯絡人和記錄的時限。 重新連接等同一次新的 onboarding，因此首次被問及的問題會再問一次，包括是否分享聊天記錄。舊連接上設定的內容，例如 Webhook 覆寫，必須重新套用。如果號碼要轉移至另一個供應商，做法相同：先在此中斷連接，再與新供應商進行 onboarding。 - 對 Coexistence 號碼呼叫 Deregister 端點。Meta 會拒絕，中斷連接須在應用程式內進行。 - 為了退出而刪除 WhatsApp Business 應用程式帳戶。這正是會遺失聊天記錄的做法。 - 把 PARTNER_REMOVED 當作故障而重試。這是商家刻意作出的中斷連接。 **中斷連接後，我會遺失聊天記錄嗎？** 不會。中斷連接只是把 API 從號碼移除，並不會刪除 WhatsApp Business 應用程式帳戶，而後者才是 Meta 警告會遺失記錄的操作。 **可以透過 API 中斷連接嗎？** 不可以。對於同時用於 Cloud API 和應用程式的號碼，Meta 不允許使用 Deregister 端點。 **我的系統如何得知已中斷連接？** 商家中斷連接時，Meta 會發送帶有 PARTNER_REMOVED 事件的 account_update Webhook。 **可以重新連接同一個號碼嗎？** 可以。從頭重新進行 onboarding 流程，與首次連接相同。 --- ## 將號碼由 Coexistence 轉為僅使用 Cloud API https://easycoexistence.com/zh-hant/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」。 - 刪除應用程式帳戶：「設定」、「帳戶」、「刪除我的帳戶」，然後最多等候 3 分鐘。 - 使用 6 位數的兩步驟驗證 PIN，在 Cloud API 註冊該號碼。 ### 企業會失去甚麼？ 手機上的對話，以及以手機作為回覆途徑的做法。 Meta 表明，刪除 WhatsApp Business 應用程式帳戶並在 Cloud API 註冊號碼後，現有的訊息記錄會遺失。這與 Coexistence 的啟用流程相反：Meta 指出該流程會保留記錄，而且兩個應用程式可同時運作。 此外，除非先從 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-hant/docs/migrating-a-number-from-another-provider 這取決於號碼目前的連接方式。透過其他供應商與 WhatsApp Business 應用程式共用的號碼，需先在應用程式內中斷連接，再由新供應商重新接入。純 API 號碼則透過 Meta 的電話號碼遷移進行，顯示名稱、品質評級、發送訊息上限及 Official Business Account 狀態都會保留。 ### 我屬於哪一種情況？ 只需問一個問題：現在仍有人在手機上用 WhatsApp Business 應用程式回覆這個號碼嗎？ 如果有，這個號碼就是與現有供應商使用 Coexistence，由應用程式持有該號碼。離開該供應商要在應用程式內操作，加入新供應商則是一次全新的 Coexistence 接入。 如果沒有，這個號碼只登記在 Cloud API 上，背後沒有應用程式。Meta 為此設有另一套遷移流程，可將號碼由一個合作夥伴的 WhatsApp Business 帳戶移到另一個，無需從頭重新登記。把兩者混為一談，是遷移中途卡住的常見原因。 ### Coexistence 號碼如何更換供應商？ 先中斷連接，再重新接入。Meta 文件指出，商戶須在應用程式的「設定」、「帳戶」、「Business Platform」下，按 Disconnect Account 按鈕來中斷與 Cloud API 的連接，而供應商會收到帶有 PARTNER_REMOVED 的 account_update Webhook。 中斷連接後，這個號碼就回復為普通的 WhatsApp Business 應用程式號碼，新供應商可透過 Embedded Signup 為它接入。條件與一般 Coexistence 相同：應用程式版本要夠新、您是 Business Portfolio 的管理員，以及沒有其他供應商仍然連接著。系統會再次詢問是否共享歷史記錄，24 小時的同步期亦會由新的接入起重新計算。 ### 純 API 遷移會保留什麼？ 保留的內容比多數人預期的多，這正是設有遷移流程、而非刪除後重新登記的原因。號碼在客戶心目中累積的信譽得以保留，只有範本的品質記錄會重新開始。 - 顯示名稱、品質評級、發送訊息上限及 Official Business Account 狀態均會保留。 - 符合資格的範本會複製到目標帳戶，狀態維持不變。 - 已上載到該號碼的媒體檔案仍可使用。 - 範本品質評級不會沿用：所有遷移後的範本都從 UNKNOWN 開始。 ### 純 API 遷移前須準備什麼？ Meta 對雙方都列出了條件，而客戶一方的條件正是遷移最容易卡住的地方。 商戶的 Meta Business Portfolio 須已通過驗證，現有的 WhatsApp Business 帳戶須已獲批准，並綁定有效的付款方式。號碼必須已停用兩步驟驗證，而 Meta 沒有提供停用它的 API 端點，因此供應商無法透過 API 完成這一步。在接收一方，目標帳戶上至少要有一個應用程式已訂閱 Webhook。 在新帳戶上的登記是即時的，訊息發送不會中斷，但範本複製需要時間，受影響的範本要等副本建立後才能使用。 - 舊供應商仍連接著，就由新供應商接入。必須先在應用程式內中斷該號碼的連接。 - 在兩步驟驗證仍開啟時開始純 API 遷移。Meta 要求先停用，而且沒有任何端點可以代為處理。 - 期望範本品質評級得以保留。遷移後的範本會從 UNKNOWN 重新開始。 **更換 Coexistence 供應商會遺失對話嗎？** 不會，應用程式全程保留對話。接入時會再次詢問是否與新連接共享歷史記錄。 **純 API 遷移會更改我的顯示名稱嗎？** 不會。Meta 會保留顯示名稱、品質評級、發送訊息上限及 Official Business Account 狀態。 **為什麼我的範本失去了品質評級？** Meta 會把範本複製到目標帳戶，而每個副本的起始評級都是 UNKNOWN。 **遷移期間會停止服務嗎？** Meta 表示，純 API 遷移的登記是即時的，訊息發送不會中斷。範本複製完成後即可使用。 --- ## Coexistence 號碼上的 WhatsApp 群組與 API https://easycoexistence.com/zh-hant/docs/whatsapp-groups-and-the-api Meta 的 Groups API 讓 Cloud API 號碼建立小型的僅限邀請群組並向群組發送訊息，但 Meta 明確表示它不適用於 WhatsApp Business 應用程式的電話號碼，而 Coexistence 號碼正是這類號碼。應用程式內現有的群組也不會同步。在共用號碼上，群組仍然只是應用程式專屬的功能。 ### WhatsApp 有 Groups API 嗎？ 有。Meta 的 Groups API 讓企業在 Cloud API 號碼上建立、列出及更新群組，向群組發送文字、媒體及訊息範本，管理邀請連結，批准或拒絕加入請求，以及移除參與者。 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 群組發送訊息嗎？** 只有持有 Official Business Account 的純 API 號碼，才可以使用 Groups API 做到。Coexistence 號碼不可以。 **我現有的群組還能使用嗎？** 可以，在 WhatsApp Business 應用程式內使用。它們不會同步到 API。 **API 群組最多可以有多少人加入？** Meta 規定透過 Groups API 建立的群組上限為 8 位參與者。 **這是我的服務供應商的限制嗎？** 不是。Meta 對所有服務供應商一律排除 WhatsApp Business 應用程式號碼。 --- ## Meta Verified 與 Coexistence 號碼上的官方商業標誌 https://easycoexistence.com/zh-hant/docs/meta-verified-and-coexistence 兩種不同的東西都被稱為藍色標誌。官方商業帳戶（OBA）是為 Cloud API 號碼申請的狀態，而 Meta 文件指出，不會授予 WhatsApp Business 應用程式號碼。Meta Verified for WhatsApp Business 是在應用程式內訂閱的服務，包括驗證標誌、多名客服代理存取及加強支援。 ### 官方商業帳戶是什麼？ 這是登記在 WhatsApp Business Platform 上的商業電話號碼所具有的狀態。Meta 形容這是由經驗證為真實的企業所擁有的號碼，在聯絡人檢視中，名稱旁會顯示藍色剔號。您可在 WhatsApp Manager 的號碼個人檔案下申請，或透過 API 的 official_business_account 欄位申請。 - 企業遵守 WhatsApp Business Messaging Policy。 - 已在平台上登記至少 30 天。 - 其 Business Portfolio 已通過 Business Verification。 - 號碼已啟用兩步驟驗證，且顯示名稱已獲批准。 ### Coexistence 號碼可以取得 OBA 狀態嗎？ Meta 的 OBA 文件指出，不會向企業員工、測試帳戶及 WhatsApp Business 應用程式號碼授予 OBA 狀態。Meta 在其 Groups API 頁面使用同一個詞語，即 WhatsApp Business 應用程式號碼，並連結到讓 WhatsApp Business 應用程式用戶上線的指南，而那正是 Coexistence。 Meta 沒有就應用程式與 API 共用的號碼另行公布規則，因此文件所載的立場就是上述內容。申請被拒後，可在 30 天後重新提交，期間商業檔案仍可編輯。 ### Meta Verified for WhatsApp Business 是什麼？ 這是透過 WhatsApp Business 應用程式辦理的付費訂閱，與平台的 OBA 流程分開。Meta 的資源頁面列出其內容：驗證標誌、自訂網頁、加強支援、可連接多部裝置並將聊天分配給銷售代理的多代理帳戶，以及最多 10 個 WhatsApp Channels 上的驗證標誌。 由於是在應用程式內購買，它屬於 Coexistence 號碼的應用程式一方。Meta 的頁面要求企業在訂閱前確保商業資料及帳戶資料是最新的，而且該頁面沒有公布固定價格。 ### 更換號碼後，標誌會保留嗎？ 就 OBA 而言，Meta 明確記載了一種情況：透過 Embedded Signup 由一個 Solution Partner 遷移到另一個 Solution Partner 的電話號碼，會保留其顯示名稱、品質評級、訊息上限及官方商業帳戶狀態。 至於更換號碼本身，並無同類說明。OBA 屬於特定的商業電話號碼，所以換了號碼就等於另一次申請。顯示名稱獲批准是 OBA 的條件之一，因此更改名稱最好在申請之前規劃，而不是之後。 - 把 OBA 和 Meta Verified 當成同一個標誌。一個是平台狀態，另一個是應用程式訂閱。 - 在平台登記未滿 30 天就申請 OBA。Meta 要求最短 30 天，被拒後便要再等 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-hant/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-hant/docs/linked-devices-and-coexistence 將 WhatsApp Business 應用程式號碼接入 Cloud API 時，帳戶上所有附屬裝置都會被取消連結。受支援的附屬裝置，例如 WhatsApp Web 及以附屬裝置方式連結的手機，之後可重新連結。Coexistence 號碼不支援 WhatsApp for Windows 和 WhatsApp for WearOS，而閒置約 30 天的附屬裝置會中斷連接。 ### 接入期間，已連結裝置會怎樣？ 它們全部會被登出。Meta 的文件指出，企業以現有 WhatsApp Business 應用程式帳戶和號碼接入 Cloud API 後，所有附屬應用程式都會與帳戶取消連結，之後企業可重新連結任何受支援的附屬應用程式。 這不會造成任何損失：主要手機仍保留帳戶及其對話。但如果前台人員用瀏覽器或第二部手機回覆客戶，接入一完成就會發現已被登出，所以最好在掃描 QR code 之前通知團隊，而不是事後才說。 ### 之後有哪些附屬裝置受支援？ 除了兩個之外，全部都支援。Meta 列明，除了 WhatsApp for Windows 和 WhatsApp for WearOS，其餘附屬用戶端都可用於 Coexistence 號碼。每個受支援的裝置都以一貫方式重新連結，即用主要手機掃描 QR code，並與之前計入同一個裝置上限。 - 瀏覽器中的 WhatsApp Web：支援，以 QR code 重新連結。 - 以附屬裝置方式連結的其他手機：支援。 - WhatsApp for Windows：不支援。 - 手錶上的 WhatsApp for WearOS：不支援。 ### 最多可連結多少個裝置？ 除主要手機外，最多 4 個。WhatsApp 在公布手機多裝置功能時，說明連結手機屬於最多 4 個額外裝置之一，與網頁瀏覽器、平板電腦和桌面電腦相同，並指出其用途是讓小型企業員工用自己的手機回覆客戶。 在 Coexistence 號碼上，這個上限由仍受支援的附屬用戶端共用。以往使用 Windows 應用程式的辦公室，通常會把這些座位改用瀏覽器中的 WhatsApp Web，它與其他附屬裝置一樣佔用 4 個名額之一。 ### 甚麼會令已連結裝置保持連接？ 有兩條閒置規則，分別針對兩類裝置，兩者都會在 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，不佔用附屬裝置名額。 **我可以連結多少個附屬裝置？** 除主要手機外最多 4 個，涵蓋 Meta 支援的各類附屬用戶端。 --- ## 更改 Coexistence 連接的電話號碼 https://easycoexistence.com/zh-hant/docs/changing-the-phone-number 一個 Coexistence 連接只屬於一個電話號碼。當業務在 WhatsApp Business 應用程式中更改號碼，Meta 會以原因 CHANGE_NUMBER 中斷該連接。新號碼在平台上是另一個獨立的商業電話號碼，必須以新連接的身分重新走一次 Coexistence 流程。 ### 號碼更改後，連接會怎樣？ 連接會終止。Meta 把更改電話號碼列為 Coexistence 連接被中斷的原因之一，並在 account_update Webhook 的 disconnection_info 中以原因 CHANGE_NUMBER 回報。 這是平台的一致做法，而非特別嚴格。API 端所知道的一切，都以商業電話號碼為鍵：它的電話號碼 ID、顯示名稱、品質評級和 Webhook 訂閱。不同的號碼就是不同的資產，所以附在舊號碼上的內容不會自動轉移，而舊連接會在更改號碼的一刻停止運作。 ### 如何連接新號碼？ 以首次連接的方式處理。新號碼必須符合與任何加入 Coexistence 的號碼相同的條件，然後從頭開始開通。舊連接的內容完全不會沿用，因此建議把轉換當作一個有日期的小型項目來安排。 - 號碼已在 WhatsApp Business 應用程式中啟用，且版本為 2.24.17 或以上。 - 號碼位於您擔任管理員的 Business Portfolio 內。 - 號碼沒有附屬於其他供應商。 - 與任何商業電話號碼一樣，須在註冊時提供顯示名稱。 ### API 端需要更新哪些內容？ 所有儲存了舊號碼或其 ID 的地方。透過 Cloud API 發送的整合，是以電話號碼 ID 為目標，因此仍指向舊 ID 的 CRM、自動化工作流程或 AI 代理會直接失敗，而不會自動切換。 新連接也會重新出現開通時的各項問題，包括是否分享聊天記錄，以及同步記錄的 24 小時時限。在舊連接上設定的 Webhook 目的地，必須重新套用到新連接。容量也值得檢查：在驗證完成或達到 2,000 的訊息上限之前，Meta 把新 Business Portfolio 限制為最多 2 個已註冊的商業電話號碼。 ### 舊號碼在平台上會怎樣？ 在有人移除之前，它仍是 WhatsApp Business Account 內的資產。Meta 只允許 Business Portfolio 管理員刪除商業電話號碼，而且若該號碼在過去 30 天內曾用於發送付費訊息，系統會拒絕刪除。 刪除屬於可選的整理工作，並非連接新號碼的必要條件，但帳戶內留有過時的號碼，會令系統容易繼續向錯誤的號碼發送訊息。待 30 天過後再移除，可讓帳戶保持清晰易讀。 - 未規劃好重新連接，就先在應用程式中更改號碼。舊連接會在那一刻終止。 - 在整合中保留舊的電話號碼 ID。發送會失敗，而不會跟隨新號碼。 - 轉換後立即嘗試刪除舊號碼。若它在 30 天內曾發送付費訊息，Meta 會阻止刪除。 **連接會跟隨我的新號碼嗎？** 不會。Meta 會以原因 CHANGE_NUMBER 中斷連接，新號碼須以新連接的身分重新開通。 **我需要新的電話號碼 ID 嗎？** 需要。新號碼在平台上是另一個獨立的商業電話號碼，擁有自己的 ID。 **我可以立即刪除舊號碼嗎？** 只有在過去 30 天內沒有發送過付費訊息時才可以，而且只有 Business Portfolio 管理員能刪除。 **我需要重新選擇顯示名稱嗎？** 需要。註冊商業電話號碼時，Meta 要求提供顯示名稱資料。 --- ## Meta 商家驗證與 Coexistence 號碼 https://easycoexistence.com/zh-hant/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。 - Official Business Account 資格：擁有該號碼的 Business Portfolio 必須先通過驗證，才可申請藍色剔號。 - 以上三項都不會改變 WhatsApp Business 應用程式在手機上的運作方式。 ### 驗證如何套用於 Coexistence 號碼？ 透過 Business Portfolio 套用。透過 Coexistence 連接的號碼，位於屬於某個 Meta Business Portfolio 的 WhatsApp Business 帳戶之內，而驗證是該 Business Portfolio 的屬性。其中所有號碼共用驗證結果，以及該 Business Portfolio 的訊息發送上限。 藍色剔號的條件則較窄。Meta 的 Official Business Account 頁面指出，不會向 WhatsApp Business 應用程式的電話號碼等授予該狀態，亦沒有另外說明同時使用應用程式及 Cloud API 的號碼。其他資格條件包括：通過驗證、在平台上至少 30 天、號碼已啟用兩步驟驗證，以及顯示名稱已獲批准。 ### 應該驗證哪一個 Business Portfolio？ 驗證擁有 WhatsApp Business 帳戶的那一個。商家連接自己的號碼時，應該使用商家本身的 Business Portfolio。 這對代理商尤其重要。如果客戶的號碼連接在代理商的 Business Portfolio 內，適用的就是代理商的驗證、上限及號碼上限，而客戶的上限會與代理商在其中持有的所有其他號碼共用。Meta 明確指出，一個號碼可以在特定期間內用盡 Business Portfolio 的全部訊息發送能力。 讓每家商家都連接在自己的 Business Portfolio 內，驗證、上限及帳單便會歸於實際發送訊息的商家。 - 等到驗證完成才連接號碼。沒有驗證也可以在起始上限內發送訊息。 - 驗證了與擁有 WhatsApp Business 帳戶不同的 Business Portfolio。驗證結果不會轉移。 - 把多個客戶的號碼放在同一個代理商 Business Portfolio 內。它們會共用同一個訊息發送上限及號碼上限。 **使用 Coexistence 需要商家驗證嗎？** 不需要。Business Portfolio 未經驗證也可以發送訊息，起始上限為滾動 24 小時內 250 個不重複收件人。 **驗證後就會獲得藍色剔號嗎？** 不會自動獲得。驗證只是 Official Business Account 狀態的其中一項要求，該狀態須另行申請，並由 Meta 審核。 **驗證是按號碼計算的嗎？** 不是。驗證屬於 Meta Business Portfolio，該 Business Portfolio 內的所有號碼共用驗證結果。 **驗證會改變我手機上的應用程式嗎？** 不會。驗證改變的是平台上限及資格，不會影響 WhatsApp Business 應用程式的運作方式。 --- ## WhatsApp 訊息上限：現行 Business Portfolio 層級 https://easycoexistence.com/zh-hant/docs/messaging-limits-and-tiers 訊息上限限制企業在移動 24 小時內，於客戶服務時段以外可向多少位不同的人傳送訊息。自 2025 年 10 月 7 日起，上限按 Meta Business Portfolio 設定，由其中所有號碼共用，起步為 250，其後依次升至 2,000、10,000、100,000 及無上限。 ### 訊息上限實際計算什麼？ 計算的是您的企業在移動 24 小時內，於客戶服務時段以外成功傳送訊息的不同 WhatsApp 使用者電話號碼數目。按這個定義，有三點需要留意。 在已開啟的客戶服務時段內回覆，不會計入上限，所以只回覆主動來信者的號碼，可以遠超上限運作而不受影響。向同一人傳送多個範本，只計算該人一次。而且時段是移動的，並非以日曆日計，因此最早的傳送滿 24 小時後，額度會逐步釋出。 上限針對的是您首次接觸多少人，而不是傳送的速度或總量。 ### 2025 年 10 月有什麼改變？ 2025 年 10 月 7 日之前，每個電話號碼各有自己的上限，新號碼不論同組其他號碼已達到什麼層級，一律由 250 起步。自此之後，上限屬於 Business Portfolio，其中所有號碼共用。 - 新註冊的號碼會立即共用 Portfolio 的上限。 - 250 之後的第一級是 2,000，以往是 1,000。 - 符合條件後 6 小時內提升，以往需時 24 小時。 - 號碼的品質評級下降，不再導致上限被降級。 - 應讀取的欄位是 whatsapp_business_manager_messaging_limit，messaging_limit_tier 已棄用。 ### 上限如何提升？ 分兩個階段。要脫離 250，Portfolio 須完成其中一條擴展途徑：驗證企業、由開通合作夥伴驗證企業，或在 30 天內使用高品質評級的範本，向不同收件人於客戶服務時段以外傳送 2,000 則訊息。Meta 隨後審核訊息品質並批准或拒絕，拒絕時會以 account_alerts webhook 通知，並指明可改用的途徑。 由 2,000 起，擴展是自動的。當 Portfolio 在所有號碼及範本上都傳送高品質訊息，並在過去 7 天內用掉至少一半現有上限，Meta 便會將 Portfolio 提升一級。無須付費，也無須提出申請。 ### 訊息上限與吞吐量有何不同？ 上限計算每日接觸的人數，吞吐量計算每秒傳送的訊息數量。兩者分開設定，也分開出現問題。 在 Coexistence 號碼上，這分別尤為明顯。Meta 將同時用於 WhatsApp Business 應用程式及 Cloud API 的號碼，吞吐量固定為每秒 20 則訊息，以便與該應用程式相容。這個數字不會隨 Portfolio 的層級改變，所以即使 Portfolio 的訊息上限為無上限，Coexistence 號碼仍然以每秒 20 則傳送。 每秒上限、每名收件人上限及管理呼叫上限，各有專頁及各自的錯誤代碼。 - 讀取 messaging_limit_tier。此欄位已棄用，現行欄位是 whatsapp_business_manager_messaging_limit。 - 以為每個新號碼都由 250 起步。自 2025 年 10 月起，新號碼會立即沿用 Portfolio 的上限。 - 將回覆計入上限。在已開啟的客戶服務時段內傳送的訊息，不屬於上限範圍。 - 讓某一個號碼的推廣活動耗盡其他號碼的額度。整個 Portfolio 共用同一個上限。 **上限是按號碼還是按帳戶計算？** 自 2025 年 10 月 7 日起按 Meta Business Portfolio 計算，Portfolio 內所有號碼共用。 **客戶的回覆會計入我的上限嗎？** 不會。只有在客戶服務時段以外成功傳送的訊息才計算，而每名不同收件人在每個移動 24 小時內只計一次。 **品質評級偏低會降低我的上限嗎？** 自 2025 年 10 月起不會。Meta 已不再因品質下降而降級上限，不過品質仍然決定上限能否提升。 **較高的層級會提升 Coexistence 的吞吐量嗎？** 不會。無論處於哪一層級，Coexistence 號碼的吞吐量都固定為每秒 20 則訊息。 --- ## Coexistence 號碼上的產品目錄 https://easycoexistence.com/zh-hant/docs/catalog-and-coexistence 透過 Coexistence 連接號碼後，WhatsApp Business 應用程式內的目錄、訂單和狀態工具在應用程式中維持不變，而 Cloud API 不會開放這些應用程式工具。透過 API 傳送的產品訊息，使用的是上載至 Meta 並連接到 WhatsApp Business 帳戶的目錄，並按每個電話號碼分別設定。 ### 我的 WhatsApp Business 應用程式目錄在 Coexistence 之後還會保留嗎？ 會，在手機上保留。Meta 的 Coexistence 功能對照表把商業工具列為例子，包括目錄、訂單和狀態，開通後這些工具在 WhatsApp Business 應用程式中的運作方式沒有改變。 同一行也註明 Cloud API 不支援這些工具。這是規劃時需要留意的地方：整合方案不應預期可以透過 API 讀取、編輯或同步應用程式的目錄工具。 因此，一直透過應用程式目錄銷售的商店，連接後仍然可以照舊運作。不同的是，商店同時多了 API 這個管道，並有自己的產品傳送方式。 ### 產品目錄如何透過 Cloud API 運作？ 透過上載至 Meta 並連接到 WhatsApp Business 帳戶的目錄。目錄是產品或服務的結構化清單，每個項目都包含名稱、說明、價格、圖片和供應狀況等資料。Meta 說明了四個階段。 - 上載庫存，可透過 Commerce API 或 Meta Commerce Manager 進行。 - 按每個電話號碼設定商務功能：是否啟用購物車，以及目錄是否可見。 - 以目錄、單一產品、多項產品或輪播訊息分享產品。 - 客戶回應，以 Webhook 通知形式送達，內含訂單詳情和產品查詢。 ### 應用程式與 API 的產品訊息有何不同？ Meta 記載了一個明顯的差異：透過 Cloud API 傳送的訊息，目前不會在對話標題列顯示購物車圖示，而從 WhatsApp Business 應用程式傳送的產品訊息則會顯示。 API 方面也有應用程式沒有以相同方式提供的設定。預設情況下，帳戶內每個商業電話號碼都啟用購物車，並隱藏店面圖示，兩者都可以透過商務設定端點按號碼切換。停用目錄後，點按 wa.me 目錄連結和「查看目錄」按鈕時，會顯示目錄無效的警告。 在客戶服務時段以外，產品仍須放在已核准的訊息範本內傳送，與其他由商家發起的訊息相同。 ### 誰負責審核產品？ 由 Meta 自動審核。加入已連接 WhatsApp Business 帳戶的目錄的項目都會經過審核，違反政策的項目會被標記，並引導商家參閱 WhatsApp 商務政策。遭拒絕的項目可在 Meta Commerce Manager 提出申訴。 客戶也可以舉報在訊息中收到的特定產品，這會觸發另一次審核。針對商家本身的舉報則屬另一回事：這是 Meta 評定號碼品質評級所用的訊號之一。 印度的商家另有遵守網上銷售法律的義務，Meta 透過其 Business Compliance API 處理這方面的要求。 - 預期可以透過 API 讀取應用程式的目錄工具。Meta 列明 Cloud API 不支援該工具。 - 在 wa.me 目錄連結仍在流傳時，停用號碼的目錄。這些連結之後會顯示目錄無效的警告。 - 在客戶服務時段以外，不使用訊息範本就傳送產品。由商家發起的訊息仍然需要使用範本。 **連接後會刪除我的目錄嗎？** 不會。Meta 列明，Coexistence 開通後，應用程式的商業工具（包括目錄）維持不變。 **API 可以讀取我的應用程式目錄嗎？** Meta 註明 Cloud API 不支援應用程式的商業工具。API 的產品訊息使用連接到 WhatsApp Business 帳戶的目錄。 **一則訊息可以放多少件產品？** 多項產品訊息最多 30 件，並按分區整理。 **我可以關閉購物車嗎？** 可以，透過商務設定端點按電話號碼設定。購物車預設為啟用。 --- ## Coexistence 之後的廣播名單與推廣訊息範本 https://easycoexistence.com/zh-hant/docs/broadcast-lists-vs-templates 號碼透過 Coexistence 連接後，WhatsApp Business 應用程式的廣播名單會變成唯讀，也無法建立新名單。API 的對應做法是向每位收件人傳送推廣訊息範本：需要對方選擇加入，會計入 Business Portfolio 的訊息上限，由 Meta 收費，並須尊重每個人的推廣偏好。 ### 在 API 上，什麼取代廣播名單？ 取代的是已通過審批的推廣訊息範本，經 Cloud API 向每位收件人各傳送一次。API 沒有名單這種物件：受眾由整合方自行保存，再把範本逐一傳送到名單內的每個號碼。 這會同時帶來三項改變。內容須先經 Meta 的範本審核才能傳送。每次在客戶服務時段以外傳送，都會開啟一個對話，由 Meta 向商家自己 WhatsApp Business Account 上的付款方式收費。而每位不重複的收件人，都會計入 Business Portfolio 在滾動 24 小時內的訊息上限。 至於功能被停用的細節，以及 Meta 給出的原因，請參閱介紹 Coexistence 會關閉哪些功能的頁面。 ### 誰可以收到推廣訊息範本？ 只限曾向商家提供號碼，並已選擇加入接收其訊息的人。Meta 的 Business Messaging Policy 明確要求這兩個條件，而且選擇加入的聲明必須點名商家，並說明對方同意接收該商家的訊息。 只要符合這些要求及適用法律，Meta 不限制收集方式：SMS、網站表單、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-hant/docs/opt-in-requirements 企業在 WhatsApp 上向某人傳送訊息前，Meta 政策要求兩項條件：對方已向企業提供電話號碼，而企業已取得對方確認願意接收其訊息的同意。自 2024 年 11 月起，同意可以是一般性的，不必特指 WhatsApp，但必須列明企業名稱並符合當地法律。 ### Meta 的同意接收政策有什麼要求？ 兩項條件必須同時成立，企業才可在 WhatsApp 上聯絡對方。第一，對方已向企業提供其手提電話號碼。第二，企業已取得對方的同意，確認對方願意接收企業其後發出的訊息或來電。 同意本身有三項要求。必須清楚說明對方同意接收來自該企業的通訊。必須清楚列明企業名稱。必須符合適用法律，而 Meta 把這一點完全交由企業自行判斷。 Meta 在 2024 年 11 月更新政策，放寬了一點：只要遵守當地法律，同意可以是一般性的，毋須提及 WhatsApp。 ### Meta 接受哪些取得同意的方式？ 只要符合上述三項要求，任何方式均可。Meta 表明這類方式符合政策，選擇權交給企業，並列出了數種獲支援的方式。無論採用哪一種，Meta 也建議向對方說明接收這些訊息有什麼好處。 - 短訊（SMS）。 - 網站表格。 - 透過互動式語音回應流程，以電話取得。 - 親身或以紙本方式，由對方簽署實體文件。 - 無論採用哪種方式，企業都須負責履行適用法律所要求的通知及授權。 ### WhatsApp Business 應用程式裏的聯絡人算是已同意嗎？ 單憑這一點並不算。Meta 的政策把許可與對方確認願意接收企業訊息掛鈎，而聯絡人名單中的電話號碼，最多只滿足兩項條件中的第一項。 這對 Coexistence 號碼尤其重要，因為連接後可以同步應用程式中的聯絡人，而現有客戶群正是首次推出訊息範本推廣活動的明顯對象。擁有對方的號碼，不等於取得對方的確認。 客戶主動聯絡企業則是另一回事：對方的訊息會開啟客戶服務時段，企業可以在時段內回覆。 ### 同意接收的做法不夠嚴謹會有什麼後果？ 收件人會作出反應，而平台會根據這些回饋採取行動。Meta 的指引指出，用戶可以封鎖或舉報企業，或停止接收其推廣訊息，而當企業的品質評級長期偏低，系統會限制其傳送量。 Meta 的實務建議由此而來。說明企業會發送的訊息類別以建立預期，或按類別分別取得同意。清楚指引對方如何取消接收特定類別，並確實照辦。讓同意及取消接收的流程一目了然，並在新的取得同意方式上線時密切留意品質評級。 政策亦要求尊重每一項封鎖、停止或取消接收的要求，不論是否在 WhatsApp 上提出，並須把該人從聯絡人名單中移除。 - 把同步的應用程式聯絡人當作已同意名單。政策要求每個人的確認，而不只是他們的號碼。 - 取得同意時從未列明企業名稱。Meta 要求清楚說明企業名稱。 - 只在取消接收要求經 WhatsApp 送達時才照辦。政策涵蓋透過任何渠道提出的要求。 **同意內容一定要提及 WhatsApp 嗎？** 毋須。自 2024 年 11 月政策更新起，一般性同意已獲允許，前提是符合當地法律。 **回覆先傳來訊息的客戶需要同意接收嗎？** 客戶的訊息會開啟客戶服務時段，企業可在時段內回覆。同意接收規範的是企業主動發起的訊息。 **可以在線下取得同意嗎？** 可以。Meta 列出親身或以紙本方式，由對方簽署文件，屬於接受的方式之一。 **有人取消接收時應該怎樣處理？** 停止向對方發送訊息，不論對方經哪個渠道提出，並按政策要求把對方從聯絡人名單中移除。 --- ## 封鎖與舉報如何影響 WhatsApp 品質評級 https://easycoexistence.com/zh-hant/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 中，並在「管理範本」面板中顯示為 High、Medium、Low 或 Quality pending。 手機上的 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-hant/docs/gdpr-and-coexistence 號碼透過 Coexistence 連接後，其訊息會在 WhatsApp Business 應用程式與 Cloud API 之間同步鏡像。Meta 表示，就 Cloud API 而言，它代表商家擔任資料處理者，訊息最多保留 30 天，並預期每家商家自行履行其 GDPR 義務。 ### 號碼使用 Coexistence 後，訊息資料有什麼變化？ 對話除了在手機上可見，Cloud API 也能看到。Meta 的 Coexistence 文件指出，收發的訊息會在 Cloud API 與 WhatsApp Business 應用程式之間鏡像，已使用 WhatsApp 的聯絡人可以同步，而最近六個月的聊天訊息可在接入期間同步。群組聊天不會同步。 由此開始，該號碼的一對一訊息會經由 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 義務。 - 接受記錄同步卻沒有決定記錄的落腳處。最多六個月的聊天可能會送到接收系統。 - 打算日後才啟用本地儲存。它在註冊時設定，要更改就必須重新註冊。 **就 Cloud API 而言，Meta 是處理者還是控制者？** Meta 表示，在法律承認該概念之處，它就 Cloud API 代表商家擔任資料處理者。 **Meta 會保留訊息內容多久？** Meta 表示 Cloud API 訊息的最長保留期為 30 天，用於重新傳送等功能。 **EasyCoexistence 看得到我的對話嗎？** 訊息事件由 Meta 直接送往您自己的系統，EasyCoexistence 絕不儲存對話內容。 **本頁屬於法律意見嗎？** 不是。本頁說明 Meta 的文件內容與 EasyCoexistence 的做法。合規與否，須由商家及其顧問評估。