WhatsApp Business API 語音轉錄:2026年7月

你已經把 WhatsApp Business API 參考文件看了兩遍,尋找那個把傳入語音訊息轉成文字的端點。 它並不存在。它從來都不存在。 這不是你看漏了 — 這是關於 WhatsApp Business API 語音轉錄最重要的一個事實,而幾乎沒有任何相關文章把它說清楚。

以下是平台實際提供甚麼、它悄悄保留了甚麼,以及那兩個為不知情的團隊無聲地破壞語音訊息的陷阱。

最後查證於 2026年7月,對照 Meta 的 WhatsApp Business Platform 文件,包括 2026 年 3 月和 6 月推出的改動。

簡短答案

WhatsApp Business Platform 上沒有任何端點可轉錄傳入的語音訊息。Cloud API 沒有,On-Premises API 也沒有。當客戶向你的企業發送語音訊息時,webhook 交給你一個媒體 ID。你呼叫媒體端點,下載一個音訊檔案,而從那一刻起你就完全靠自己了。

把那段音訊轉成文字是你要解決的問題,由你自選的語音轉文字工具、以你自己的成本完成。

WhatsApp 用戶在對話中看到的文字稿確實存在 — 但它們在接收者的手機上生成,永遠不會離開。它們不會傳送給 WhatsApp,當然也不會傳送給你。即使你團隊中的人工客服在 WhatsApp Business 應用程式內閱讀了文字稿,那段文字仍被困在那一部手機上。沒有任何 API 會把它交給你。

諷刺之處:Meta 會轉錄通話,卻不轉錄語音訊息

這正是平台變得真正奇怪的地方。

在 2026 年 6 月 30 日,Meta 為 WhatsApp Business Calling API 推出了通話轉錄。它並非聊備一格的功能。它在約 54 種語言中自動偵測所說語言,將商業說話者與客戶分開,並以結構化 JSON 返回帶有逐字信心分數的逐字時間標記。

與此同時,Android 上的語音訊息文字稿仍然只支援四種語言:英文、葡萄牙文、西班牙文和俄文。自 2024 年 11 月以來從未改變。如果你需要各平台的完整全貌,我們已詳細拆解了 WhatsApp 轉錄實際支援哪些語言。

所以平台能夠轉錄泰米爾文、斯瓦希里文、越南文和烏爾都文 — 在通話中。它只是不為你客戶三十秒前發給你的語音訊息這樣做。無論原因為何,對你而言實際後果很簡單:引擎存在,而你無法把它指向你的語音訊息。

通話轉錄實際如何運作

• 按每通通話選擇加入,在你發起或接受通話時傳入一個 transcription 物件。它並非預設開啟。
• 同意是強制且可聽見的。Meta 在轉錄開始前將一段語音提示混入雙方的音訊流,而你必須提供一個明述的用途。你無法無聲地轉錄通話。
• 交付是非同步的。你會收到一個帶有媒體 ID 的 webhook,然後下載 JSON 文字稿。
• 你有七天時間。之後文字稿便無法再下載。如果你需要保留它,必須及時自行拉取並儲存。
• 目前免費,Meta 的文件表明另有計劃中的定價,但尚未定日期。不要把價格維持零元當作你商業計劃的基礎。

兩個無聲破壞語音訊息的陷阱

陷阱 1:它必須是採用 OPUS 編解碼器的 .ogg

自 2025 年 10 月起,你已能把音訊作為真正的語音訊息發送 — 波形、播放按鈕,一應俱全 — 而非作為檔案附件。但文件中埋著一項硬性要求。

語音訊息必須是以 OPUS 編解碼器編碼的 .ogg 檔案。 Meta 的文件 毫不含糊:「如果你發送不同的檔案類型,或以不同編解碼器編碼的檔案,語音訊息轉錄將會失敗。」

令這一點惡毒的是它的失敗模式。沒有錯誤,也沒有警告 — 訊息發送出去、能播放,而文字稿就是永遠不出現。團隊為此耗費數天,梳理他們的 webhook 處理,而實際的錯誤只是他們編碼步驟中的一行。

陷阱 2:由接收者決定,而非你

即使有一個完美編碼的 OPUS 檔案,你也無法控制是否顯示文字稿。接收者才能。每位 WhatsApp 用戶都將語音訊息文字稿設為以下三種狀態之一:

• 自動 — 文字轉錄隨訊息一同出現。
• 手動 — 他們看到「轉錄」選項,並選擇是否使用。
• 永不 — 永遠不顯示任何文字。

沒有任何 API 參數可覆寫此設定,也無法查詢某位用戶採用哪個設定。如果你的產品體驗依賴客戶閱讀你語音訊息的文字稿,要明白你正依賴一個你看不到、也改不了的設定。據此設計 — 如果內容重要,就發送文字。

2026 年確實落地的改變

「已播放」webhook

自 2026 年 3 月 17 日起,企業發送的語音訊息會在接收者首次播放時收到「已播放」狀態 webhook。在此之前,「已送達」和「已讀」就是故事的終點,而語音訊息上的已讀回條並不能告訴你多少事情。

這是個確實有用的訊號。這是你首次能夠區分一則只是被送達的語音訊息,與一則真的被聆聽的語音訊息 — 而那正是你真正想知道的唯一事情。

語音留言以普通音訊訊息形式抵達

語音留言於 2026 年 6 月 25 日正式全面推出。值得內化的細節是它的交付方式:語音留言透過訊息(messages)webhook 以傳入音訊訊息形式抵達。

這意味著它們落在與其他每一則語音訊息完全相同的位置 — 一個指向音訊檔案的媒體 ID,不附帶任何文字稿。你的未接來電現在會產生更多需要你自行轉錄的音訊。

那麼你實際上該建立甚麼?

撇開細節,架構是被逼出來的。對於任何傳入的語音訊息,你收到一個媒體 ID、下載音訊,然後自備你的語音轉文字。沒有任何受支援的途徑可繞過這一點。

這留給你一個真正的決定,而它值得刻意作出,而非隨波逐流:

自己建。把媒體端點接到一個語音轉文字供應商。你將擁有整個流程、重試機制、音訊儲存及其保留政策、每分鐘成本,以及在貨車和咖啡店錄製的現實音訊上準確度這個持續的問題。如果轉錄是你產品的核心,而你想掌控模型,這是合理的。

不要自己建。如果你只是需要你的團隊讀到客戶說了甚麼,搭建並維護一條轉錄流程,是為了重新發明一個已經存在的東西而付出大量工程。把語音訊息轉寄給一個 轉錄服務 ,便能讓文字回到對話中,支援超過 50 種語言,毋須任何基礎設施,也沒有需要你儲存和保護的音訊。

要老實面對你有的是哪個問題。許多團隊建了那條流程,是因為 API 的沉默令它感覺像是必須的 — 而不是因為轉錄曾經是他們想要做得好的事情。

使用 WhatsApp Business 應用程式而非 API?不同的產品,不同的規則 — 文字稿存在於你的手機上,設定只是一個開關。請改為參閱我們的 轉錄 WhatsApp Business 語音訊息指南。

資料來源

於 2026 年 7 月對照 Meta 的第一手文件核實。

• Meta for Developers — 音訊訊息 — .ogg/OPUS 要求、接收者的自動/手動/永不設定,以及 2026 年 3 月 17 日起的「已播放」狀態 webhook。
• Meta for Developers — 通話轉錄 — 選擇加入流程、強制的同意提示、JSON 文字稿結構、語言涵蓋範圍,以及七天的下載窗口。
• WhatsApp 說明中心 — 關於語音訊息文字稿 — 裝置端、接收端的行為,以及 Android 語言清單。

常見問題

有沒有 WhatsApp Cloud API 端點可轉錄傳入的語音訊息?沒有。截至 2026 年 7 月,WhatsApp Business Platform 上沒有任何端點會返回傳入語音訊息的文字稿。你得到一個媒體 ID、下載音訊,而轉錄是你要解決的事。

企業能看到它所收到語音訊息的文字稿嗎?透過 API 不能。文字稿在接收者的裝置上生成,永遠不會離開。即使你的客服在 WhatsApp Business 應用程式中閱讀了一份,那段文字仍留在那部手機上。

為甚麼我的 WhatsApp 語音訊息從不顯示文字稿?幾乎總是以下兩者之一。要麼檔案不是以 OPUS 編碼的 .ogg — 在這情況下轉錄會無聲地失敗 — 要麼接收者已將語音訊息文字稿設為手動或永不,而這是你看不到也無法覆寫的。

WhatsApp Business Calling API 支援轉錄嗎?支援,自 2026 年 6 月 30 日起。按每通通話選擇加入,雙方會聽到必要的提示,而你會得到附帶說話者分離、逐字時間標記和信心分數的 JSON,涵蓋約 54 種自動偵測的語言。文字稿可下載七天。它轉錄的是通話,而非語音訊息。

通話轉錄免費嗎?目前免費。Meta 的文件表示另有計劃中的定價,但未給出推出日期。把目前的價格視為暫時性的。