บทช่วยสอน September 23, 2026

จัดการ LINE Unsend โดยไม่ให้ข้อความที่ลบแล้วกลับมาในกล่องข้อความ

เมื่อผู้ใช้ LINE ยกเลิกการส่งข้อความ ควรนำเนื้อหาออกจากหน้าจอฝ่ายบริการและหยุดใช้งานในระบบปลายทาง คู่มือ webhook ทางการของ LINE แนะนำให้เลิกแสดงข้อความและลบเนื้อหาที่จัดเก็บไว้ สำหรับการเชื่อมต่อผ่าน UnifyPort ให้จัดการอีเวนต์มาตรฐาน message.deleted ด้วยเครื่องหมายการลบที่บันทึกถาวร และงานล้างข้อมูลที่ลองใหม่ได้ การลบเพียงแถวในกล่องข้อความไม่พอ เพราะอีเวนต์ที่มาช้าอาจสร้างข้อความขึ้นใหม่ ขณะที่ระบบค้นหาหรือ AI ยังมีสำเนาอยู่

ประเด็นสำคัญ

การรับแจ้งว่าข้อความถูกยกเลิกการส่ง ไม่ใช่การเรียก API เพื่อสั่งยกเลิกข้อความ
ใช้ ID ของอีเวนต์ตรวจรายการซ้ำ แต่ระบุข้อความเป้าหมายด้วย data.message.id และขอบเขตบัญชี
เก็บเครื่องหมายการลบเท่าที่จำเป็น เพื่อไม่ให้อีเวนต์รับหรือแก้ไขที่มาช้าคืนเนื้อหา
ติดตามการล้างระบบปลายทางแยกกัน การตอบรับ webhook ไม่ได้ยืนยันว่าสำเนาทั้งหมดถูกลบแล้ว

LINE Unsend หมายถึงอะไรต่อข้อมูลที่เก็บไว้

คู่มือรับข้อความของ LINE ระบุว่าเมื่อผู้ใช้ยกเลิกการส่ง จะมี unsend event ส่งไปยังเซิร์ฟเวอร์ และแนะนำให้เคารพเจตนาของผู้ใช้ ไม่ให้เนื้อหานั้นถูกดูหรือใช้งานต่อ เช่น นำออกจากหน้าจอจัดการและลบออกจากพื้นที่จัดเก็บ

นี่คือคำแนะนำทางการ ส่วนเครื่องหมายการลบ transactional outbox และการทดสอบด้านล่างเป็นข้อเสนอการออกแบบแอปพลิเคชัน ไม่ใช่ฟีเจอร์ของ LINE หรือคำวินิจฉัยเรื่องระยะเวลาเก็บข้อมูลตามกฎหมาย

การแก้ไขคือการแทนที่เนื้อหา แต่การยกเลิกการส่งคือการหยุดใช้เนื้อหา หากรองรับการแก้ไขด้วย ให้ใช้ขั้นตอนปรับข้อมูลด้วย LINE message.updated ต่อไป แต่ตรวจสถานะการลบก่อนเขียนข้อความใหม่ ประวัติการแก้ไขต้องไม่กลายเป็นสำเนาที่ซ่อนอยู่แต่เจ้าหน้าที่หรือระบบค้นหายังอ่านได้

แยกสัญญาข้อมูลของแต่ละช่องทาง

ตัวรับ LINE Messaging API ทางการและตัวรับ UnifyPort ใช้รูปแบบ payload และการตรวจสอบต่างกัน อย่าส่ง payload ดั้งเดิมของ LINE เข้า handler สำหรับอีเวนต์มาตรฐานโดยไม่มีตัวแปลงแยกต่างหาก

เอกสารอีเวนต์มาตรฐานของ 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 ระบุข้อความที่ถูกนำออก อย่าใช้ตัวแรกค้นหาข้อความ และอย่าตีความการไม่มี text ว่าเป็นการแก้ไขให้ข้อความว่าง

สร้างแนวป้องกันการคืนข้อมูลก่อนเริ่มล้าง

เพิ่ม message.deleted ใน subscribed_events ควบคู่กับอีเวนต์รับและแก้ไขที่ต้องใช้ เปิด signing_secret แล้วทำตามสัญญาการส่ง webhook เพื่อตรวจ HMAC-SHA256 ของ timestamp ตามด้วยจุดและ raw request body พร้อมตรวจความใหม่ของ timestamp ก่อนรับงาน บทเรียนป้องกัน replay อธิบายว่าทำไมการตรวจลายเซ็นกับการป้องกันรายการซ้ำแบบถาวรจึงต้องทำแยกกัน

หลังตรวจสอบความน่าเชื่อถือและ payload แล้ว:

ระบุเป้าหมายภายใน workspace แพลตฟอร์ม และบัญชีรับส่งข้อความที่ถูกต้อง ใช้ ID บทสนทนาและข้อความเมื่อมี หากไม่มีบริบทบทสนทนา ให้ใช้เฉพาะ mapping ภายในบัญชีที่มีอยู่และไม่กำกวม ห้ามเดาข้ามแชต แยกรายการที่ระบุไม่ได้เพื่อให้ตรวจสอบ
ใน transaction เดียว บันทึกการกันอีเวนต์ซ้ำ สร้างหรือคงเครื่องหมายการลบ ลบเนื้อหาที่ใช้งาน และเพิ่มงานล้างข้อมูล ประสานให้การเปลี่ยนสถานะนี้ทำงานเป็นลำดับกับการรับหรือแก้ไขเป้าหมายเดียวกัน
ตอบ 2xx หลังรับข้อมูลแบบถาวรแล้ว ให้ worker ลองล้างปลายทางใหม่ได้โดยอิสระ
ทุกจุดที่เขียนจากอีเวนต์รับหรือแก้ไขต้องตรวจเครื่องหมาย อีเวนต์ที่มาช้าต้องไม่เติมเนื้อหากลับหรือสร้างงาน AI ใหม่

ตารางนี้เป็นกฎสถานะที่แนะนำสำหรับแอป ไม่ใช่ฟิลด์ API:

สถานะที่เก็บไว้	สิ่งที่เข้ามา	การทำงาน
ยังไม่มีต้นฉบับ	การลบ	เก็บเครื่องหมายที่ไม่มีเนื้อหา ไม่รอต้นฉบับ
มีเนื้อหาที่ใช้งาน	การลบ	หยุดแสดงและเพิ่มงานล้าง
มีเครื่องหมายการลบ	รับหรือแก้ไข	ไม่คืนเนื้อหา
มีเครื่องหมายการลบ	การลบซ้ำ	คงสถานะและทำงานล้างที่ค้างต่อ

อย่าอาศัยลำดับที่มาถึงหรือ timestamp ล่าสุดอย่างเดียว UnifyPort ไม่รับประกันลำดับการส่ง เครื่องหมายคือกฎที่แอปเลือกใช้เพื่อให้การลบยังมีผลต่อข้อความเดิม

ติดตามสำเนา ไม่ใช่แค่แถวในกล่องข้อความ

เก็บ mapping ระหว่างข้อความต้นทางกับสิ่งที่สร้างจากข้อความนั้น รายการต่อไปนี้เป็นจุดที่ต้องสำรวจ ไม่ใช่งานที่ UnifyPort ลบให้โดยอัตโนมัติ:

สำเนาหรืองาน	สิ่งที่แนะนำ
เนื้อหาและตัวอย่างในกล่องข้อความ	ลบเนื้อหาและทำให้แคชใช้ไม่ได้
ไฟล์แนบที่ดาวน์โหลด	ลบสำเนาและภาพย่อที่ระบบดูแล
ดัชนีค้นหาและเวกเตอร์	ลบรายการและระงับการดึงข้อมูลระหว่างรอลบ
บริบท AI สรุป และคำตอบรอส่ง	ตัดต้นทางออก ทำให้สรุปที่เกี่ยวข้องใช้ไม่ได้ ยกเลิกหรือตรวจงานที่พึ่งพาข้อมูล
สำเนาใน CRM หรือแชตทีม	ลบหรือปิดบังเมื่อรองรับ และติดตามส่วนที่ยังจัดการไม่ได้
raw-event log คิวงานล้มเหลว และข้อมูลสำรอง	ใช้นโยบายสิทธิ์เข้าถึงและการเก็บข้อมูล ป้องกันการคืนสู่หน้าจอใช้งาน

worker ควรตรวจสถานะการลบอีกครั้งก่อนดึงข้อมูล ก่อนเผยแพร่ข้อความที่สร้าง และเมื่อสร้างดัชนีใหม่ หากทำได้ ให้ขั้นตอนเผยแพร่ประสานกับกลไกป้องกันระดับข้อความเดียวกัน งานที่ส่งให้ระบบภายนอกไปแล้วอาจเรียกคืนไม่ได้ ต้องบันทึกข้อจำกัดแทนการรับประกันว่าลบได้ทั้งหมด

เครื่องหมายขั้นต่ำอาจเก็บเพียงตัวระบุที่มีขอบเขตและสถานะการล้าง โดยไม่เก็บข้อความที่ถูกยกเลิก กำหนดระยะเวลาเก็บตามความต้องการด้าน replay การกู้คืน และความเป็นส่วนตัว หากลบเครื่องหมายขณะที่อีเวนต์เก่ายังนำมาประมวลผลใหม่ได้ เนื้อหาอาจกลับมาอีก

การทดสอบรับมอบและข้อจำกัด

ใช้ข้อความทดสอบที่ควบคุมได้ ไม่ใช้ข้อมูลลูกค้า รายการนี้เป็นการทดสอบที่เสนอ ไม่ใช่ผลทดสอบจริง:

การลบมาถึงก่อนต้นฉบับ แล้วอีเวนต์รับที่มาทีหลังไม่คืนเนื้อหา
ลบระหว่างงานแก้ไขหรือสร้างดัชนี แล้วไม่มีการเผยแพร่ซ้ำ
รับการลบซ้ำแล้วไม่เกิดผลข้างเคียงซ้ำ แต่งานล้างที่ค้างยังลองใหม่
ปลายทางลบไม่สำเร็จ กล่องข้อความยังซ่อนเนื้อหาและแสดงสถานะงานค้างอย่างชัดเจน
กู้ข้อมูลสำรองแล้วใช้เครื่องหมายการลบก่อนเปิดการค้นหาหรือกล่องข้อความ

UnifyPort เป็นอินเทอร์เฟซที่ไม่เป็นทางการพร้อมสตรีมอีเวนต์มาตรฐาน ไม่ได้ลบข้อมูลใน CRM หรือ AI ให้โดยอัตโนมัติ ไม่มี REST API อ่านประวัติข้อความ และไม่รับประกัน replay ของอีเวนต์ที่พลาด การไม่ได้รับอีเวนต์ลบ ไม่ได้พิสูจน์ ว่าไม่มีการยกเลิกการส่ง หากผลิตภัณฑ์ต้องการสัญญา LINE Official Account แบบดั้งเดิม ให้เลือกเส้นทางทางการ

คำถามที่พบบ่อย

message.deleted เป็นคำสั่งยกเลิกข้อความของคนอื่นหรือไม่?

ไม่ใช่ เป็นรายงานการลบหรือเรียกคืนที่ตรวจพบ การล้างสำเนาที่ระบบของคุณเก็บเป็นคนละงานกับการสั่งงานแพลตฟอร์ม

กู้ข้อความต้นฉบับจาก payload การลบได้หรือไม่?

ไม่ได้ เอกสารรับประกัน ID เป้าหมาย ไม่ใช่ข้อความหรือสื่อที่ถูกนำออก อย่าออกแบบการจัดการยกเลิกการส่งเป็นฟีเจอร์กู้เนื้อหา

HTTP 200 หมายถึงลบทุกสำเนาแล้วหรือไม่?

ไม่ใช่ เป็นการยืนยันรับการส่ง แอปต้องติดตามผลการล้างและความล้มเหลวแยกต่างหาก

ขั้นตอนถัดไปและแหล่งข้อมูล

ตรวจตาราง webhook แต่ละแพลตฟอร์ม แล้วเพิ่มการทดสอบ “ลบก่อนต้นฉบับมาถึง” ก่อนเปิดใช้ AI ปลายทาง

ตรวจสอบแหล่งข้อมูลเมื่อ 2026-09-23:

UnifyPort API

เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร

เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน

รับ API Key ดูเอกสารอ้างอิง API