對比選型 July 10, 2026

WhatsApp Calling API 錄音同轉寫：聊天入站唔應該同通話智能綁埋一齊

Meta 喺 2026 年 6 月 30 日嘅 WhatsApp Business Platform changelog 入面，釋出咗一個支援團隊值得留意嘅訊號：Cloud API 新增 call recording 同 call transcription 指南，歸喺 WhatsApp Business Calling API 底下。官方通話能力亦包括 user-initiated calls、business-initiated calls、SIP、calling webhook 同 calling pricing。

如果你嘅 WhatsApp 客服流程有語音通話，呢個係好消息。錄音同轉寫可以變成可搜尋紀錄：客戶問過咩、同事承諾過咩、下一步要跟咩。好多團隊會因此覺得：既然 WhatsApp 有通話轉寫，客戶上下文問題係咪已經解決？

未係。呢個解決嘅係語音通話材料保存，唔係聊天入站。

通話智能唔等於訊息入站

通話轉寫來自一次語音會話，價值係將口頭內容變成文字，方便 QA、摘要、培訓同跟進。聊天入站做嘅係另一件事：客戶訊息一到，就接收、驗簽、保存，再分流到客服、CRM、隊列或者 AI。

兩個能力應該可以喺同一條客戶時間線度會合，但唔應該變成同一個依賴。

問題	WhatsApp Calling API 錄音/轉寫	簽名入站聊天 webhook
核心對象	一次語音通話同錄音/轉寫	一個客戶訊息事件
時機	通話中或通話後	入站訊息到達一刻
適合用途	QA、摘要、合規回看、客服訓練、跟進紀錄	入站、路由、去重、CRM 記錄、AI 分流
要避免嘅失敗	通話後失去語音上下文	第一條客戶訊息未入隊就遺失
渠道範圍	WhatsApp 官方通話能力	WhatsApp、Telegram、LINE、TikTok、Zalo 同 X 嘅標準事件流

如果團隊只做 WhatsApp 語音，官方 Calling API 可以係核心。如果團隊同時處理 WhatsApp 訊息、LINE、Zalo、Telegram、TikTok 同 X，通話轉寫就只係客戶時間線上其中一種材料，唔係整套支援系統入口。

先劃清邊界

官方 WhatsApp Calling API 應該放喺語音層。客戶要打電話、你需要 call button、客服需要語音路由，或者 QA 需要錄音同轉寫，佢就係合適工具。

訊息入站應該放喺事件層。呢層要簡單、嚴格、容易查：

接收入站投遞。
驗證簽名。
用事件 ID 保存原始事件。
按 provider、account、conversation、sender 同 message type 路由。
AI、CRM 同人工隊列都喺保存之後先工作。

呢個拆分好重要，因為聊天係非同步。客戶傳一句「剛才電話後，我個取貨時間有冇改？」就可能走咗。如果入站路徑仲等緊通話轉寫、CRM 查詢或者 AI 摘要，系統就可能錯過最應該先保存嗰條訊息。

UnifyPort 嘅位置

UnifyPort 唔係用嚟取代官方 WhatsApp Calling API。你需要 WhatsApp 語音通話、錄音或者官方通話轉寫，就應該用 Meta 官方通話能力。

UnifyPort 嘅角色更窄：透過非官方接口接收一般訊息帳號嘅入站訊息，並投遞成已簽名、標準化嘅 webhook 事件。同一個 handler 可以接 WhatsApp、Telegram、LINE、TikTok、Zalo 同 X。

先建立 webhook endpoint，訂閱 message.received，並設定 signing_secret：

curl -X POST https://api.unifyport.ai/v1/webhook-endpoints \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://support.example.com/webhook",
  "status": "active",
  "subscribed_events": ["message.received"],
  "signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'

WhatsApp 訊息到達時，receiver 會收到標準事件：

{
  "id": "evt_20260710_01",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_support_whatsapp",
  "occurred_at": "2026-07-10T02:30:00Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user", "title": "Minh Tran" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM20260710",
      "type": "text",
      "text": "Can someone confirm whether my pickup changed after the call?",
      "direction": "inbound",
      "sent_at": "2026-07-10T02:29:58Z"
    },
    "event": { "kind": "message_received" }
  }
}

如果 endpoint 設咗 signing_secret，投遞會包含 X-Device-Timestamp 同 X-Device-Signature。簽名係對 <X-Device-Timestamp>.<raw request body> 計出嘅十六進制 HMAC-SHA256。入站服務可以喺寫 storage 或交畀 AI 前，用同一套方法驗證來源。

架構保持簡單就夠：

WhatsApp / LINE / Zalo / Telegram / TikTok / X message
  -> UnifyPort message.received webhook
  -> HMAC-SHA256 signature verification
  -> Event store
  -> Routing, CRM lookup, AI triage, or human queue

WhatsApp voice call
  -> Official WhatsApp Calling API layer
  -> Recording / transcript / summary artifact
  -> Attach to the same customer timeline

重點係客戶時間線由邊度開始。應該由第一個入站事件開始，再將通話錄音、轉寫同摘要作為相關材料掛上去。

小團隊點判斷

對 2 至 10 人嘅支援團隊嚟講，問題唔係「要唔要通話轉寫」，而係「邊個系統保存客戶第一次接觸紀錄」。

如果 WhatsApp 語音係主渠道，官方通話層可以承擔好多體驗：客服接電話，錄音同轉寫掛喺通話之下，流程係 voice-first。

如果聊天係主渠道，入站層就唔應該等語音工具。先保存訊息，再做增強：

客戶之後打電話，就將錄音同轉寫掛到同一個 conversation。
AI 生成回覆，都要以原始 message.received 做來源。
人工回覆時，用已連接帳號呼叫 POST /v1/messages。
第二個平台入同一條支援隊列時，用 provider 路由，而唔係再開一個 inbox。

Meta 嘅錄音同轉寫更新令 WhatsApp 語音更適合支援場景，但冇取代聊天入站層。將通話智能同訊息 webhook 分開，團隊先可以同時用兩者，而唔會令其中一層卡住另一層。