我們即將停用內部部署 API。詳情請參閱內部部署 API 停用文件,並從中了解如何轉用新一代雲端 API。
請瀏覽 WhatsApp Business 平台狀態頁面,了解平台服務中斷情況的最新資訊。
企業 API 用戶如果在其所控制的伺服器上管理 API 端點,WhatsApp 便視其通訊為端對端加密通訊,因為第三方無權存取端點之間的內容。
部分機構可能會選擇委派第三方企業解決方案供應商來管理其 WhatsApp Business API 端點。在此類情況下,通訊仍使用相同的訊號協定加密。但是,由於 WhatsApp Business API 用戶已選擇交由第三方來管理其端點,因此 WhatsApp 將不會視此類訊息為端對端加密。在未來於 2021 年,此做法也將適用於選擇使用由 Facebook 託管的雲端版本 API 之企業。
此外,如果您在向 WhatsApp Business API 用戶端發出調用時使用 HTTPS,系統便會 SSL 加密相關資料 (從後端用戶端至 WhatsApp Business API 用戶端)。
更多詳情請參閱我們的 WhatsApp 加密概覽技術白皮書。
不可以,您只能為每個實例運行一個帳戶。如果您需要第二個測試帳戶,請務必為第二個實例使用不同的電話號碼。
不可以!不管在任何時候,一個手機號碼都只能運行一個 WhatsApp Business API 用戶端實例。一旦您註冊了第二個實例,第一個實例就會被關閉並失效。我們正在研發有效解決方案,以助您做到這個動作。如有任何最新消息,我們會立即通知您。
WhatsApp Business 企業內部 API 用戶端需要使用資料庫來儲存密鑰,以解密商家與顧客之間傳送的訊息。WhatsApp 上的所有訊息均以傳送者和接收者密鑰以作加密處理。顧客密鑰儲存在其流動裝置上,商家密鑰則儲存在其資料庫中。詳情請參閱 WhatsApp 安全。
WhatsApp Business 雲端 API 是 Meta 託管商家資料庫的替代方案。透過使用雲端 API,您可以直接執行 WhatsApp Business API,無需花費成本託管自己的伺服器。了解詳情。
不可以,目前無法在同一個 WhatsApp Business API 用戶端設定中運行多個號碼。我們正在開發妥善的解決方案,以便在未來支援運行多個號碼。
不需要。WhatsApp Business API 用戶端會建立一個連接至 WhatsApp 伺服器端口 5222 或 443 的已發出 TCP 連接。TCP 流量會在此長期連接中產生。通常,防火牆將之分類為允許「已接收流量和已有流量」。當然,一旦建立了連接,套件將會來回傳輸,但由於此連接將由 WhatsApp Business API 用戶端開始建立,因此不需要訂立允許已接收連接的規則。
相關的必要條件取決於您的具體負載和情況。解決方案可在任何運行 Docker 且連接至互聯網的裝置中運作。例如,您可以使用手提電腦來進行簡單的測試。
若是單一實例的正式版伺服器設定,我們建議最少配備 250 GB SSD、16GB RAM 和 4 核 CPU。我們不建議您使用 HDD,因為 I/O 速度會在承受負載時變成阻礙。
若是多點連線的正式版伺服器設定,我們建議每個核心應用程式/主節點/網頁應用程式容器最少配備 50 GB SSD、4 GB RAM 和 2 核 CPU。
在大多數情況下,您應該使用與核心應用程式和網頁應用程式容器分開的實體伺服器來運行數據庫。數據庫伺服器與電腦之間只可有幾毫秒的延遲時間。
此設定支援每秒傳送大約 20 則訊息。
您必須使用 MySQL 5.7.x、PostgreSQL 9.5.x、9.6.x、10.x。使用較舊的版本會導致出現 Unable to initialize config store
錯誤。
請遵循 Docker MySQL 指南的指示,使用 Docker 在本機設定 MySQL。
請遵循 Docker PostgreSQL 指南的指示,使用 Docker 在本機設定 PostgreSQL。
在大多數情況下,您應該使用與核心應用程式和網頁應用程式容器分開的實體伺服器來運行數據庫。數據庫伺服器與電腦之間只可有幾毫秒的延遲時間。
沒有,我們不支援 KOPS。我們支援基於 ECS 的 AWS 解決方案。我們也提供一般 Kubernetes minikube 設定。
我們的系統支援 MySQL 和 PostgreSQL。如果您自行運行 Docker,則必須為要連接的容器提供一個 MySQL/PostgreSQL 資料庫。如果使用 AWS 範本,則系統會預設設定 MySQL 資料庫。
不可以。WhatsApp Business API 用戶端目前無法在 Docker for Windows 中運行。如有開發需要,我們建議您使用 Linux 虛擬機器,並在此虛擬機器中運行 Docker。如需處理正式版負載,我們建議您使用 Linux 伺服器,以避免出現相容性和性能問題。
您可以運行以下程式碼,以重新啟動 Docker 容器:
docker restart wacore<Current_WABA_Version>
docker restart webapp<Current_WABA_Version>
您可以檢查自己正在運行哪個版本
docker ps
是,網頁應用程式容器和核心應用程式容器的記錄輪替將略有不同:
下列指令碼可在外部觸發,以便清除容器的舊記錄:
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
此指令碼同時適用於網頁應用程式容器及核心應用程式容器。運行指令碼後,系統便會移除舊的記錄檔案,並僅保留容器中最近 30 天的記錄檔案。
隨著儲存空間逐漸變滿,您的系統運行速度或會開始變慢。這可能是因為您的影音素材檔案、訊息和大型記錄檔案過多。系統會自動輪替記錄檔案,但如果記錄檔案開始變大,您也可以安心將之刪除。
系統會將訊息儲存至資料庫中。如有需要,您也可以刪除訊息。此外,如果您在應用程式設定中將pass_through
設定為 false,則除非您明確地將之刪除,否則系統會將所有訊息儲存在資料庫。
系統會將用戶傳送給您的影音素材檔案下載至影音素材磁碟區。企業可自行決定刪除哪些影音素材,但一般情況下,您都可安心刪除任何影音素材檔案。您可以使用 docker inspect your-container-id
來查看影音素材磁碟區資料夾的所在位置。
可以。您可以將資料庫用於其他用途,只要不影響與 WhatsApp 相關的表格即可。
資料庫表格會儲存與應用程式設定、聊天室對話串、訊息和影音素材等相關的資訊,而且應用程式必須使用這些資訊才能運作。
資料庫垃圾回收會定期清理 messages
和 messages_reciept_log
表格,以協助管理資料庫。
垃圾回收工具會保留某些訊息,以成功傳送/處理訊息。例如保留特定時間段內已接收的訊息,以便企業整合工具將訊息標記為已讀。
核心應用程式會按照隨機的時間間隔執行垃圾回收(例如每隔幾個小時)。這樣做是為了防止在高可用性堆疊中可能因爭用資料庫而出現效能降低。
垃圾回收與回調佇列無關。例如,如果 4 天無法使用 Webhook 伺服器,系統則會儲存回調,再於 Webhook 伺服器連接恢復時傳送回調。
使用資料庫垃圾回收 services
API 端點,清除 messageStore.messages
和 messageStore.messages_receipt_log
表格中的訊息和相應的訊息接收資料。
只需透過 users
端點將用戶登出,即可令分配至該帳戶的所有身份驗證憑證無效。此外,刪除用戶也有相同的作用,雖然這種做法比較極端。請注意,如要透過 users
端點讓用戶登入,系統將會傳回新的身份驗證憑證,但不會使該用戶已在使用的身份驗證憑證無效。任何擁有先前預先分配的憑證之用戶均可繼續使用該憑證,直至憑證過期,或您透過上述其中一種方法使之變為無效為止。
備註:請勿使用 WhatsApp Business API 向同一位傳送對象重複傳送相同訊息。
訊息送達率不是 100% 的原因有很多種。其中一些常見情況包括:用戶的網絡斷斷續續、用戶在一段時間內沒有任何活動,或建立 優質用戶體驗。
可以透過 WhatsApp 送達的訊息會有非常高的送達率。可是,也有很多原因會導致訊息傳送失敗。您可以監察回呼,以了解訊息的具體狀態。由於您無法存取最後送達狀態,而再次傳送訊息可能反而會產生不同成效,因此這方式有別於短訊等其他訊息傳送方式。
訊息可能會因為用戶手機停機、沒電,或用戶在遺失手機後更換新手機並停用 SIM 卡,而無法送達至用戶。另此,企業的用戶端網絡連線功能也有可能出錯,系統也有可能無法送達回呼(Webhooks)。您可使用此 health
節點監察這些狀況。只需開啟伺服器接收回呼,即可知道訊息有否成功進入 WhatsApp 伺服器雲端。
當用戶重新連接至網絡時,您之前所傳送的所有訊息都將會送達至他們。對用戶而言,重複收到內容相同的訊息會令體驗欠佳。他們較有可能會封鎖或投訴您,而您亦較有可能會被停權。
如果您在傳送訊息後收到了來自 API 的訊息編號,則代表您已經完成可做的操作來傳送此訊息。請勿向同一位傳送對象重複傳送相同內容。
如果您發現送達率長期偏低,請提交支援工作單至 直接支援服務。
當您傳送訊息時,只要您獲得訊息編號,便代表系統已將該訊息要求儲存在資料庫中。WhatsApp Business API 用戶端會不斷嘗試傳送該訊息,直至收到 WhatsApp 伺服器的確認為止。這個過程不設任何結束期限。然後,WhatsApp 伺服器會嘗試將該訊息傳送至用戶的手機。如果用戶的手機不在線,則系統會將訊息存儲在 WhatsApp 伺服器 30 天,然後將之捨棄。
當然可以!請聯絡您的 WhatsApp 代表,以提出此要求。
不能,我們無法保證訊息的送達順序會與它們的傳送順序相同。如果訊息排序對您的使用案例十分重要,則我們建議您先偵聽第一則訊息的送達回調,然後再觸發第二則訊息。
If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.
No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.
如要尋找影音素材磁碟區的掛載點,請運行 Docker 指令。
docker volume inspect whatsappMedia
[ { "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data", "Name": "whatsappMedia", "Options": {}, "Scope": "local" } ]
然後,如要查看全部已接收影音素材檔案,請使用已收到的 Mountpoint
檔案路徑運行 ls
指令:
ls /var/lib/docker/volumes/whatsappMedia/_data/
若是 AWS 設定,您可將影音素材磁碟區掛載至主機的 /mnt/wa/media
路徑。
上載檔案大小不能超過 64 MB,而此限制亦適用於與訊息一同傳送的任何圖像、文件或影片。
您可以自行決定何時刪除影音素材。
上載影音素材後,您將收到一個影音素材編號;您可以使用此編號傳送一則包含已上載影音素材的訊息。傳送影音素材訊息後,WhatsApp Business API 便會將影音素材解碼並上載至 WhatsApp 伺服器,且伺服器會將之保留 14 天。之後,您便可以自行決定刪除此影音素材(方法為提供影音素材編號),還是保留它供日後使用。我們建議將影音素材保留 30 天;您可以根據貴公司的政策或使用案例,自行決定具體保留時間。
如果是圖片,系統會將說明加入為描述。在 Android 和 iPhone 中,系統均會顯示圖片說明的完整文字。
如果是文件,則說明內容會取代檔案名稱。系統並不會在用戶裝置中將之顯示為描述文字,而是會將之顯示為檔案名稱。iPhone 會顯示全部文字,而 Android 則會截斷檔案名稱,這是由於 WhatsApp 在這兩種裝置中當前安裝方面的技術限制所致。
使用 WhatsApp Business API 以相簿形式傳送圖像時,您需要最少連續傳送 4 張圖像。如果用戶收到圖像時,其對話視圖處於活躍狀態,則需要等待至下次存取時才能使用相簿視圖。
如果出現以下任何情況,則將無法建立相簿:
沒有辦法,目前我們必須使用 AWS EFS 才能在核心應用程式和網頁應用程式之間分享媒體影音素材磁碟區。
不可以,目前我們不支援更改影音素材儲存空間的預設路徑 (/usr/local/wamedia/)。所有影音素材儲存空間均需要在預設位置下才能正常運作。
目前的快取週期為 7 天。如果 7 天後快取仍未有更新,則不論套件內是否有相應的元素,系統均會從伺服器擷取最新的語言套件。
請注意:由 v2.27.8
開始,fallback
語言政策已停用,現時的預設政策為 deterministic
語言政策。
建立新語言的翻譯時,您必須將您使用的所有元素翻譯成該語言。否則,您可能會因為接收人的手機無法找到其支援語言的某個元素,而收到「無法使用此結構」錯誤。此類「無法使用此結構」錯誤會在使用 Fallback 政策傳送範本訊息時顯示。
如果您暫時不想建立語言翻譯,則可以使用 Deterministic 政策,以避免出現此類錯誤。
WhatsApp Business API 用戶端會透過核心應用程式容器向您傳送 Webhook 回調。因此,您需要配置您的 Webhook 端,以便它接收來自核心應用程式的已接收要求。
如果 Webhook 無法傳送回調,系統便會將該回調置於重試佇列中。系統無法接收在初始回調失敗後發出的任何回調。失敗的初始回調必須傳送成功,系統才可接收其餘的回調。
如果 Webhook 事件由於任何原因而無法送達(例如用戶已離線),或 Webhook 要求傳回 200
以外的 HTTP 狀態碼,則我們將嘗試再次傳送 Webhook。我們將繼續嘗試傳送,並將延遲時間增加到特定逾時期限(一般為 24 小時,但亦可能會有所不同),或直至傳送成功。
為了確保用戶最少收到訊息一次(而非只收到一次),系統或會向 WhatsApp Webhook 傳送重複的訊息。如果這個做法影響了您的訊息處理方式,我們建議您按訊息編號為 Webhook 訊息刪除重複資料。
再次檢查 pass_through
應用程式設定。如果您已在 WhatsApp Business API 用戶端 v2.29.1
或更高版本中啟用 pass_through
,將無法接收任何讀取狀態回調。
如果您想接收讀取狀態回調,請停用 pass_through
應用程式設定。請注意,停用 pass_through
後,資料庫儲存空間會快速增加。如需有關管理資料庫的詳細資訊,請參閱資料庫管理文件。
這是由舊版 iOS 用戶端的一個錯誤引起的失敗訊息。隨著一般用戶升級其用戶端,此錯誤的出現頻率應會逐漸減少。
這是一個已知的問題。有時候,當使用 CloudFormation 指令碼升級 WhatsApp Business API 用戶端時,您亦需要升級 RDS DB 堆疊。新的 RDS 堆疊與原來的堆疊主機名稱有所不同,因此 Docker 容器無法連接至資料庫。若要解決此問題,請為由 CloudFormation 建立的 EC2 實例使用 SSH,並使用新的主機名稱更新 whatsapp.conf
檔案,然後重新啟動 Docker 容器,以便容器獲取新的設定。
當 Docker 網橋損壞時,便會發生此錯誤。解決此問題的最佳方法就是關閉並重新啟動 Docker 服務。您亦可以在容器執行 docker restart
。
如果您收到「連接已被拒」錯誤,這有可能是因為核心應用程式沒有運行。請使用 docker ps
查看核心應用程式是否正在運行。如果它未有運行,請查看 Docker 記錄。核心應用程式可能無法連接至資料庫。請確保您已正確地設定資料庫。
當中的原因有許多種。這可能是因為您的核心應用程式發生故障,或您的資料庫沒有正確地設定。如果不是這兩種情況,請查看核心應用程式記錄(如果您正在運行多點連線,則請查看主要核心應用程式記錄)。如果您看到資料庫連接出現錯誤,則可能是因為您的資料庫連接已用完。請參閱 MySQL 文件或 PostgreSQL 文件,以了解更多關於此錯誤的資訊。
我們建議您增加資料庫連接的數量。一般而言,1000 個資料庫連接算是比較安全的數量,但請您根據實際情況作出相應的決定。如果錯誤仍然存取,請建立支援問題單。
如果您看到此錯誤,但您 json 正文已設定錯誤訊息所列的缺失必要參數,則有可能是 json 解析錯誤。當整個 json 的負載因 json 格式錯誤而無法解析時,便會出現此錯誤。查看那些參數值是否有無效的 json 字元,如末尾的歸位字元。有時您也可能會在複製參數時複製了多餘的空格,而這些空格可能會包含破壞 json 的字元。
如果手機無法讀取範本訊息,「structure unavailable」錯誤便會出現。
範本儲存在伺服器上。當用戶使用 messages
節點傳送範本訊息時,系統僅會將命名空間、語言、元素名稱和本地化參數傳送至手機,不會傳送整則訊息。手機收到這些值後,就會嘗試顯示這則訊息。
如果顯示期間出現任何錯誤,系統會向回呼網址傳送 structure unavailable
錯誤,其中包含傳送對象和訊息編號。命名空間錯誤、本地化參數不符、元素名稱錯誤等都是導致此類錯誤的原因。
請前往 Facebook 企業管理平台中的「WhatsApp 管理工具」查看正確的參數數量。請仔細檢查命名空間是否正確,以及元素名稱是否存在。
一個常見的錯誤原因就是沒有為所有使用的範本建立翻譯。例如,如果您有兩個經常傳送的範本,而您為其中一個範本加入了新語言翻譯,則請務必也為另一個範本加入該語言的翻譯。如果您計劃支援多種語言,則需要為所有範本提供所有支援語言的翻譯版本。
不過, structure unavailable
錯誤通常源自 messages
API 呼叫中的錯誤,可透過變更傳送裝載來解決。
WhatsApp Business API 用戶端的所有組件均會在發佈之日起 6 個月後過期。如果您看到此錯誤訊息,請儘快升級至最新版本。
WhatsApp 會展開一系列的試驗,以衡量和了解 WhatsApp Business API 通知對用戶體驗和整體產品的影響。如果您想向其傳送訊息的用戶正在參與此類試驗,則即使他們已選擇接收您的通知,他們也有可能收不到它們。
如果您在設定 AWS 部署時遇到類似以下內容的錯誤,請嘗試將堆疊名稱改為不超過 8 個字元。
國家/地區名稱(雙字母代碼)[AU]:州或省份(全名)[Some-State]:地點名稱(如城市)[]:機構名稱(如公司)[Internet Widgits Pty Ltd]:機構單位名稱(如部門)[]:常用名稱(如伺服器完整網域名稱或您的姓名)[]:字串過長,長度不得超過 64 位元 常用名稱(如伺服器完整網域名稱或您的姓名) []:電郵地址:錯誤,製作用於 internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com 的證書要求建立裝置金鑰時,出現配置檔案中沒有指定物件的問題
471
錯誤代碼與根據品質而定的傳輸率限制有關。請參閱根據品質而定的傳輸率限制文件,以進一步了解更多資訊。
以下是訊息範本傳送端驗證錯誤訊息,以及出現此類錯誤的原因:
template
。詳情請參閱媒體訊息範本文件。在 v2.29.x
版本之前,可能會因為系統錯誤而導致傳出訊息隊列數量持續增加。請升級至 v2.29.3
版本以解決這個問題。
核心應用程式將在核心應用程式容器內檢查 /usr/local/waent/data
和 /usr/local/waent/log
目錄,以確保系統至少還有 10 MB 儲存空間可用,否則核心應用程式會將此錯誤視為嚴重錯誤。
請檢查您的記錄和資料目錄,以確保儲存空間充足。
我們暫時尚未提供這種做法。如果您無法處理用戶透過 WhatsApp 傳送的已接收回應,則我們建議您傳送自動回覆訊息,以將戶重新導向至合適的支援渠道。
請註冊第二個手機號碼,並建立第二個 CloudFormation 堆疊或 Docker 實例以供測試。如果您有兩個使用相同手機號碼的 WhatsApp Business API 用戶端,則伺服器會因加密金鑰有所衝突而將您登出帳戶。我們建議您先設定第二個可用於測試非正式版實例的環境,然後再在正式版用戶端執行任何遷移動作。
當顧客更改其 WhatsApp 手機號碼時,您的企業不會獲取相應的通知。當您使用 contacts
節點時,該號碼的狀態將會顯示為 invalid
。
如果顧客已停用其手機號碼,但仍在使用 WhatsApp,則顧客可以繼續使用 WhatsApp,直至該手機號碼獲重新分配或重新註冊為止。
WhatsApp 必須驗證某個電話號碼是否屬於某部手機。如果用戶擁有 WhatsApp 帳戶,則證明他們已確認此電話號碼,而且之後也沒有其他用戶使用此號碼來註冊 WhatsApp。然而,這並不能保證 SIM 卡的實際位置。
另一方面,如果用戶的手機丟失或遭竊,他們也可停用他們的 WhatsApp 帳戶。如要進一步了解用戶如何停用帳戶的資訊,請參閱有關手機丟失與遭竊的常見問題。
不可以,WhatsApp Business API 不支援偵測是否有多部裝置正在使用相同電話號碼的功能。
用戶可透過文字或影音素材檔案的形式傳送訊息負載。
如果是文字,我們相信這不會造成任何危險。
如果是影音素材檔案:
auto_download
欄位設定為空白陣列。 WhatsApp Business 企業內部 API 用戶端需要使用資料庫來儲存密鑰,以解密商家與顧客之間傳送的訊息。WhatsApp 上的所有訊息均以傳送者和接收者密鑰以作加密處理。顧客密鑰儲存在其流動裝置上,商家密鑰則儲存在其資料庫中。詳情請參閱 WhatsApp 安全。
WhatsApp Business 雲端 API 是 Meta 託管商家資料庫的替代方案。透過使用雲端 API,您可以直接執行 WhatsApp Business API,無需花費成本託管自己的伺服器。了解詳情。