ส่งข้อความผิด: ควรแก้ไข เรียกคืน หรือซ่อนเฉพาะในกล่องข้อความ?
เมื่อส่งข้อความผิดจากบัญชีที่เชื่อมต่อ ให้เลือกขอบเขตก่อน: แก้ไข คือแทนที่ข้อความที่ส่งแล้ว เรียกคืน คือขอถอนข้อความสำหรับทุกคนในบทสนทนา ส่วน ซ่อนในแอป เปลี่ยนเฉพาะหน้าจอของระบบคุณ เอกสาร UnifyPort ระบุการแก้ไขข้อความสำหรับ WhatsApp และการเรียกคืนสำหรับ Telegram, WhatsApp และ LINE ทั้งสองคำสั่งใช้กับข้อความที่บัญชีนั้นส่งเองเท่านั้น การรับ webhook แจ้งแก้ไขหรือลบได้ไม่ได้แปลว่าระบบสามารถสั่งทำสิ่งเดียวกันได้
ประเด็นสำคัญ
- แยกการแก้คำผิด การถอนข้อความของตัวเอง และการจัดหน้าจอเจ้าหน้าที่ออกจากกัน
- เก็บบัญชี บทสนทนา และข้อความเป็นเป้าหมายเดียวกัน อย่าเปลี่ยนไปเลือก “ข้อความล่าสุด” หลังยืนยัน
- ตรวจความสามารถในการสั่งงานแยกจากความสามารถในการรับเหตุการณ์
- ผล API เหตุการณ์ webhook และการล้างสำเนาในระบบปลายทางเป็นหลักฐานคนละส่วน
แก้ไข เรียกคืน และซ่อน ต่างกันอย่างไร
สมมติว่าเจ้าหน้าที่ส่งเวลานัดหมายผิด การแก้ข้อความกับการทำให้ข้อความหายจากหน้าจอเจ้าหน้าที่ไม่ได้แก้ปัญหาเดียวกัน
| สิ่งที่ต้องการ | วิธีที่เหมาะสม | สิ่งที่ยังยืนยันไม่ได้ |
|---|---|---|
| แก้ข้อความที่ส่งแล้ว | แก้ไขข้อความ | ผู้รับยังไม่เคยเห็นข้อความเดิม |
| ถอนข้อความที่บัญชีนี้ส่ง | เรียกคืนข้อความ | สำเนาที่บันทึกหรือส่งต่อถูกลบทั้งหมด |
| ซ่อนแถวในกล่องข้อความของคุณ | การควบคุมการแสดงผลในแอป | ข้อความในแชตของลูกค้าเปลี่ยนไป |
| ตอบสนองต่อการเรียกคืนที่พบ | ประมวลผล message.deleted | มีการส่งคำขอเรียกคืนใหม่ |
คำแนะนำการลบของ WhatsApp ระบุว่าผู้รับอาจเห็นข้อความก่อนถูกลบ และสื่อที่บันทึกใน Photos บน iOS อาจยังคงอยู่ อย่าตั้งชื่อปุ่มว่า “ลบทุกสำเนา” หรือถือว่าการเรียกคืนรับประกันว่าข้อมูลลับไม่เคยถูกเปิดเผย
การซ่อนในบทความนี้เป็นการออกแบบแอป ไม่ใช่ endpoint สำหรับลบข้อความเฉพาะฝั่งตัวเองที่ UnifyPort ระบุไว้ ส่วน conversation.deleted และ conversation.cleared บอกการเปลี่ยนแปลงบทสนทนาเฉพาะบัญชี ไม่ใช่การเรียกคืนข้อความหนึ่งรายการสำหรับทุกคน
ตรวจตารางคำสั่ง ไม่ใช่แค่ตารางเหตุการณ์
ตารางคำสั่งของแต่ละผู้ให้บริการ ระบุไว้ดังนี้
| ผู้ให้บริการ | แก้ข้อความที่ส่งแล้ว | เรียกคืนข้อความของตัวเอง |
|---|---|---|
whatsapp | รองรับ | รองรับ |
telegram | ไม่รองรับ | รองรับ |
line | ไม่รองรับ | รองรับ |
twitter, zalo, tiktok, whatsapp-protocol | ไม่รองรับ | ไม่รองรับ |
นี่คือความสามารถของ adapter ไม่ใช่การรับประกันว่าทุกคำขอจะผ่านเงื่อนไขของบัญชีหรือบริการต้นทาง คู่คำสั่งที่ยังไม่รองรับจะคืน 501 unsupported_by_provider
สำหรับทีมที่ใช้ LINE ต้องแยก การรับเหตุการณ์แก้ไขข้อความ ออกจากการสั่งแก้ไข บทความนั้นอธิบายการรวม message.updated เข้ากับข้อความเดิม ไม่ได้เปิดความสามารถในการแก้ข้อความ LINE ผ่าน UnifyPort อย่าเปิดปุ่มแก้ไขเพียงเพราะตัวรับเข้าใจเหตุการณ์นี้
สัญญาเรียกคืนของ UnifyPort ยังแคบกว่าฟังก์ชันดูแลกลุ่มแบบ native บางประเภท เพราะอนุญาตเฉพาะข้อความที่บัญชีเชื่อมต่อส่งเอง แม้เจ้าหน้าที่เป็นผู้ดูแลกลุ่ม ก็ไม่ควรเสนอคำสั่งนี้กับข้อความของสมาชิกคนอื่น
ตรึงเป้าหมายก่อนส่งคำขอ
ใช้ account_id, data.conversation.id และ data.message.id จาก message.received ที่เก็บไว้ เหตุการณ์นี้อาจเป็นข้อความขาเข้าหรือขาออก จึงต้องตรวจ data.message.direction และเจ้าของข้อความก่อนอนุญาตให้ทำงาน ค่า id ระดับบนสุดเป็น ID เหตุการณ์ ไม่ใช่ ID ข้อความ
ข้อแนะนำสำหรับแอป:
- ตรวจสิทธิ์เจ้าหน้าที่ต่อบัญชีรับส่งข้อความและบทสนทนาที่เลือก
- ตรึงตัวตนของข้อความในหน้าต่างยืนยัน พร้อมแสดงเนื้อหาปัจจุบันและขอบเขตคำสั่ง
- ตรวจช่องทางและยืนยันว่าบัญชีนี้เป็นผู้ส่ง สำหรับการแก้ไขต้องเป็นข้อความตัวอักษร
- จัดลำดับคำสั่งแก้ไขเป้าหมายเดียวกัน เพื่อไม่ให้เจ้าหน้าที่สองคนเขียนทับการตัดสินใจกัน
- เก็บประวัติคำสั่งและผลลัพธ์แยกจากเนื้อหาที่แสดง
ด้านล่างเป็น ตัวอย่าง JSON ที่ใช้ตัวระบุสมมติ ไม่ใช่ข้อมูลลูกค้าจริง ส่งจากเซิร์ฟเวอร์ด้วย X-Api-Key และอย่าใส่คีย์ในโค้ดเบราว์เซอร์
สำหรับ POST /v1/messages/edit ค่า content คือข้อความใหม่ทั้งชุด ไม่ใช่ส่วนต่าง:
{
"account_id": "acc_example",
"conversation_id": "8600000000000@s.whatsapp.net",
"message_id": "3EB0A185AAC596E2BB602C",
"content": "ขอแก้ไข: เวลานัดหมายคือ 15:00 น."
}สำหรับ POST /v1/messages/revoke เลือกเป้าหมายเดิมโดยไม่ส่งข้อความแทนที่:
{
"account_id": "acc_example",
"conversation_id": "8600000000000@s.whatsapp.net",
"message_id": "3EB0A185AAC596E2BB602C"
}เอกสารเรียกคืนระบุว่า sender_id มีค่าเริ่มต้นเป็นบัญชีเองและมักละได้ การใส่ผู้ส่งคนอื่นไม่เพิ่มสิทธิ์ อย่ากำหนดระยะเวลาแก้ไขร่วมกันทุกช่องทางขึ้นเอง หรือนำสิทธิ์จาก API อื่นมาใช้กับคำขอนี้
แยกผลคำขอออกจากการล้างสำเนา
ตัวอย่างผลสำเร็จของทั้งสอง endpoint มี data.ok: true ให้บันทึกผลจริง แต่ไม่ตีความว่าผู้รับทุกคนหรือระบบปลายทางลบเนื้อหาเดิมแล้ว
| สิ่งที่พบ | สิ่งที่ควรทำ |
|---|---|
501 unsupported_by_provider | ปิดคำสั่งสำหรับช่องทางนั้น ไม่ส่งซ้ำแบบเดิม |
edit_message_failed หรือ revoke_message_failed | ตรวจข้อผิดพลาดและบริบทเป้าหมายก่อนตัดสินใจ |
| HTTP หมดเวลาหรือคำตอบหาย | คงสถานะผลไม่แน่ชัดและตรวจสอบก่อนส่งอีกครั้ง |
พบ message.updated หรือ message.deleted ที่ตรงกัน | อัปเดตข้อความในขอบเขตที่ถูกต้องแบบ idempotent |
| ไม่พบเหตุการณ์ที่ตรงกัน | อย่าสรุปสำเร็จหรือล้มเหลวจากการไม่มีเหตุการณ์เพียงอย่างเดียว |
เก็บ request_id ตามคู่มือติดตามคำขอ เพื่อสอบสวนปัญหา ไม่ใช่ใช้เป็น idempotency token หรือคีย์เชื่อม webhook ที่มีการรับประกัน
ทำตามสัญญาการส่ง webhook: ตั้ง signing_secret ตรวจ HMAC-SHA256 จาก timestamp และ raw body ตรวจความใหม่ของเวลา แล้วบันทึกถาวรก่อนตอบรับ ลำดับเหตุการณ์ไม่ได้รับการรับประกัน สำเนาในระบบค้นหา CRM หรือ AI ของคุณยังต้องล้างแยกต่างหาก ดูคู่มือล้างเนื้อหาที่ถูกเรียกคืน สำหรับขอบเขตนี้
คำถามที่พบบ่อย
ใช้คำสั่งแก้ไขแทนที่ไฟล์แนบได้ไหม?
เอกสารรองรับเฉพาะข้อความตัวอักษร อย่าใช้ content เป็นฟิลด์แทนที่สื่อ
ซ่อนในกล่องข้อความแล้วลูกค้าจะไม่เห็นด้วยหรือไม่?
ไม่ใช่ การแสดงผลเฉพาะแอปกับการเรียกคืนบนช่องทางเป็นคนละคำสั่ง ต้องระบุขอบเขตในหน้าจอให้ชัดเจน
รองรับ message.deleted แปลว่าทุกการเรียกคืนมี callback หรือไม่?
ไม่ใช่ ตารางเหตุการณ์ไม่รับประกันว่าทุกบัญชีหรือทุกการติดตั้งต้นทางจะส่งทุกเหตุการณ์ เก็บผล HTTP แยกจากสถานะที่สังเกตได้
ขั้นตอนถัดไปและแหล่งข้อมูล
เริ่มจากเอกสารเรียกคืนข้อความ แล้วทดสอบการเลือกและยืนยันในบทสนทนาทดสอบที่ได้รับอนุญาต UnifyPort เป็นอินเทอร์เฟซที่ไม่เป็นทางการ ไม่ได้แทนที่กฎของแพลตฟอร์ม และไม่รับประกันการลบสำเนาภายนอก
ตรวจข้อมูลวันที่ 2026-10-12:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน