Handle LINE Unsend Events Without Restoring Deleted Inbox Messages
When a LINE user unsends a message, remove its content from your support interface and stop using it downstream. LINE’s official webhook guide recommends removing the displayed message and deleting stored content. In a UnifyPort integration, handle the normalized message.deleted event with a durable deletion marker and retryable cleanup work. Deleting only the visible inbox row is not enough: delayed events could recreate it, and search or AI context could still contain copies.
Key takeaways
- Receiving a recall is different from asking an API to revoke a message.
- Deduplicate the deletion event, but identify the target using
data.message.idand its account scope. - Keep a minimal deletion marker so delayed receive or edit events cannot restore content.
- Track cleanup across your own downstream systems; webhook acknowledgement does not prove those copies are gone.
What LINE unsend means for stored content
The LINE receiving-messages guide says an unsend event is delivered when a user unsends a message. It recommends respecting that intention so the message cannot be seen or used in the future, including removing it from management screens and deleting it from storage.
That is the official recommendation. The deletion-marker, outbox, and acceptance-test design below is our suggested application architecture, not a LINE feature or a legal retention ruling.
An edit replaces content; a recall suppresses it. If you also process edits, keep the LINE message.updated reconciliation flow but add a deletion guard before it writes new text. Revision history must not become a hidden copy that ordinary agents or retrieval jobs can still access.
Use the right event contract
An official LINE Messaging API receiver and a UnifyPort receiver have different payload and verification contracts. Do not send a native LINE body into a normalized-event handler without a separate adapter.
UnifyPort’s standard event reference defines message.deleted as a deleted or recalled message. Within the message object, only data.message.id is guaranteed; text and media are dropped. The provider event matrix maps this event for LINE, Telegram, and WhatsApp, but explicitly does not guarantee that every upstream account or deployment emits every mapped event.
This illustrative normalized event uses documented fields and fictional identifiers; it is not a captured delivery:
{
"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" }
}
}The top-level id identifies the event; data.message.id identifies the removed message. Do not use the former as a message lookup key or interpret missing text as an empty-text edit.
Build a deletion barrier before cleanup
Configure subscribed_events to include message.deleted alongside the receive and edit events your application needs. Enable signing_secret. Follow the delivery contract to verify HMAC-SHA256 over the timestamp, a dot, and the raw request body, and apply a timestamp freshness policy before accepting work. The replay-protection tutorial explains why verification and durable deduplication are separate controls.
After authentication and payload validation:
- Resolve the target inside the correct workspace, provider, and messaging account. Use conversation and message identifiers when available. If conversation context is missing, use an existing unambiguous account-scoped mapping; never guess across chats. Quarantine unresolved targets for review.
- In one transaction, record event deduplication, create or retain a minimal deletion marker, remove live content, and enqueue cleanup work. Serialize this transition with receive/edit writes for the same target.
- Return 2xx only after durable acceptance. Let a worker retry downstream cleanup independently.
- Make every receive/edit writer consult the marker. A late event must not repopulate the message or trigger another AI job.
Suggested application state rules—not API fields:
| Stored state | Incoming observation | Action |
|---|---|---|
| No original | Deletion | Store a content-free marker; do not wait for the original |
| Live content | Deletion | Suppress content and enqueue cleanup |
| Deletion marker | Receive or edit | Do not restore content |
| Deletion marker | Repeated deletion | Keep state; continue unfinished cleanup |
Do not rely solely on arrival order or a last-write-wins timestamp. UnifyPort does not guarantee delivery order. The marker is an intentional application rule that deletion remains effective for that message identity.
Follow the copies, not just the inbox row
Maintain a local mapping from each source message to its derived artifacts. The following are cleanup targets to inventory, not capabilities UnifyPort performs automatically:
| Copy or task | Recommended action |
|---|---|
| Inbox body and previews | Remove content and invalidate caches |
| Downloaded attachments | Delete owned copies and thumbnails |
| Search and vector indexes | Remove entries and block retrieval while removal is pending |
| AI context, summaries, queued replies | Exclude the source, invalidate affected summaries, cancel or review dependent jobs |
| CRM or team-chat relays | Remove or redact where supported; track unresolved copies |
| Raw-event logs, dead-letter queues, backups | Apply documented access and retention controls; prevent restoration into live views |
Workers should recheck deletion state before retrieval, before publishing generated text, and when rebuilding an index. Coordinate publication with the same per-message guard where possible. Work already handed to an external system may not be retractable; record that boundary rather than claiming perfect erasure.
A minimal marker can retain scoped identifiers and cleanup status without retaining the recalled text. Decide its retention period together with replay, restore, and privacy requirements. Removing the marker while old events remain replayable can reopen the restoration problem.
Acceptance tests and limits
Use controlled test messages, not customer data. These are proposed tests, not reported results:
- Delete before the original arrives: a later receive stays suppressed.
- Delete while an edit or index job runs: no content is republished.
- Deliver the same deletion again: no duplicate side effects, unfinished cleanup still retries.
- Fail a downstream delete: the inbox hides content while cleanup remains visibly pending.
- Restore a backup: apply deletion markers before reopening search or inbox access.
UnifyPort provides an unofficial interface and a normalized event stream, not automatic deletion from your CRM or AI systems. It has no REST message-history read API or guaranteed replay for missed events. No deletion event received does not prove that no recall occurred. Prefer the official LINE path when your product requires the native Official Account contract.
FAQ
Is message.deleted a request to revoke someone else’s message?
No. It reports an observed deletion or recall. Cleaning your own stored copies is separate from initiating a provider action.
Can I recover the original text from the deletion payload?
No. The documented message object guarantees the target ID, not the removed text or media. Do not build recall handling as a recovery feature.
Does HTTP 200 mean all downstream copies are deleted?
No. It acknowledges delivery. Your application must track cleanup completion and failures separately.
Next step and sources
Review the webhook event matrix, then add a deletion-before-original test to your receiver before enabling downstream AI processing.
Sources checked on 2026-09-23:
Turn messaging integration into a stable product pipeline.
Start by sending through one API, then bring every inbound message back into your business system with standard events.