← 所有文章
對比選型

訊息傳錯後：編輯、收回還是只在本機隱藏？

透過已連結帳號傳錯訊息後，先確認要改變的範圍：編輯替換已傳送文字，收回要求從對話所有參與者處收回訊息，本機隱藏只改變自己應用程式的畫面。UnifyPort 文件支援 WhatsApp 文字編輯，以及 Telegram、WhatsApp、LINE 訊息收回。兩種動作都只針對帳號自己傳送的訊息；能接收編輯或刪除 webhook，不代表能執行相同動作。

重點整理

  • 更正文字用編輯，撤下自己傳出的訊息用收回，調整工作台顯示則用應用程式控制。
  • 帳號、對話與訊息必須一起保存；確認後不要重新選取「最新一則」。
  • 主動操作能力與事件接收能力要分別確認。
  • API 結果、webhook 觀察與下游副本清理，是不同層次的證據。

編輯、收回與本機隱藏的差別

假設客服傳錯預約時間。更正文字與讓訊息從客服畫面消失，解決的是不同問題。

目的適合的控制不能據此證明
更正已傳送文字編輯訊息收件人從未看過原文
收回本帳號傳出的訊息收回訊息所有儲存或轉傳的副本都已消失
隱藏自己收件匣的一列應用程式顯示控制客戶聊天室的訊息有改變
處理已觀察到的收回處理 message.deleted已發起新的收回請求

WhatsApp 的官方刪除說明提醒：收件人可能在刪除前已看到訊息，iOS 使用者儲存到「照片」中的媒體也可能保留。不要把按鈕命名為「徹底抹除」，或以收回保證機密內容從未曝光。

這裡的本機隱藏是應用程式設計，不是已公開的 UnifyPort 單則訊息本機刪除端點。conversation.deleted 與 conversation.cleared 描述本機對話變更，也不等於為所有人收回單則訊息。

核對動作矩陣，而非只看事件矩陣

目前管道動作矩陣的映射如下：

管道編輯已傳送文字收回本人訊息
whatsapp支援支援
telegram不支援支援
line不支援支援
twitter、zalo、tiktok、whatsapp-protocol不支援不支援

這些是介接層映射，不保證每次請求都符合上游條件或帳號限制。尚未實作的組合會回傳 501 unsupported_by_provider。

例如，LINE 編輯事件處理文章說明接收及整併 message.updated，並未開放 LINE 主動編輯。不要因為接收端認得這個事件，就啟用「編輯」按鈕。

UnifyPort 的收回契約也比某些原生群組管理功能更窄：只能收回已連結帳號自己傳送的訊息。即使操作人員是群組管理員，也不要據此提供收回其他成員訊息的功能。

送出更正前，固定選取的訊息

從已儲存的 message.received 觀察取得 account_id、data.conversation.id 與 data.message.id。事件可能代表入站或出站訊息；執行前檢查 data.message.direction 並確認歸屬。頂層事件 id 不是訊息 ID。

建議加入以下應用程式檢查：

  1. 驗證操作人員對所選訊息帳號與對話的權限。
  2. 在確認視窗固定訊息身分，顯示目前內容及動作範圍。
  3. 確認管道支援，且訊息由本帳號傳送；編輯只允許文字訊息。
  4. 依序處理同一目標的更正，避免兩位客服互相覆蓋決定。
  5. 將動作與結果記錄，和可見訊息內容分開儲存。

以下為採用虛構識別碼的 JSON 請求本文範例，不是實際客戶流量。透過伺服器使用 X-Api-Key 傳送，不要把金鑰放進瀏覽器程式碼。

POST /v1/messages/edit 的 content 是完整替換文字，不是局部修補：

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C",
  "content": "更正：預約時間是 15:00。"
}

POST /v1/messages/revoke 選取相同目標，不需替換文字：

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C"
}

收回文件指出 sender_id 預設為帳號本身，通常可省略。填入其他傳送者不會擴大權限。不要自行設定跨管道統一的更正期限，也不要套用另一套 API 的權限。

分開處理請求結果與副本清理

兩個端點的成功回應範例均包含 data.ok: true。記錄實際結果，但不要解讀為所有收件人與下游系統都已清除舊內容。

觀察結果建議處理
501 unsupported_by_provider停用該管道動作，不重送相同請求
edit_message_failed 或 revoke_message_failed檢查錯誤與目標脈絡，再決定下一步
HTTP 逾時或回應遺失保留結果不確定，先調查再考慮重試
收到對應的 message.updated 或 message.deleted在正確範圍內，以冪等方式更新訊息
沒有對應事件不只憑事件缺席判定成功或失敗

依請求追蹤指南保存回傳的 request_id 供調查；它不是冪等權杖，也不是保證可關聯 webhook 的鍵。

接收事件時遵循投遞契約：設定 signing_secret，以時間戳記與原始本文驗證 HMAC-SHA256、檢查時效，持久化後再確認。事件順序沒有保證。自有搜尋、CRM、AI 副本仍需另外清理；收回內容清理指南說明了這個應用層邊界。

常見問題

編輯端點能替換附件嗎？

文件只支援文字訊息。不要把 content 當成媒體替換欄位。

在收件匣隱藏後，客戶就看不到了嗎？

不是。本機可見性與管道側收回是不同操作，介面必須標明範圍。

支援 message.deleted，就表示每次收回都有回呼嗎？

不是。事件映射不保證每個上游帳號或部署都會產生所有事件。分別保留 HTTP 結果與事件觀察狀態。

下一步與來源

先閱讀收回訊息參考，在獲授權的測試對話檢查選取與確認流程。UnifyPort 是非官方介面，不取代原生平台規則，也不保證抹除外部副本。

資料核對日期：2026-10-12。

UnifyPort API

讓訊息接入變成一條穩定的產品管線。

先用統一 API 跑通傳送，再用標準事件把所有入站訊息接回業務系統。

取得 API Key瀏覽 API 參考