Handle LINE Edited Messages With a message.updated Webhook

LINE added an edit event to the Messaging API on August 12, 2026. When a user edits a sent text message in an eligible group chat that includes a LINE Official Account, LINE can send a messageEdited webhook event. Your inbox should update the existing message, not append a second one. With UnifyPort, the corresponding normalized event is message.updated, keyed by the original data.message.id.

Key takeaways

• LINE’s provider event is named messageEdited; UnifyPort exposes the normalized event as message.updated.
• Match the edit to the stored message by account, conversation, and data.message.id.
• Store the new content while preserving an audit timestamp; do not count the edit as a new inbound message.
• Verify the HMAC-SHA256 signature before parsing, and make retries idempotent.
• Receiving a LINE edit does not mean the UnifyPort outbound edit action is available for LINE.

What changed in LINE group chats

LINE’s official Messaging API news page records the August 12, 2026 addition: users can edit messages in group chats containing a LINE Official Account, and the Messaging API now includes the messageEdited edit event. The current Messaging API reference lists an Edit event among its webhook event objects.

This change matters to shared inboxes, CRM timelines, search indexes, and AI context stores. If a customer corrects an order number, delivery address, or question, a system that ignores the edit continues acting on stale text. A system that inserts the edit as a new message creates a different problem: duplicate message counts and a conversation timeline that no longer matches LINE.

The correct model is a state change on one provider message.

LINE messageEdited vs UnifyPort message.updated

The official LINE payload is provider-specific. UnifyPort’s event layer gives the same update a standard envelope that can also represent edited messages from other supported providers:

{
  "id": "evt_7f42c18a9d",
  "type": "message.updated",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-08-22T09:15:30Z",
  "data": {
    "conversation": {
      "id": "c8f2a4d91e",
      "type": "group",
      "title": "Order support"
    },
    "sender": {
      "id": "u71b9d420f",
      "type": "user",
      "name": "Jordan Lee"
    },
    "message": {
      "id": "551842037194",
      "text": "Correction: the order number is A1234.",
      "direction": "inbound",
      "sent_at": "2026-08-22T09:12:04Z"
    },
    "event": {
      "kind": "message_updated"
    }
  }
}

The important distinction is between the two IDs:

• Top-level id identifies this webhook event and helps deduplicate delivery retries.
• data.message.id identifies the original message whose content changed.

The verified per-provider matrix is in Webhook standard event differences. It lists LINE support for message.updated; field availability can still vary with the upstream account and deployment.

Reconcile an edited message without duplicates

Use a composite lookup rather than assuming a provider message ID is globally unique:

(account_id, conversation_id, provider_message_id)

Then apply the update as an idempotent state transition:

1. Verify the signed raw request body.
2. Deduplicate the delivery by the webhook event ID.
3. Find the stored row using account_id, data.conversation.id, and data.message.id.
4. Replace the current text with data.message.text.
5. Save occurred_at as the edit observation time.
6. Keep the original receive time and, if your product requires it, an internal revision history.
7. Acknowledge with a 2xx response only after the durable write succeeds.

Here is a compact Express handler. The database calls are intentionally abstract so the event contract remains clear:

import crypto from 'crypto';
import express from 'express';

const app = express();
const secret = process.env.WEBHOOK_SIGNING_SECRET;

app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  const timestamp = req.get('X-Device-Timestamp') || '';
  const signature = req.get('X-Device-Signature') || '';
  const expected = crypto
    .createHmac('sha256', secret)
    .update(timestamp + '.')
    .update(req.body)
    .digest('hex');

  const valid = signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
  if (!valid) return res.sendStatus(401);

  const event = JSON.parse(req.body.toString('utf8'));
  if (await db.hasWebhookEvent(event.id)) return res.sendStatus(200);

  if (event.type === 'message.updated') {
    await db.applyMessageEdit({
      accountId: event.account_id,
      conversationId: event.data.conversation.id,
      messageId: event.data.message.id,
      text: event.data.message.text,
      editedAt: event.occurred_at
    });
  }

  await db.rememberWebhookEvent(event.id);
  return res.sendStatus(200);
});

For the full signing string, retry rules, and ordering caveats, use the webhook delivery and signature guide. The related HMAC replay-protection tutorial goes deeper on stale timestamps and durable idempotency.

Handle missing or out-of-order originals

Webhook delivery order is not guaranteed. An edit can reach a worker before the original message has committed, or the original may be absent because the receiver was offline. Do not create a normal timeline message and increment inbound analytics immediately.

Instead, place the update in a short-lived pending table keyed by the composite message identity. When the original message.received event arrives, apply the pending text before exposing the row. If the original never arrives, surface the record as an incomplete edited-message observation for operator review rather than silently presenting it as a complete message.

The same state-oriented approach works for emoji changes. See How to Process Message Reactions in a Unified Webhook for the parallel distinction between an event and the message state it changes.

Where UnifyPort fits—and where it does not

UnifyPort is useful when a small team receives LINE alongside WhatsApp, Telegram, TikTok, Zalo, or X and wants one signed event contract. The handler can branch on message.updated instead of maintaining a separate provider parser in every downstream service.

The official Messaging API remains the better fit when your application is centered on a LINE Official Account and needs LINE-native capabilities or the original provider payload. Also note the current action boundary: UnifyPort can normalize incoming LINE message updates, but its outbound POST /v1/messages/edit action is not currently supported for LINE. Receiving an edit and initiating an edit are separate capabilities.

FAQ

What is LINE messageEdited?

messageEdited is LINE’s official Messaging API webhook event for an eligible edit. LINE announced it for group chats containing a LINE Official Account on August 12, 2026.

What event name should a UnifyPort receiver subscribe to?

Subscribe to message.updated, or use the "*" wildcard if the endpoint intentionally receives every public standard event. Use exact event names in production filters.

Should an edited LINE message create a new inbox item?

No. Match data.message.id to the existing message and update its current content. Preserve revision metadata separately if your audit requirements need it.

Can I edit a LINE message through the UnifyPort edit endpoint?

Not currently. The provider action matrix does not list LINE support for the outbound edit action. This tutorial covers receiving and reconciling edits.

Next step

Review the per-provider webhook event matrix, add message.updated to your subscription, and test the idempotent update path before enabling it for a production inbox.

Sources

Checked August 22, 2026:

• LINE Developers: Messaging API news
• LINE Messaging API reference: webhook event objects