← บทความทั้งหมด
บทช่วยสอน

ตรวจสอบผ่าน 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:

UnifyPort API

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

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