處理 LINE 收回訊息事件：防止已刪除內容重回收件箱

LINE 用戶收回訊息後，應從客服介面移除內容，並停止在下游使用。LINE 官方 webhook 指南建議取消顯示及刪除已儲存內容。透過 UnifyPort 接入時，可處理標準化的 message.deleted 事件，持久化刪除標記，再執行可重試的清理工作。只刪除收件箱的一筆紀錄並不足夠：延遲事件可能重建訊息，搜尋或 AI 上下文亦可能仍保留副本。

重點

• 接收收回通知，與呼叫 API 主動收回訊息，是兩項不同操作。
• 按事件 ID 去重，但以 data.message.id 及帳戶範圍定位目標。
• 保留最小刪除標記，防止延遲接收或編輯事件還原內容。
• 獨立追蹤下游清理；webhook 確認成功不代表所有副本已刪除。

LINE 收回訊息對已儲存內容的影響

LINE 訊息接收指南指出，用戶收回訊息時，伺服器會收到 unsend 事件。官方建議尊重用戶意圖，避免內容繼續被查看或使用，包括從管理畫面移除及從儲存空間刪除。

這是官方建議。下文的刪除標記、交易式 outbox 及驗收測試，屬於應用程式架構建議，不是 LINE 內置功能，亦不是法定資料保留期限的判斷。

編輯是取代內容，收回則是停止使用內容。如同時處理編輯，可保留LINE message.updated 同步流程，但寫入新文字前必須檢查刪除標記。修訂紀錄不能成為客服或檢索工作仍可讀取的隱藏副本。

分清事件契約

LINE 官方 Messaging API 接收器與 UnifyPort 接收器，使用不同的 payload 及驗證契約。沒有獨立轉接層時，不要把原生 LINE 請求直接交給標準化事件處理器。

UnifyPort 的標準事件參考將 message.deleted 定義為訊息被刪除或收回。在 message 物件內，只保證 data.message.id；文字及媒體會被移除。平台事件矩陣列出 LINE、Telegram 及 WhatsApp 對此事件的映射支援，但不保證所有上游帳戶或部署都會產生每種已映射事件。

以下示例使用文件中的欄位及虛構識別碼，並非實際擷取的投遞：

{
  "id": "evt_6d91a2c8",
  "type": "message.deleted",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-09-23T08:15:00Z",
  "data": {
    "conversation": { "id": "c8f2a4d91e", "type": "group" },
    "message": { "id": "551842037194" },
    "event": { "kind": "message_deleted" }
  }
}

頂層 id 識別事件，data.message.id 識別被移除的訊息。不要用前者查找訊息，亦不要把缺少文字理解成「編輯為空字串」。

先建立刪除屏障，再清理副本

在 subscribed_events 加入 message.deleted，保留業務所需的接收及編輯事件，並啟用 signing_secret。依照投遞契約，對時間戳記、句點及原始請求內容驗證 HMAC-SHA256，接受工作前亦要檢查時間戳記的有效時間。重放防護教學說明了驗證與持久化去重為何不能互相取代。

完成驗證及 payload 檢查後：

1. 在正確的工作區、平台及訊息帳戶內定位目標。可用時採用對話及訊息識別碼；如缺少對話資料，只使用既有且無歧義的帳戶內映射。不可跨對話猜測，無法定位的目標應隔離並交由人員覆核。
2. 在同一交易內記錄事件去重資料、建立或保留最小刪除標記、移除線上內容，並加入清理工作。與相同目標的接收及編輯寫入進行序列化協調。
3. 持久化接受後才回傳 2xx。下游清理由 worker 獨立重試。
4. 所有接收及編輯寫入都須檢查標記。延遲事件不可重新填入內容或觸發新 AI 工作。

以下是建議的應用程式狀態，不是 API 欄位：

現有狀態	新到事件	處理
沒有原訊息	刪除	儲存不含內容的標記，不等待原訊息
線上內容	刪除	停止顯示並安排清理
刪除標記	接收或編輯	不還原內容
刪除標記	重複刪除	維持狀態，繼續未完成的清理

不要只依賴到達次序或「最後時間戳記優先」。UnifyPort 不保證投遞次序。刪除標記是應用程式主動採用的規則：對同一訊息身分，刪除持續有效。

追蹤副本，而不只是收件箱紀錄

維護來源訊息與衍生產物的本地映射。以下是需要盤點的清理目標，不是 UnifyPort 自動執行的能力：

副本或工作	建議動作
收件箱正文、預覽	移除內容並使快取失效
已下載附件	刪除持有的副本及縮圖
搜尋、向量索引	刪除項目，完成前阻止檢索
AI 上下文、摘要、待發回覆	排除來源，使受影響摘要失效，取消或覆核相依工作
CRM、團隊聊天轉發	支援時刪除或遮蔽，追蹤未能清理的副本
原始事件日誌、死信佇列、備份	執行存取及保留政策，防止還原至線上畫面

worker 應在檢索前、發佈生成文字前，以及重建索引時重新檢查刪除狀態。可行時，發佈亦應與相同的訊息層級保護機制協調。已交予外部系統的工作未必可收回；應記錄限制，不要承諾完全抹除。

最小標記可只保留有範圍的識別碼及清理狀態，不保留被收回文字。按重放、備份還原及私隱要求決定保留期限。舊事件仍可重放時提早刪除標記，可能令內容再次出現。

驗收測試與限制

使用受控測試訊息，不使用客戶資料。以下是建議測試，並非已執行結果：

• 刪除先於原訊息到達：後到接收事件仍不顯示內容。
• 刪除與編輯或索引工作同時執行：內容不會重新發佈。
• 重複投遞刪除：沒有重複副作用，未完成工作繼續重試。
• 下游刪除失敗：收件箱隱藏內容，同時明確標示清理待完成。
• 還原備份：開放搜尋或收件箱存取前，先套用刪除標記。

UnifyPort 提供非官方介面及標準化事件流，不會自動刪除 CRM 或 AI 系統的內容。它沒有 REST 訊息歷史讀取 API，亦不保證重放漏收事件。未收到刪除事件，不代表沒有發生收回。產品需要原生 LINE 官方帳戶契約時，應優先採用官方路徑。

常見問題

message.deleted 是收回他人訊息的請求嗎？

不是。它報告已觀察到的刪除或收回。清理自己的儲存副本，與主動執行平台動作是不同操作。

可以從刪除 payload 找回原文嗎？

不可以。文件保證目標 ID，不保證已移除的文字或媒體。不要把收回處理設計成內容復原功能。

HTTP 200 表示所有下游副本都已刪除嗎？

不是。它只是投遞確認；應用程式須另行追蹤清理完成狀態及失敗。

下一步與來源

查看平台 webhook 事件矩陣，在啟用下游 AI 處理前，加入「刪除先於原訊息」的測試。

資料核對日期：2026-09-23。

• LINE：接收訊息與收回事件處理
• LINE：Messaging API 參考
• UnifyPort：標準事件
• UnifyPort：投遞與簽章驗證