ตรวจสอบผ่าน API ว่าบันทึกผู้ติดต่อ WhatsApp แล้วหรือยัง
หากต้องการตรวจสอบว่ามีบุคคลหนึ่งอยู่ในรายชื่อผู้ติดต่อของบัญชี WhatsApp ที่เชื่อมต่อแล้วหรือไม่ ให้เรียก GET /v1/accounts/{account_id}/contacts/membership ของ UnifyPort โดยส่ง LID ที่ API ผู้ติดต่อส่งกลับมาเป็น contact_id ค่า data.is_in_contacts: false ในผลตอบกลับที่สำเร็จหมายถึง ยังไม่บันทึก ไม่ใช่คำขอล้มเหลว การตรวจสอบนี้ดูรายชื่อของบัญชีที่เชื่อมต่อ ไม่ได้บอกว่าอีกฝ่ายบันทึกหมายเลขของคุณหรือไม่
ประเด็นสำคัญ
- ใช้ LID ที่ API ผู้ติดต่อส่งกลับใน
conversation_idอย่าสร้างจากหมายเลขโทรศัพท์ - แยกผลในแอปเป็นสามสถานะ: บันทึกแล้ว ยังไม่บันทึก และไม่ทราบ
- การอยู่ในรายชื่อ ประวัติแชต สถานะบล็อก และสิทธิ์ส่งข้อความการตลาดเป็นคนละเรื่อง
- การตรวจสอบเป็นแบบอ่านอย่างเดียว การเพิ่มผู้ติดต่อควรเป็นอีกการกระทำที่ยืนยันแยกต่างหาก
ผลว่าบันทึกแล้วพิสูจน์อะไรได้บ้าง
คู่มือผู้ติดต่ออย่างเป็นทางการของ WhatsApp ระบุว่าการลบผู้ติดต่อไม่ได้ลบประวัติแชต ดังนั้นการเห็นบุคคลนั้นในรายการแชตจึงไม่ใช่หลักฐานว่ายังบันทึกเขาไว้ คู่มือเดียวกันยังอธิบายว่าผู้รับข้อมูลผู้ติดต่อเลือกเพิ่มลงในสมุดรายชื่อหรือส่งข้อความถึงบุคคลนั้นได้ การแชร์ข้อมูลกับการบันทึกจึงเป็นคนละการกระทำ
เอกสารตรวจสอบรายชื่อผู้ติดต่อของ UnifyPort ตอบคำถามที่เฉพาะเจาะจงกว่า: ผู้ติดต่อนี้อยู่ในรายชื่อของ บัญชีที่เชื่อมต่ออยู่ หรือไม่
| คำถาม | หลักฐานที่ควรใช้ |
|---|---|
| บัญชีที่เชื่อมต่อบันทึกบุคคลนี้หรือยัง | ผลตอบกลับสำเร็จและ is_in_contacts |
| อีกฝ่ายบันทึกหมายเลขของเราหรือไม่ | endpoint นี้ไม่ตอบคำถามนี้ |
| บุคคลนี้ถูกบล็อกหรือไม่ | กระบวนการตรวจสอบรายการบล็อกแยกต่างหาก |
| มีแชตหรือเคยแชร์บัตรผู้ติดต่อหรือไม่ | หลักฐานจากบทสนทนาหรือข้อความ |
| แอปติดต่อบุคคลนี้ได้หรือไม่ | การอนุญาตและนโยบายการสื่อสารที่ตรวจสอบแยกไว้ |
อ่านความแตกต่างระหว่างการเขียนรายชื่อกับการแชร์ข้อมูลได้ใน เพิ่มผู้ติดต่อหรือส่ง vCard อย่าเรียก API เพิ่มผู้ติดต่อเพียงเพื่อให้ตรวจสอบได้ง่ายขึ้น เพราะจะเปลี่ยนสถานะที่คุณตั้งใจจะตรวจ
เตรียมบัญชีและ LID ที่ส่งกลับจริง
UnifyPort เป็น อินเทอร์เฟซที่ไม่เป็นทางการ สำหรับบัญชีรับส่งข้อความที่เชื่อมต่อ ไม่ใช่ endpoint ของ WhatsApp Cloud API ปัจจุบันตารางการรองรับการกระทำตามช่องทาง ระบุว่าการตรวจนี้รองรับ whatsapp ไม่ใช่ LINE, Telegram, Zalo หรือผู้ให้บริการแยกอย่าง whatsapp-protocol หากหน้าจอเดียวกันดูแล LINE ด้วย ควรแสดงปุ่มนี้ตามความสามารถของแต่ละช่องทาง
เก็บบัญชีที่เลือกคู่กับผู้ติดต่อเสมอ ออบเจ็กต์ผู้ติดต่ออาจมีค่า id, provider_user_id และ conversation_id ต่างกัน สำหรับการตรวจนี้ เอกสารกำหนดให้ใช้ LID ที่ API ผู้ติดต่อส่งกลับใน conversation_id เก็บค่านั้นจากกระบวนการจัดการผู้ติดต่อที่ถูกต้องซึ่งมีอยู่แล้ว อย่าเติม @lid ต่อท้ายหมายเลขโทรศัพท์แล้วถือว่าเป็นตัวระบุที่ถูกต้อง
หากแอปมีเพียงหมายเลขโทรศัพท์ แต่ยังไม่มี LID ที่ได้รับกลับมาและตรวจสอบแล้ว ให้แสดงว่ายังตรวจไม่ได้จนกว่าจะยืนยันการจับคู่ตัวตน endpoint นี้ไม่ได้ระบุว่าเป็นบริการค้นหาหมายเลขโทรศัพท์ใด ๆ
ตัวอย่างคำขอต่อไปนี้ยังไม่ได้รันในบทความ กำหนดตัวแปรสภาพแวดล้อมจากบัญชีที่เลือกและข้อมูลจับคู่ผู้ติดต่อบนแบ็กเอนด์ เก็บ API key ไว้ฝั่งเซิร์ฟเวอร์ ไม่ส่งให้เบราว์เซอร์:
curl --get \
"https://api.unifyport.ai/v1/accounts/${UNIFYPORT_ACCOUNT_ID}/contacts/membership" \
-H "X-Api-Key: ${UNIFYPORT_API_KEY}" \
--data-urlencode "contact_id=${WHATSAPP_CONTACT_LID}"
การเข้ารหัสพารามิเตอร์ช่วยส่งตัวระบุที่มี @ ได้ถูกต้อง ผลตอบกลับสำเร็จประกอบด้วย data.contact_id และค่าบูลีน data.is_in_contacts
แสดงสามผลลัพธ์ ไม่ใช่ช่องทำเครื่องหมายเพียงช่องเดียว
ข้อผิดพลาดที่พบบ่อยในการออกแบบคือแปลงค่าที่หายไปหรือค่าที่ประเมินเป็นเท็จทั้งหมดให้เป็น “ยังไม่บันทึก” วิธีนี้จะทำให้ timeout ช่องทางที่ไม่รองรับ หรือผลตอบกลับผิดรูปแบบกลายเป็นข้อสรุปเชิงลบที่ไม่ถูกต้อง
JavaScript ตัวอย่างนี้แปล HTTP status และ JSON ที่รับและแปลงแล้ว ไม่ได้ส่งคำขอเครือข่าย:
function classifyMembership(httpStatus, body) {
if (httpStatus !== 200) return 'unknown';
const value = body?.data?.is_in_contacts;
if (value === true) return 'saved';
if (value === false) return 'not_saved';
return 'unknown';
}
สตริงเหล่านี้เป็น ป้ายสถานะของแอป ไม่ใช่ฟิลด์ตอบกลับเพิ่มเติมจาก API ให้จัดการข้อผิดพลาดการเชื่อมต่อและผลตอบกลับที่ไม่ใช่ JSON เป็นไม่ทราบก่อนเรียกฟังก์ชันนี้
| สิ่งที่ได้รับ | สถานะบนหน้าจอ | ขั้นตอนถัดไปที่แนะนำ |
|---|---|---|
200 และบูลีน true | บันทึกแล้ว | แสดงเวลาตรวจสอบ |
200 และบูลีน false | ยังไม่บันทึก | เสนอการเพิ่มที่แยกต่างหากและตรวจสิทธิ์แล้วเฉพาะเมื่อจำเป็น |
501 unsupported_by_provider | ไม่รองรับ / ไม่ทราบ | ตรวจช่องทางที่เลือก ไม่เพิ่มอัตโนมัติ |
| timeout คำขอล้มเหลว หรือไม่มีค่าบูลีน | ไม่ทราบ | เก็บข้อมูลวินิจฉัย แล้วตรวจสอบหรือรีเฟรช |
ผูกผลที่สังเกตได้กับบัญชี LID และเวลาตรวจที่แอปบันทึก อย่าใช้ผลแคชเดียวร่วมกันข้ามบัญชี หากเจ้าหน้าที่เปลี่ยนไปดูผู้ติดต่ออื่นแล้ว อย่านำผลตอบกลับที่มาช้ามาแสดงในรายการใหม่ และอย่าแสดงผลเก่าเหมือนเป็นการรับประกันถาวร
แยกการกระทำถัดไปออกจากการตรวจสอบ
ผลว่าไม่พบในรายชื่อไม่ได้ให้สิทธิ์เขียนข้อมูล หากเจ้าหน้าที่ต้องการบันทึกบุคคลนั้นจริง ๆ ให้ใช้ API เพิ่มผู้ติดต่อ แยกต่างหาก เก็บตัวระบุที่ส่งกลับ และตรวจรายชื่อซ้ำเมื่อจำเป็นต้องยืนยันสถานะปัจจุบัน
“ยังไม่บันทึก” ไม่ได้หมายถึง “ถูกบล็อก” บทความปิดเสียงกับบล็อกต่างกันอย่างไร อธิบายการควบคุมที่แยกกันเหล่านี้ อย่าปลดบล็อก ส่งข้อความทดสอบ หรือแก้ไขสมุดรายชื่อเป็นผลข้างเคียงของการแสดงสถานะ
เมื่อเกิดข้อผิดพลาด ให้เก็บ HTTP status และ request_id หากมี แต่ไม่บันทึก API key หรือข้อมูลผู้ติดต่อทั้งรายการลง log แอปควรกำหนดด้วยว่าเจ้าหน้าที่คนใดดูรายชื่อของแต่ละบัญชีได้
คำถามที่พบบ่อย
ตรวจได้ไหมว่าอีกฝ่ายบันทึกหมายเลขของฉันหรือยัง
ไม่ได้ API ตรวจเฉพาะรายชื่อของบัญชีที่เชื่อมต่อ ไม่ได้อ่านสมุดรายชื่อของอีกฝ่าย
is_in_contacts: false เป็นข้อผิดพลาดหรือไม่
ถ้าอยู่ในผลตอบกลับ 200 ที่สำเร็จ ถือเป็นผลเชิงลบตามปกติ ข้อมูลหายหรือคำขอล้มเหลวต้องถือว่าไม่ทราบ ไม่ใช่ false
ใช้ JID จากหมายเลขโทรศัพท์แทน LID ได้ไหม
อินพุต WhatsApp ที่ระบุในเอกสารคือ LID ที่ API ผู้ติดต่อส่งกลับใน conversation_id ใช้ค่านั้น ไม่ใช่ตัวระบุที่คาดเดา
ได้รับบัตรผู้ติดต่อแล้วแปลว่าบันทึกแล้วหรือไม่
ไม่ใช่ ข้อความที่มีข้อมูลผู้ติดต่อกับการแก้ไขสมุดรายชื่อเป็นคนละการกระทำ ให้ตรวจรายชื่อเมื่อจำเป็นต้องแยกสองกรณีนี้
ขั้นตอนถัดไปและแหล่งอ้างอิง
สร้างส่วนควบคุมแบบอ่านอย่างเดียวตามเอกสารตรวจสอบผู้ติดต่อ ก่อนใช้งานจริงให้ทดสอบ true, false, ข้อมูลหาย, ช่องทางไม่รองรับ, timeout และการเปลี่ยนผู้ติดต่อขณะคำขอยังรอผล รายการนี้เป็นข้อเสนอการทดสอบ ไม่ใช่รายงานผลที่รันแล้ว
ตรวจสอบแหล่งข้อมูลเมื่อ 2026-10-31:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน