第一個選項是使用像 Baileys 這樣的非官方函式庫，它透過WhatsApp 經逆向工程分析出的網路協定進行連線。這種方法雖然可行——但終究會失效。它違反了WhatsApp服務條款，每當WhatsApp 其客戶端WhatsApp 就會失效，甚至可能導致開發者的個人電話號碼遭到永久封禁。對於任何認真想要推出產品的人來說，這都是不可接受的。
第二種選擇是官方途徑：透過 Meta 申請自己的WhatsApp API 存取權限，完成為期數天的企業驗證流程，自行管理 webhook 基礎架構，並安全地處理 Meta Cloud API 憑證。對於擁有專職開發人員的企業團隊來說，這尚屬可行；但對於正在開發 AI 代理程式原型的獨立開發者而言，這無異於一道高牆。
兩者之間從未有過一條快速、正式且無阻礙的通道。我們開闢了一條。
無需完成 Meta Business 驗證。無需配置 API 憑證。無需架設 webhook 伺服器。imBee 負責運作已驗證的WhatsApp 帳號（WABA）、路由基礎架構以及安全層。您的本地 OpenClaw 實例透過一次性 QR 碼流程與 imBee 的號碼配對，此後發送至該號碼的每則訊息，都將在 500 毫秒內轉發至您的客服人員。
此外掛程式透過 ClawHub 註冊表和 npm 進行發行。只需一筆指令即可安裝：
openclaw 外掛程式 安裝whatsapp
接著，它便會作為一級通道選項出現在標準 新增 openclaw 頻道 設定精靈，以及您已安裝的其他頻道。
新增 openclaw 頻道, 該外掛程式會在頻道選單中顯示為「官方WhatsApp （透過 imBee）」。CLAW-A3F9-Z7KL) 並將其連同每個實例的 API 金鑰一併傳回。wa.me 深度連結。兩者均包含 imBee 已驗證的WhatsApp 號碼以及您的專屬配對碼。配對代碼僅限使用一次，有效期為 10 分鐘，且由 36⁸ ≈ 2.8 兆種組合中產生。一旦您的執行個體完成配對，該代碼即失效，且絕不會儲存在您的裝置上。
當WhatsApp 傳送到 imBee 的已驗證號碼時，我們的路由伺服器會識別已配對的本地實例，並透過持久的 WebSocket 連線在 500 毫秒內轉發完整的事件。對於文字訊息，您的客服人員還會自動向用戶發送輸入提示——因此當客服人員處理請求時，客戶會看到「正在輸入…」的提示。
支援的傳入訊息類型：
外發回覆會透過單一 REST 呼叫傳送至 imBee 的路由伺服器，該伺服器隨後會透過WhatsApp API 進行傳送。您的客服人員可以發送文字或多媒體內容（包括圖片、影片、音訊或文件），而無需直接接觸 Meta 或 360dialog。
您本地的外掛程式與 imBee 路由伺服器之間的每項連線均採用 TLS 1.2 或更高版本。WebSocket 連線則採用 wss://. 您的本地實例會透過配對過程中生成的、專屬該實例的 Bearer 憑證進行驗證，該憑證會透過 SecretRef 表面 — 絕不會以純文字形式儲存在磁碟上。
每次傳入事件都會驗證 Webhook 的完整性：針對 Meta Cloud API 後端，會使用 Meta 的應用程式密鑰進行 HMAC-SHA256 驗證，或 Ocp-Apim-訂閱金鑰 360dialog 後端的驗證。任何未能通過這些檢查的請求都會被拒絕，並顯示 403 禁止存取.
最重要的是：訊息內容絕不會永久儲存於 imBee 的路由伺服器上。資料包會在記憶體中處理，並立即轉發至您的本地實例。我們唯一會永久儲存的資料是路由元資料——包括電話號碼、WABA 號碼、實例 ID 以及連線狀態——這些資料對於將未來的訊息傳送給正確的代理程式至關重要。
這正是 imBee 為金融服務、醫療保健及物流領域的企業客戶所提供的安全防護措施。此外掛程式在設計上繼承了這項特性。
對於在 OpenClaw 上進行開發的開發者，請透過 ClawHub 或 npm 進行安裝：
openclaw 外掛程式 安裝whatsapp
接著執行：
新增 openclaw 頻道
請從選單中選擇「官方WhatsApp （透過 imBee）」，用手機掃描 QR 碼，並從WhatsApp 傳送配對碼。設定就完成啦。
對於WhatsApp 更廣泛的人工智慧代理策略WhatsApp 評估，並想了解 imBee 的 BSP 級基礎設施如何擴展至專用號碼、多代理路由、廣播活動以及 imBee 全通路平台的其他功能之企業—— 立即預約演示 與我們的團隊。我們協助亞太地區的企業，以大規模且安全的方式將人工智慧融入客戶對話中。
OpenClaw 的官方WhatsApp 現已透過ClawHub及GitHub 儲存庫提供下載。
