บทช่วยสอน October 29, 2026

ล้างกับลบแชต WhatsApp: ซิงก์สถานะ Webhook ให้ถูกต้อง

การล้างแชต WhatsApp จะล้างประวัติในเครื่องแต่ยังเก็บแชตไว้ ส่วนการลบแชตเป็นอีกการทำงานหนึ่งของรายการแชต ใน UnifyPort เหตุการณ์ conversation.cleared และ conversation.deleted รายงานการเปลี่ยนแปลงเหล่านี้สำหรับบัญชีรับส่งข้อความที่เชื่อมต่ออยู่ ทั้งสองเหตุการณ์ไม่ได้หมายความว่าข้อความถูกลบสำหรับทุกคน กล่องข้อความที่ทีมใช้ร่วมกันควรแยกการแสดงประวัติออกจากการแสดงบทสนทนา แล้วใช้นโยบายที่ชัดเจนกับสำเนาที่ระบบของตนจัดเก็บ

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

เป็นการแจ้งการเปลี่ยนแปลงภายในบัญชี ไม่ใช่คำสั่งลบข้อความของลูกค้า
data.conversation.id ระบุแชตเป้าหมาย ส่วน id ชั้นนอกระบุเหตุการณ์
delete_media อธิบายการลบสื่อในเครื่อง ไม่ได้ยืนยันว่าสื่อในที่เก็บไฟล์หรือ CRM ของคุณถูกลบแล้ว
การไม่ให้ประวัติเก่ากลับมาแสดง ไม่ควรเท่ากับการปฏิเสธข้อความใหม่ตลอดไป

ล้างแชต ลบแชต หรือเรียกคืนข้อความ?

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

เหตุการณ์ที่ได้รับ	ขอบเขตตามเอกสาร	แนวทางสำหรับกล่องข้อความ
`conversation.cleared`	บัญชีที่เชื่อมต่อล้างประวัติในเครื่อง บทสนทนาฝั่งคู่สนทนาและสมาชิกภาพกลุ่มไม่เปลี่ยน	เก็บรายการบทสนทนาไว้ และซ่อนประวัติที่เกี่ยวข้องตามนโยบาย
`conversation.deleted`	บัญชีลบบทสนทนาในเครื่อง	นำออกจากรายการที่สะท้อนสถานะบัญชี เก็บเฉพาะข้อมูลประกอบการตรวจสอบที่อนุญาต
`message.deleted`	ข้อความหนึ่งถูกลบหรือเรียกคืน	ระบุข้อความเป้าหมาย ไม่จัดการทั้งแชต
`conversation.updated`	การตั้งค่าแชตในบัญชีเปลี่ยน	อัปเดตค่าที่ได้รับ ไม่อนุมานว่าประวัติถูกลบ

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

อ่านเป็นเหตุการณ์บทสนทนา ไม่ใช่ payload ของข้อความ

เอกสาร conversation.cleared และ conversation.deleted ให้ข้อมูลบทสนทนาเป้าหมายและ delete_media แต่ไม่ได้ให้รายการ ID ของข้อความที่ได้รับผลกระทบ หรือจุดตัดประวัติที่แน่นอน

ตัวอย่างต่อไปนี้ใช้ฟิลด์ตามเอกสารและตัวระบุสมมติ ไม่ใช่ข้อมูลการรับส่งจริง:

{
  "id": "evt_c4d0b7a2e5",
  "type": "conversation.cleared",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-10-29T08:15:00Z",
  "data": {
    "conversation": {
      "id": "8600000000000@s.whatsapp.net",
      "type": "user"
    },
    "delete_media": true,
    "event": { "kind": "conversation_cleared" }
  }
}

ค้นหาระเบียนภายในด้วย workspace, provider, account_id และ data.conversation.id ร่วมกัน เก็บตัวระบุที่ได้รับตามเดิม ไม่ประกอบจากหมายเลขโทรศัพท์หรือรวมแชตเพียงเพราะชื่อเหมือนกัน สาขาการประมวลผลนี้ไม่ควรบังคับให้มี data.message.id เพราะเป็นเหตุการณ์ของบทสนทนา

ตารางรองรับเหตุการณ์แต่ละช่องทาง ปัจจุบันจับคู่สองเหตุการณ์นี้กับ whatsapp ไม่ใช่ provider แยกชื่อ whatsapp-protocol หรือทุกช่องทาง หากทีมดูแล LINE และ WhatsApp ในกล่องเดียวกัน ต้องไม่อนุมานว่ามีความสามารถเท่ากันเพียงเพราะใช้รูปแบบ webhook ร่วมกัน ตารางอธิบายการรองรับของตัวแปลงข้อมูล ไม่รับประกันว่าทุกบัญชีหรือทุกสภาพแวดล้อมของต้นทางจะส่งเหตุการณ์

แยกสถานะของแอปออกเป็นสามส่วน

กำหนดสิ่งที่ผลิตภัณฑ์รับปากก่อนลงมือทำระบบล้างข้อมูล กล่องข้อความที่สะท้อนบัญชีอาจซ่อนประวัติตามการเปลี่ยนแปลงในบัญชี ขณะที่แฟ้มงานบริการซึ่งมีนโยบายแยกอาจต้องเก็บต่างกัน อธิบายความต่างนี้ให้ผู้ปฏิบัติงานทราบ อย่าตีความการล้างในแอปต้นทางอย่างเงียบ ๆ ว่า “ไม่มีอะไรเกิดขึ้น” หรือ “ลบทุกระเบียนธุรกิจ”

จัดเก็บแนวคิดต่อไปนี้แยกกัน:

การแสดงในรายการ: บทสนทนาปรากฏในรายการที่สะท้อนบัญชีหรือไม่
การแสดงประวัติและสถานะการล้าง: เนื้อหาเก่าส่วนใดถูกซ่อน และสำเนาที่คุณดูแลส่วนใดยังต้องจัดการ
การรับข้อความในอนาคต: กิจกรรมใหม่จะเปิดบทสนทนาอีกครั้งได้เมื่อใด โดยไม่คืนประวัติเก่า

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

ทั้งสองเหตุการณ์ต้องปฏิบัติตามข้อกำหนดการส่ง webhook: ตั้ง signing_secret ตรวจ HMAC-SHA256 ของ X-Device-Timestamp ตามด้วยจุดและเนื้อหาคำขอดิบ พร้อมตรวจความใหม่ของ timestamp ภายใน transaction เดียว ให้ตัดเหตุการณ์ทั่วไปที่ซ้ำ บันทึกการเปลี่ยนสถานะการแสดง และเข้าคิวงานล้าง ตอบ 2xx หลังบันทึกอย่างคงทน ไม่ต้องรอระบบภายนอกทั้งหมดทำงานเสร็จ

อย่าให้การโหลดประวัติยกเลิกการตัดสินใจเดิม

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

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

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

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

การล้างสื่อและการทดสอบรับงาน

delete_media=true หมายความว่าสื่อในเครื่องถูกล้างหรือลบด้วย ไม่ได้ยืนยันว่าไฟล์แนบที่ดาวน์โหลด ดัชนีค้นหา บริบท AI หรือสำเนาที่ส่งต่อถูกลบแล้ว ส่วน false ก็ไม่ใช่สิทธิให้เก็บทุกอย่างไม่มีกำหนด ใช้นโยบายการเก็บและการเข้าถึงที่แจ้งผู้ใช้ไว้ และติดตามการล้างแยกจากการตอบรับ webhook

ทดสอบด้วยบัญชีที่คุณควบคุม:

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

นี่เป็นรายการทดสอบที่เสนอ ไม่ใช่ผลทดสอบที่รายงาน UnifyPort เป็นอินเทอร์เฟซที่ไม่เป็นทางการ ไม่มีการรับประกันส่งข้อมูลที่พลาดซ้ำ และไม่มี REST API สำหรับอ่านคืนประวัติข้อความ การไม่ได้รับเหตุการณ์ไม่ใช่หลักฐานว่าไม่มีการเปลี่ยนแปลงภายในบัญชี

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

conversation.deleted ลบข้อความของคู่สนทนาด้วยหรือไม่?

ไม่ใช่ เอกสารระบุการลบบทสนทนาในเครื่องของบัญชีที่เชื่อมต่อ ไม่ใช่การลบสำหรับทุกคน

conversation.cleared หมายความว่าออกจากกลุ่มแล้วหรือไม่?

ไม่ใช่ เอกสารระบุชัดว่าสมาชิกภาพกลุ่มไม่เปลี่ยน

ใช้ชื่อเหตุการณ์เพื่อสร้างปุ่มเรียก API ล้างแชตได้หรือไม่?

เหตุการณ์อธิบายสิ่งที่สังเกตพบ ไม่ใช่คำสั่งขาออกเพื่อล้างหรือลบ อย่าอนุมาน endpoint จากชื่อเหตุการณ์

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

เริ่มจากเอกสาร conversation.cleared แล้วกำหนดกฎการแสดง การเก็บ และการเปิดใหม่ ก่อนเชื่อมเข้ากับงานลบข้อมูล

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

UnifyPort API

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

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

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