← 所有文章
對比選型

訊息發錯後：編輯、撤回，還是只在本機隱藏？

透過已連接帳戶發錯訊息後，先確定要改動的範圍：編輯替換已發出的文字，撤回要求從對話所有參與者處收回訊息，本機隱藏只改變自己應用程式的顯示。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 供調查；它不是冪等 token，也不是保證可關聯 webhook 的鍵。

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

常見問題

編輯端點可以替換附件嗎？

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

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

不是。本機可見性與渠道側撤回是不同操作，介面必須寫明範圍。

支援 message.deleted，就代表每次撤回都有回調嗎？

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

下一步與來源

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

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

UnifyPort API

令訊息接入變成一條穩定嘅產品管線。

先用統一嘅 API 跑通發送，再用標準事件將所有入站訊息接返去業務系統。

攞 API Key睇 API 參考