ปักหมุดแชทกับปักหมุดข้อความ WhatsApp: เลือก API ให้ถูก
การปักหมุดแชทใน WhatsApp ช่วยให้ค้นหาห้องสนทนาในรายการแชทได้ง่าย ส่วนการปักหมุดข้อความใช้เน้นเนื้อหาบางข้อความภายในห้องนั้น ทั้งสองอย่างไม่ใช่การตั้งค่าเดียวกัน หากทำกล่องข้อความร่วมผ่าน API ให้เลือกเป้าหมายก่อน: แชทต้องใช้ ID ของห้องสนทนา ส่วนข้อความต้องมี ID ของข้อความด้วย และควรระบุ ID ผู้ส่งอย่างชัดเจนเมื่อเป็นข้อความของคนอื่น
ประเด็นสำคัญ
- การปักหมุดแชทจัดการรายการแชทของบัญชีที่เชื่อมต่อ ส่วนการปักหมุดข้อความเลือกเนื้อหาในห้อง
- UnifyPort มีคนละ endpoint และมีวิธีเลิกปักหมุดต่างกัน
- การปักหมุดห้องสนทนาไม่มีพารามิเตอร์ระยะเวลา ส่วนข้อความมี
duration_secondsแบบไม่บังคับ pinnedในconversation.updatedเป็นสถานะรายการแชท ไม่ใช่สถานะปักหมุดข้อความ
ปักหมุดแชทกับปักหมุดข้อความต่างกันอย่างไร
คู่มือส่งข้อความหาตัวเองของ WhatsApp อธิบายการปักหมุดแชทไว้ด้านบนของรายการ ส่วนคู่มือปักหมุดข้อความ ให้เลือกข้อความและระยะเวลาปักหมุด แม้ใช้คำเดียวกัน แต่เป้าหมายต่างกัน
| เป้าหมายงาน | สิ่งที่ต้องเลือก | อย่าสรุปว่า |
|---|---|---|
| หาบทสนทนาของลูกค้าได้สะดวก | รายการแชท | ข้อความของลูกค้าบางข้อความจะถูกเน้นด้วย |
| เน้นคำแนะนำในกลุ่ม | ข้อความหนึ่งข้อความ | กลุ่มจะย้ายขึ้นบนสุดของกล่องข้อความ |
| มอบหมายงานด่วนให้เจ้าหน้าที่ | ทิกเก็ตหรือคิวของแอป | การปักหมุดจะตั้งผู้รับผิดชอบหรือกำหนดส่ง |
คู่มือทางการระบุว่า เมื่อปักหมุดข้อความในกลุ่ม จะมีข้อความระบบแจ้งว่าใครเป็นผู้ปักหมุด และผู้ดูแลกลุ่มสามารถกำหนดให้สมาชิกปักหมุดได้หรือไม่ได้ จึงไม่ควรนำเสนอปุ่มนี้เป็นบุ๊กมาร์กส่วนตัวของเจ้าหน้าที่ นอกจากนี้ ผู้ใช้ที่ไม่มีประวัติที่เกี่ยวข้องอาจมองไม่เห็นข้อความที่ปักหมุด การปักหมุดจึงไม่ใช่การกู้คืนเนื้อหา
หากต้องการเพียงเตือนเจ้าหน้าที่ภายในระบบของคุณ แนะนำให้สร้างบุ๊กมาร์กในแอปแทนการเปลี่ยนสถานะบนแพลตฟอร์มโดยอัตโนมัติ นี่เป็นข้อเสนอด้านการออกแบบ ไม่ใช่ฟีเจอร์ API เพิ่มเติม
เลือกสัญญา API ของ UnifyPort ตามเป้าหมาย
รายการต่อไปนี้เป็น unofficial interface ของ UnifyPort ไม่ใช่ Meta Cloud API
| รายละเอียด | ปักหมุดห้องสนทนา | ปักหมุดข้อความ |
|---|---|---|
| Method และ path | POST /v1/accounts/{account_id}/conversations/pin | POST /v1/messages/pin |
| การเลือกบัญชี | account_id ใน URL | account_id ใน JSON |
| เป้าหมายใน JSON | conversation_id | conversation_id, message_id และระบุ sender_id สำหรับข้อความของผู้อื่น |
| การเลือกสถานะ | path หมายถึงการปักหมุด | pinned: true เพื่อปักหมุด และ pinned: false เพื่อเลิก |
| ระยะเวลา | ไม่มีพารามิเตอร์ระยะเวลา | ใส่ duration_seconds ได้เมื่อปักหมุด |
| การเลิกปักหมุด | endpoint แยกสำหรับห้องสนทนา | endpoint ข้อความเดิม โดยส่ง pinned: false |
ตรวจสอบเอกสารปักหมุดห้องสนทนา, เลิกปักหมุดห้องสนทนา และปักหมุดหรือเลิกปักหมุดข้อความ ก่อนสร้าง request
อย่านำตัวเลือกระยะเวลาจากหน้าจอแอปมาเพิ่มเองใน API ของห้องสนทนา และอย่าส่ง pinned: false ไปยัง endpoint ปักหมุดห้องสนทนาแล้วคาดหวังว่าจะเลิกปักหมุด ต้องยึดสัญญาของ operation ที่เรียกจริง
ตารางรองรับการทำงานของแต่ละแพลตฟอร์ม ปัจจุบันระบุการปักหมุดและเลิกปักหมุดห้องสนทนาสำหรับ WhatsApp และ LINE แต่การปักหมุดข้อความรองรับเฉพาะ WhatsApp คู่ที่ไม่รองรับคืน 501 unsupported_by_provider สำหรับทีมไทยที่รวม LINE ไว้ในกล่องข้อความร่วม ควรแยกสิทธิ์เปิดใช้ปุ่มทั้งสอง อย่าเปิดปุ่มปักหมุดข้อความเพียงเพราะ LINE รองรับการปักหมุดแชท
เก็บข้อความที่เลือกไว้ ไม่เปลี่ยนเป็นข้อความล่าสุด
หากเลือกจากอีเวนต์ message.received ที่จัดเก็บแล้ว ให้จับคู่ตามเอกสารดังนี้:
account_idระดับบนของอีเวนต์ →account_iddata.conversation.id→conversation_iddata.message.id→message_iddata.sender.id→sender_id
เอกสารปักหมุดข้อความระบุว่า ถ้าไม่ส่ง sender_id จะใช้บัญชีที่เชื่อมต่อเองเป็นค่าเริ่มต้น จึงต้องระบุผู้ส่งเมื่อเลือกข้อความของสมาชิกคนอื่น ในกลุ่ม ID ห้องสนทนาหมายถึงกลุ่ม ส่วน ID ผู้ส่งหมายถึงผู้เขียน อย่าสลับกัน
ระหว่างที่เจ้าหน้าที่ตรวจสอบก่อนยืนยัน ให้รักษาเป้าหมายเดิมไว้ ข้อความใหม่ที่เข้ามาต้องไม่เปลี่ยน ID ที่เลือก และควรตรวจสอบว่าเจ้าหน้าที่มีสิทธิ์ดำเนินการกับบัญชีรับส่งข้อความและห้องนั้นก่อนส่ง request
ข้อความที่อ้างอิงข้อความก่อนหน้ามีอีกจุดที่อาจสับสน: ID ของข้อความต้นทางไม่ใช่ ID ของข้อความที่เลือก คู่มือการตอบกลับแบบอ้างอิงของ WhatsApp อธิบายความสัมพันธ์นี้ การปักหมุดใช้ ID ของข้อความที่เลือก ไม่ใช้ reply_token และไม่เลือกข้อความต้นทางแทนโดยอัตโนมัติ
ยืนยันผลให้ตรงระดับ
ตัวอย่างผลสำเร็จของทั้งสอง endpoint มี data.ok: true ให้บันทึกเป้าหมายและ response จริงแยกจากการกดปุ่ม หาก HTTP timeout ผลยังไม่แน่นอน อย่าแสดงว่าสำเร็จแล้วหรือส่งคำสั่งตรงข้ามเพื่อแก้ไขโดยอัตโนมัติ
เอกสารอีเวนต์ ระบุว่า conversation.updated ใช้ data.conversation.id เพื่อชี้แชท และอาจมี data.pinned สำหรับการเปลี่ยนสถานะปักหมุด นี่คือสถานะรายการแชทของบัญชีที่เชื่อมต่อ ไม่ได้บอกว่าข้อความใดในห้องถูกปักหมุด
อัปเดตเฉพาะค่าที่มีในอีเวนต์ เช่น อีเวนต์ปิดเสียงที่ไม่มี pinned ไม่ควรล้างสถานะปักหมุดที่เก็บไว้ ให้มองอีเวนต์เป็นข้อมูลที่สังเกตได้ ไม่ใช่การรับประกันว่าทุก API call จะมีอีเวนต์ยืนยัน ปัจจุบันแค็ตตาล็อกสาธารณะไม่มีอีเวนต์เฉพาะสำหรับปักหมุดข้อความ และตารางอีเวนต์ไม่ได้ระบุ conversation.updated สำหรับ LINE
เมื่อรับอีเวนต์ ให้ตรวจสอบลายเซ็นและจัดการการส่งซ้ำตามสัญญาการส่ง Webhook ใช้อีเวนต์ปรับมุมมองให้ตรงกัน ไม่ใช่เรียกคำสั่งแก้ไขเดิมซ้ำอีกครั้ง
แยกการปักหมุดออกจากลำดับความสำคัญของงาน
สมมติว่าทีมปักหมุดแชทระหว่างรอคำตอบจากลูกค้า ผู้รับผิดชอบ กำหนดเวลา และสถานะปิดงานยังต้องเก็บในแอป การเลิกปักหมุดไม่ควรปิดทิกเก็ตโดยไม่แจ้ง
การซิงก์อ่านแล้วและยังไม่อ่าน และการปิดเสียงเทียบกับการบล็อก ใช้หลักเดียวกัน: การมองเห็น สถานะการอ่าน การแจ้งเตือน และข้อจำกัดการติดต่อมีหน้าที่ต่างกัน
ก่อนเปิดใช้งาน แนะนำให้ทดสอบปักหมุดแชท การเลิกปักหมุดแยกต่างหาก ข้อความของสมาชิกกลุ่มคนอื่น แพลตฟอร์มที่ไม่รองรับ และ response ที่สูญหาย ทั้งหมดนี้เป็นรายการทดสอบที่เสนอ ไม่ใช่ผลทดสอบที่ดำเนินการแล้ว หากทำด้วยมือได้เพียงพอ ให้ใช้แอปโดยตรง และหากต้องการการเชื่อมต่อทางการ ให้ประเมินสัญญาของระบบนั้นแยกต่างหาก
คำถามที่พบบ่อย
ปักหมุดแชทแล้วข้อความล่าสุดจะถูกปักหมุดด้วยหรือไม่?
ไม่ ทั้งสอง operation มีเป้าหมายและ API ต่างกัน
ใช้ duration_seconds กับการปักหมุดห้องสนทนาได้ไหม?
ไม่ได้ตามสัญญาปัจจุบันของ UnifyPort ฟิลด์นี้เป็นของการปักหมุดข้อความ
pinned ใน conversation.updated ยืนยันการปักหมุดข้อความได้ไหม?
ไม่ได้ ค่านี้แสดงการตั้งค่ารายการแชทของบัญชีที่เชื่อมต่อ
LINE ใช้การปักหมุดได้ทั้งสองแบบหรือไม่?
ตารางปัจจุบันรองรับการปักหมุดและเลิกปักหมุดห้องสนทนา แต่ไม่รองรับการปักหมุดข้อความ ต้องตรวจสอบแต่ละ operation แยกกัน
ขั้นตอนถัดไปและแหล่งข้อมูล
เริ่มจากเอกสารปักหมุดห้องสนทนา และตั้งชื่อปุ่มให้ชัดว่าเปลี่ยนเป้าหมายใดก่อนเปิดใช้
ตรวจสอบเมื่อ 2026-10-08:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน