LINE's message edit trial: how bots must handle Edit and Unsend webhooks

LINE opens message editing in LINE Labs

On August 20, 2026, LINE announced a free trial of an "Edit Message" feature through LINE Labs, according to a dev.to article by Evan Lin, who leads the Developer Relations team at LINE Taiwan. Users on mobile LINE version 26.12.0 or later can switch the feature on under Home, Settings, LINE Labs, after which text messages can be edited within 15 minutes of being sent in one-on-one and group chats. Keep Notes allow edits for up to six days. Photos, videos, voice messages, files and stickers cannot be edited, edited messages are labelled "Edited" in the thread, and there is no way to view or restore earlier versions.

One restriction matters directly to developers: one-on-one chats with LINE Official Accounts do not support editing at all, so a bot has to be added to a group chat before its Edit events will fire.

Two new webhook events for bots

The Messaging API exposes an Edit event, typed messageEdited, alongside the existing Unsend event delivered when a user retracts a message. Per the dev.to walkthrough, the Edit event carries the edited text, a timestamp, a reply token and a message ID, and that message ID is identical to the one in the original message event. That makes it a stable key: a bot can create a record when the first message arrives and overwrite the same record whenever an edit lands. The Edit event also carries its own reply token, distinct from the original event's, so a bot can reply to that specific edit.

Developers using the Mark as Read API should watch for a field difference: the Edit event has no markAsReadToken, so the standard message-event processing path cannot simply be reused. Lin recommends replaying webhook fixtures after an SDK upgrade to catch these mismatches.

The demo: a group buying bot

To exercise both events, Lin built a group buying bot. A group leader starts a buy with a store and a deadline, participants post orders in a slash-separated format such as "Pearl Milk Tea / Half Sugar / Less Ice / 1", and when someone edits that message the bot updates the quantity, sweetness, ice level and total. When someone unsends an order, the bot deletes it and recalculates. A "Current Orders" command returns the summary as a Flex Message, and the sample code is published on GitHub.

The scenario was chosen deliberately: the two most common moments in group buying, changing your mind and cancelling, map cleanly onto Edit and Unsend, and observers can verify from the quantities and totals whether a webhook actually changed backend state rather than the bot merely acknowledging the edit.

Two implementation traps

The first trap is ordering. A user can edit the same message several times in quick succession, and the resulting webhooks are not guaranteed to arrive in the order they were made; the platform may also resend events. Lin follows the official recommendation to treat the event with the largest timestamp as the latest state and discard edits older than what is already stored. Deduplication is handled separately through webhookEventId: that prevents the same event from being processed twice, while the timestamp check stops an older edit from overwriting a newer one.

The second trap is validation. An edited message may no longer be a valid order at all, since a user might rewrite an order into plain text such as "I suddenly don't want to drink anymore". Keeping the old order would break consistency just as surely as ignoring the edit, so the demo clears the stored content, marks the record invalid and temporarily removes it from the running total.

Why it matters

Message editing breaks a long-standing assumption in chat bot design: that an inbound message is immutable input. Bots that parse and persist messages without also consuming Edit and Unsend events will drift out of sync with what users actually see, and the drift is silent because the bot keeps answering as if nothing changed. The ordering and deduplication concerns here are not specific to LINE either; they apply to any webhook-driven integration with at-least-once delivery. As editing and unsending spread across messaging platforms, treating the latest user intent as something that must be reconciled, rather than assumed on first receipt, becomes a baseline requirement for bot backends.