對比選型 July 10, 2026

WhatsApp Calling API 錄音與轉寫：聊天入站不要和通話智慧綁在一起

Meta 在 2026 年 6 月 30 日的 WhatsApp Business Platform changelog 裡，釋出了一個值得支援團隊注意的訊號：Cloud API 新增了 call recording 和 call transcription 指南，並歸在 WhatsApp Business Calling API 底下。官方通話面還包含使用者發起通話、企業發起通話、SIP、calling webhook 和 calling pricing。

如果你的 WhatsApp 客服流程包含語音，這是好消息。錄音和轉寫可以變成可搜尋的紀錄：客戶問了什麼、客服承諾了什麼、下一步該追什麼。很多團隊也會因此想：既然 WhatsApp 有通話轉寫，客戶上下文是不是就解決了？

還沒有。這解決的是語音通話材料沉澱，不是聊天入站。

通話智慧不等於訊息入站

通話轉寫來自一次語音會話。它的價值是把口頭內容轉成文字，方便質檢、摘要、訓練和後續追蹤。聊天入站要做的是另一件事：客戶訊息一到，就接收、驗證、儲存，再分流到客服、CRM、佇列或 AI。

這兩個能力應該能在同一條客戶時間線上會合，但不應該變成同一個依賴。

問題	WhatsApp Calling API 錄音/轉寫	簽章入站聊天 webhook
核心物件	一次語音通話與其錄音/轉寫	一個客戶訊息事件
發生時機	通話中或通話後	入站訊息抵達時
適合用途	質檢、摘要、合規檢視、客服訓練、追蹤紀錄	入站、路由、去重、CRM 記錄、AI 分流
要避免的失敗	通話後失去語音脈絡	第一則客戶訊息還沒進隊列就遺失
渠道範圍	WhatsApp 官方通話能力	WhatsApp、Telegram、LINE、TikTok、Zalo 和 X 的標準事件流

如果團隊只處理 WhatsApp 語音，官方 Calling API 可以成為核心。若團隊同時處理 WhatsApp 訊息、LINE、Zalo、Telegram、TikTok 和 X，那通話轉寫只是客戶時間線上的一種材料，不是整套支援系統的入口。

先切清楚邊界

官方 WhatsApp Calling API 應該放在語音層。客戶要打電話、你需要 call button、客服需要語音路由，或質檢需要錄音與轉寫時，它就是合適的工具。

訊息入站應該放在事件層。這一層要單純、嚴格、容易排查：

接收入站投遞。
驗證簽章。
以事件 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 訊息到達時，接收端會拿到標準事件：

{
  "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。這讓入站服務能在寫入資料庫或交給 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 分開，團隊才能同時使用兩者，而不會讓其中一個卡住另一個。