การย้ายระบบ BSUID ของ WhatsApp เริ่ม 7 กรกฎาคม — เช็กลิสต์ 5 ข้อสำหรับทีมที่รับข้อความขาเข้าอย่างเดียว — UnifyPort

Meta กำลังเปลี่ยนวิธีระบุตัวตนผู้ใช้ WhatsApp ใน API ตั้งแต่วันที่ 7 กรกฎาคม 2026 (Wave 1) ฟิลด์ใหม่ที่เรียกว่า Business-Scoped User ID (BSUID) จะปรากฏใน webhook payload ทุกรายการ — และสำหรับผู้ใช้ที่เปิดใช้ WhatsApp username เบอร์โทรศัพท์อาจไม่แสดงอีกต่อไป

ถ้าคุณรับข้อความ WhatsApp เป็นส่วนหนึ่งของคิวซัพพอร์ต ระบบ CRM หรือ AI agent pipeline การเปลี่ยนแปลงนี้กระทบโค้ดของคุณแน่นอน แต่จะกระทบมากน้อยแค่ไหนขึ้นอยู่กับว่าข้อความ WhatsApp เดินทางผ่านเส้นทางไหนก่อนถึง backend ของคุณ — และถ้าคุณใช้แพลตฟอร์มหลายช่องทางอย่าง LINE ควบคู่กับ WhatsApp สำหรับตลาดไทย สิ่งที่ต้องตรวจสอบอาจมากกว่าที่คิด

บทความนี้เป็นเช็กลิสต์ 5 จุดที่ต้องตรวจสอบ ตารางตัดสินใจ 1 ตาราง และคำตอบชัดเจนสำหรับคำถามที่ทีมขนาดเล็กส่วนใหญ่กำลังถาม: “ต้องทำอะไรก่อนวันที่ 7 กรกฎาคมหรือเปล่า?”

BSUID คืออะไรกันแน่

ผู้ใช้ WhatsApp ทุกคนจะได้รับ identifier ใหม่: Business-Scoped User ID รูปแบบคือรหัสประเทศ 2 ตัวอักษร ตามด้วยจุด และตัวอักษร-ตัวเลขสูงสุด 128 ตัว — เช่น TH.1A2B3C4D5E6F7G8H9I0J คุณสมบัติสำคัญคือ: คนเดียวกันจะได้ BSUID ต่างกัน สำหรับแต่ละธุรกิจที่เขาติดต่อด้วย BSUID ของผู้ใช้ Alice ที่ธุรกิจคุณจะไม่เหมือนกับ BSUID ของ Alice ที่บริษัทอื่น

ไทม์ไลน์การเปิดตัวของ Meta:

Wave	วันที่	ขอบเขต
Wave 1	7 กรกฎาคม 2026	ตลาดเริ่มต้น
Wave 2	20 กรกฎาคม 2026	ขยายขอบเขต
ทั่วโลก	กันยายน 2026	ตลาดที่เหลือทั้งหมด

BSUID เริ่มปรากฏใน webhook payload ตั้งแต่วันที่ 31 มีนาคม 2026 ในฟิลด์ user_id ใหม่ แต่การเปลี่ยนแปลงที่กระทบจริงมาพร้อม Wave 1: เมื่อผู้ใช้เปิดใช้ WhatsApp username เบอร์โทรศัพท์อาจไม่ปรากฏในฟิลด์ wa_id และ from อีกต่อไป

เช็กลิสต์: 5 จุดที่ต้องตรวจสอบ

1. การ parse webhook payload

สิ่งที่เปลี่ยน: ฟิลด์ user_id ใหม่จะปรากฏใน message webhook ทุกรายการ สำหรับผู้ใช้ที่เปิด username ฟิลด์ wa_id และ from ที่เคยเป็นเบอร์โทรศัพท์อาจเปลี่ยนเป็น BSUID แทน — หรืออาจหายไปเลย

สิ่งที่ต้องตรวจสอบ: webhook handler ของคุณสันนิษฐานว่า from เป็นเบอร์โทรศัพท์เสมอหรือไม่? ใช้ regex จับเฉพาะตัวเลข ใช้เป็น database key หรือส่งเข้า library ตรวจสอบเบอร์โทรศัพท์? สิ่งเหล่านี้จะพังเมื่อ from มีค่าเป็น TH.1A2B3C4D5E... แทนที่จะเป็น 66812345678

2. CRM และการจับคู่ผู้ติดต่อ

สิ่งที่เปลี่ยน: ถ้า CRM ของคุณเก็บข้อมูลลูกค้าโดยใช้เบอร์โทรศัพท์เป็น key ข้อความจากผู้ใช้ที่เปิด username อาจมาถึงโดยไม่มีเบอร์โทรศัพท์เลย คุณจะหาข้อมูลลูกค้าไม่เจอ

สิ่งที่ต้องตรวจสอบ: ฐานข้อมูลผู้ติดต่อของคุณสามารถเก็บและจับคู่ด้วย BSUID ควบคู่กับเบอร์โทรศัพท์ได้หรือไม่? Meta มี Contact Book API ที่เก็บ mapping ระหว่างเบอร์โทรศัพท์กับ BSUID จากการสนทนาก่อนหน้า — แต่คุณต้องเรียกใช้ก่อนที่เบอร์โทรศัพท์จะหายไปจาก webhook ใหม่

3. ประวัติการสนทนาและการจัดกลุ่มข้อความ

สิ่งที่เปลี่ยน: ถ้าคุณจัดกลุ่มการสนทนาด้วยเบอร์โทรศัพท์ (เช่น “แสดงข้อความทั้งหมดจาก +66812345678”) ข้อความจากคนเดิมจะเริ่มมาภายใต้ BSUID แทน ประวัติการสนทนาจะแยกเป็นสองส่วน เว้นแต่คุณจะเชื่อมโยงข้อมูลเดิมที่ใช้เบอร์โทรศัพท์กับ BSUID ใหม่แล้ว

สิ่งที่ต้องตรวจสอบ: message store ของคุณใช้เบอร์โทรศัพท์เป็น primary key สำหรับ conversation thread หรือไม่? ถ้าใช่ วางแผน backfill: ใช้ Contact Book mapping เพื่อเชื่อมโยงข้อมูลที่ใช้เบอร์โทรศัพท์กับ BSUID ก่อน Wave 1

4. Template และการส่งข้อความขาออก

สิ่งที่เปลี่ยน: เมื่อส่ง template message (ขาออก) ในที่สุดคุณจะต้องระบุผู้รับด้วย BSUID แทนเบอร์โทรศัพท์ — โดยเฉพาะสำหรับผู้ใช้ที่เปิด username แล้วและเบอร์โทรศัพท์ไม่ถูกเปิดเผยอีกต่อไป

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

5. การจัดเก็บข้อมูลและการปฏิบัติตามกฎหมาย

สิ่งที่เปลี่ยน: BSUID เป็นข้อมูลส่วนบุคคล (PII) รูปแบบใหม่ แม้จะถูก scope ต่อธุรกิจ (ไม่สามารถใช้ cross-reference ผู้ใช้ข้ามบริษัทได้) แต่ก็ยังเป็น PII ภายใต้กรอบกฎหมายความเป็นส่วนตัวส่วนใหญ่ รวมถึง PDPA ของไทย

สิ่งที่ต้องตรวจสอบ: นโยบายการเก็บรักษาข้อมูลของคุณครอบคลุม identifier ประเภทใหม่นี้หรือไม่? ถ้าคุณมี flow การลบข้อมูลตาม PDPA ที่ระบุ identifier ทั้งหมดของผู้ใช้ ต้องรวม BSUID เข้าไปด้วย

คุณอยู่บนเส้นทางไหน?

ไม่ใช่ทุกทีมที่ต้องดำเนินการทั้ง 5 ข้อ ขึ้นอยู่กับว่าข้อความ WhatsApp ถึง backend ของคุณอย่างไร — และถ้าคุณจัดการช่องทางอื่นอย่าง LINE ด้วย (ซึ่งเป็นเรื่องปกติสำหรับทีมในประเทศไทย) เส้นทางที่เลือกจะส่งผลต่อทั้งสองช่องทาง

เส้นทางการเชื่อมต่อ	ข้อที่ต้องดำเนินการ	ระดับความพยายาม
Cloud API (ตรง)	ทั้ง 5 ข้อ	สูง — คุณ parse webhook ดิบของ Meta ทุกการเปลี่ยนแปลง payload กระทบโค้ดโดยตรง
BSP (Wati, 360dialog ฯลฯ)	ข้อ 2, 3, 4, 5	ปานกลาง — BSP อาจ abstract รูปแบบ webhook แต่ CRM และ logic การส่งยังต้องอัปเดต
อินเทอร์เฟซขาเข้าแบบไม่เป็นทางการ	ไม่มี	ศูนย์ — อ่านต่อ

ทำไมอินเทอร์เฟซขาเข้าแบบไม่เป็นทางการไม่ได้รับผลกระทบ

ถ้าข้อความ WhatsApp ของคุณมาถึงผ่านอินเทอร์เฟซแบบไม่เป็นทางการของ UnifyPort การย้ายระบบ BSUID ไม่กระทบ pipeline ของคุณเลย เหตุผลคือ: UnifyPort ไม่ส่งข้อความผ่าน Cloud API ของ Meta เส้นทางแบบไม่เป็นทางการเชื่อมต่อกับ WhatsApp โดยตรง ข้อความที่ webhook ของคุณได้รับจึงไม่เคยอยู่ในรูปแบบ Cloud API payload ตั้งแต่แรก

สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับทีมในประเทศไทยที่รับข้อความจากทั้ง WhatsApp และ LINE: UnifyPort ใช้ schema เดียวกันสำหรับทุกช่องทาง ดังนั้นไม่ว่าลูกค้าจะส่งข้อความมาทาง WhatsApp หรือ LINE backend ของคุณจัดการด้วย handler เดียวกัน — และไม่มีช่องทางไหนได้รับผลกระทบจากการเปลี่ยนแปลง identity model ของ Meta

Webhook ของคุณยังคงได้รับ event message.received เหมือนเดิม:

{
  "event": "message.received",
  "account_id": "acct_3qPmRz",
  "provider": "whatsapp",
  "from": "user_88c1ae",
  "text": "สวัสดีครับ ออเดอร์ #2241 ส่งแล้วหรือยัง?",
  "timestamp": 1751875200,
  "message_id": "wa_msg_f4e29a"
}

ฟิลด์ from เป็น user identifier แบบ normalized ของ UnifyPort เอง — ไม่ใช่เบอร์โทรศัพท์ ไม่ใช่ BSUID ไม่เคยเป็นเบอร์โทรศัพท์ตั้งแต่แรก จึงไม่มีอะไรต้อง migrate เมื่อ Meta เปลี่ยนระบบ identifier การจับคู่ CRM การจัดกลุ่มการสนทนา และการ parse webhook ทั้งหมดยังคงทำงานเหมือนเดิม

การตรวจสอบลายเซ็น HMAC-SHA256 บน webhook endpoint ของคุณก็ไม่ได้รับผลกระทบเช่นกัน — signing secret และรูปแบบลายเซ็นเป็นของ UnifyPort ไม่ใช่ของ Meta

สิ่งที่ต้องทำสัปดาห์นี้

ถ้าคุณใช้ Cloud API หรือ BSP: เริ่มจากเช็กลิสต์ข้อ 1 (การ parse webhook) บันทึกตัวอย่าง webhook ที่เข้ามาและตรวจสอบว่าฟิลด์ user_id ปรากฏแล้วหรือไม่ — ระบบเริ่มทยอยเปิดตั้งแต่ 31 มีนาคม ถ้ามีอยู่แล้ว แสดงว่า payload ของคุณกำลังเปลี่ยนแปลง ดำเนินการข้อ 2-5 ก่อนวันที่ 7 กรกฎาคม

ถ้าคุณใช้เส้นทางขาเข้าแบบไม่เป็นทางการ: ไม่มีอะไรเปลี่ยน การย้ายระบบ BSUID เป็นเรื่องของ Cloud API และข้อความของคุณไม่ได้ผ่าน Cloud API สร้างสิ่งที่คุณกำลังสร้างต่อไปได้เลย