对比选型 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 分开，团队才能同时使用两者，而不会让其中一个成为另一个的前置门槛。