เบอร์โทรไม่ใช่สิ่งที่ WhatsApp ใช้ระบุตัวลูกค้าของคุณอีกต่อไป CRM ส่วนใหญ่ยังตามไม่ทัน
WhatsApp กำลังย้ายอัตลักษณ์ลูกค้าออกจากเบอร์โทร และถ้าคุณรัน CRM หรือ integration ส่งข้อความแบบไหนก็ตาม การเปลี่ยนแปลงนี้มาถึงคุณแล้ว นับตั้งแต่การ rollout ช่วงปลายเดือนมีนาคมถึงต้นเดือนเมษายน 2026 ทุก WhatsApp Cloud API message webhook พา identity field ใหม่ชื่อ Business-Scoped User ID หรือ BSUID มาด้วย ซึ่งเป็น token แบบ opaque ที่ Meta ออกให้ต่อพอร์ตโฟลิโอธุรกิจ [1][2] มันมาในรูป field ของตัวเอง ไม่ใช่ค่าใหม่ที่ยัดลงใน field เบอร์โทรเดิม และตัวเบอร์โทรเองตอนนี้อาจหายไปได้แล้วเมื่อผู้ใช้เลือกตั้ง WhatsApp username ถ้าคุณจะเปลี่ยนอะไรสักอย่างหลังอ่านบทความนี้ ให้เปลี่ยนสิ่งนี้ ปฏิบัติกับ BSUID เป็น identity key ในทุกข้อความขาเข้า เก็บเบอร์โทรเป็น alias ที่เป็น null ได้ และเลิกคิดว่า to, from หรือ wa_id จะถือเบอร์โทรไว้ [2] ส่วนที่เหลือของบทความนี้คือแผนที่ราย field ที่ตรวจกับเอกสารหลักแล้ว พร้อมข้อผิดพลาดที่กำลังถูกพูดถึงกันอยู่
มีสองสิ่งกำลังมาถึงพร้อมกัน และเกือบทุกคนเอาสองสิ่งนี้ไปรวมกัน หนึ่งคือฟีเจอร์ความเป็นส่วนตัวสำหรับผู้ใช้ นั่นคือ WhatsApp username ที่ให้ใครสักคนติดต่อธุรกิจได้โดยไม่ต้องยื่นเบอร์ของตัวเองให้ อีกอันคือการเปลี่ยนอัตลักษณ์สำหรับนักพัฒนา นั่นคือ BSUID ซึ่งโผล่มาใน Cloud API ไม่ว่าผู้ใช้คนนั้นจะเคยตั้ง username หรือไม่ก็ตาม username ได้พาดหัวข่าว แต่ BSUID ต่างหากที่เงียบ ๆ ทำให้ integration พัง จึงคุ้มที่จะแยกสองสิ่งนี้ออกจากกัน มันรันบนไทม์ไลน์ต่างกัน และแตะคนละส่วนของ stack คุณ
สองชั้น ไม่ใช่ชั้นเดียว
ข่าวส่วนใหญ่ปฏิบัติกับ "WhatsApp usernames" และ "BSUID" เป็นการเปิดตัวเดียว จริง ๆ แล้วมันคือสองชั้น มุ่งไปที่คนละกลุ่ม และมีรัศมีผลกระทบต่างกันมาก
| ชั้น |
คืออะไร |
กระทบใคร |
สถานะ ณ มิถุนายน 2026 |
| WhatsApp username |
handle สาธารณะที่เลือกใช้ได้ ให้ผู้ใช้ถูกติดต่อได้โดยไม่ต้องแชร์เบอร์โทร [2][6] |
ผู้ใช้ปลายทาง (opt-in ไม่มีใครถูกบังคับให้ตั้ง) |
beta จำกัดตั้งแต่เมษายน 2026 การ rollout วงกว้างเริ่มมิถุนายน 2026 [2][3][5] |
| Business-Scoped User ID (BSUID) |
identity token แบบ opaque ตัวใหม่ใน Cloud API มีให้ทุกผู้ใช้ไม่ว่าจะใช้ username หรือไม่ [1][2] |
ทุกธุรกิจ ทุก CRM และทุก BSP integration บนแพลตฟอร์ม |
live ใน message webhook ตั้งแต่การ rollout ช่วงปลายมีนาคมถึงต้นเมษายน 2026 [1][2][5] |
ช่องว่างตรงนั้นแหละที่ทำให้ทีมสะดุด คุณรอให้ username rollout เสร็จก่อนแล้วค่อยทำงานไม่ได้ เพราะฝั่งนักพัฒนา ship ไปแล้ว BSUID อยู่ใน webhook ของคุณตอนนี้แล้ว รวมถึงสำหรับผู้ใช้ที่จะไม่มีวันเข้าใกล้ฟีเจอร์ username เลยด้วย
การ rollout พร้อมวันที่
หมุดหมายตามวันที่ด้านล่างดึงมาจากเอกสาร BSP ที่สะท้อนคำแนะนำสำหรับพาร์ตเนอร์ของ Meta ตรงไหนที่วันที่เป็นการ rollout ที่ยังดำเนินอยู่ ไม่ใช่จุดสลับที่ตายตัว เราจะบอกไว้
| วันที่ |
หมุดหมาย |
ชั้น |
| ปลายมีนาคม / ต้นเมษายน 2026 |
BSUID เริ่มปรากฏใน Cloud API และ BSP message webhook หน้าหลักของ Meta บอกว่าต้นเมษายน ส่วนตารางไทม์ไลน์ของ Azure และ 360dialog บอกว่า 31 มีนาคม [1][2][5] |
นักพัฒนา |
| ต้นเมษายน 2026 |
Contact Book เปิดตัว: ที่เก็บ mapping เบอร์โทรกับ BSUID ที่ Meta โฮสต์และเปิดเป็นค่าเริ่มต้น [2] |
นักพัฒนา |
| เมษายน 2026 |
WhatsApp username beta จำกัดสำหรับผู้ใช้กลุ่มเล็ก [3][5] |
ผู้ใช้ |
| พฤษภาคม 2026 (วันที่แน่นอนยังรอ) |
Cloud API โดยตรงของ Meta เริ่มรองรับการส่งไปยัง BSUID ผ่าน recipient field ใหม่ [1] |
นักพัฒนา |
| มิถุนายน 2026 |
username เริ่มถึงมือผู้ใช้ปลายทาง และธุรกิจเริ่มจอง handle ได้ ส่วน Azure และ Twilio วางกรอบความพร้อมในการส่งของ wrapper ไว้ราวช่วงนี้ [2][3] |
ผู้ใช้ |
| ตลอดที่เหลือของปี 2026 |
การขยายแบบเป็นขั้นทีละประเทศไปสู่ความพร้อมใช้งานวงกว้าง [5] |
ผู้ใช้ |
มีวันที่หนึ่งที่ควรมีหมายเหตุ และมันเป็นภาพประกอบที่ชัดเจนของการแยก raw API กับ BSP ที่บทความนี้ย้อนกลับมาพูดถึงเรื่อย ๆ หน้า BSUID ของ Meta เองบอกว่า Cloud API โดยตรงจะยังไม่รองรับการส่งไปยัง BSUID จนถึงพฤษภาคม 2026 โดยวันที่แน่นอนยังรออยู่ [1] ส่วน Azure และ Twilio วางกรอบความพร้อมใช้งานจริงไว้ราวมิถุนายน 2026 ผูกกับช่วงที่ username ถึงมือผู้ใช้ปลายทาง [2][3] ดังนั้นให้ปฏิบัติกับความพร้อมส่ง outbound เป็นเรื่องเฉพาะของผู้ให้บริการ contract ดิบคือ recipient field ใหม่ แต่ตอนที่คุณจะใช้มันได้จริงขึ้นอยู่กับว่าคุณอยู่บน API โดยตรงหรือ BSP และแต่ละอันก็มาถึงตามวันของตัวเองได้ ยืนยันของคุณกับผู้ให้บริการของคุณ
webhook ขาเข้าหน้าตาจริง ๆ เป็นแบบไหน
นี่คือจุดที่งานเขียนส่วนใหญ่ผิดพลาด บน Cloud API โดยตรง BSUID เป็น field ของตัวมันเอง มันไม่ใช่ wa_id เดิมที่ถือค่าชนิดใหม่
| Field (raw Cloud API) |
พาอะไร |
มีเมื่อ |
contacts[].user_id |
BSUID ของผู้ใช้ |
เสมอ ในทุก message webhook [1][6] |
messages[].from_user_id |
BSUID ของผู้ส่ง |
เสมอ ในทุก message webhook [1] |
contacts[].profile.username |
WhatsApp username |
เฉพาะเมื่อผู้ใช้ตั้งไว้แล้ว [1][6] |
contacts[].wa_id |
เบอร์โทร |
เมื่อมีเบอร์ จะถูกละไว้เมื่อมีการใช้ username แล้วและเงื่อนไขการแนบเบอร์ไม่ครบ [2] |
messages[].from |
เบอร์โทรของผู้ส่ง |
เงื่อนไขเดียวกับ wa_id [2] |
statuses[].recipient_user_id |
BSUID ของผู้รับ |
บน status webhook ไม่ว่าการส่งเดิมจะใช้เบอร์โทรหรือ BSUID ข้อยกเว้นเดียว: status ที่ล้มเหลวซึ่งข้อความถูกจ่าหน้าด้วยเบอร์โทร [1][6] |
รูปร่างที่ต้องจำคือ user_id และ from_user_id อยู่ตรงนั้นเสมอ ขณะที่ field เบอร์โทรไม่เสมอ เมื่อมีเบอร์ คุณจะได้ทั้งคู่พร้อมกัน เบอร์อยู่ใน wa_id และ from ส่วน BSUID อยู่ใน user_id และ from_user_id [2] เมื่อผู้ใช้ตั้ง username แล้วและไม่มีประวัติเร็ว ๆ นี้กับคุณ field เบอร์โทรอาจมาแบบว่างเปล่าหรือหายไป และ BSUID คือสิ่งเดียวที่ระบุตัวผู้ส่ง
Meta จะให้เบอร์โทรไหลต่อเมื่อเงื่อนไขข้อใดข้อหนึ่งเป็นจริง โดยตรวจต่อเบอร์โทรของธุรกิจ ไม่ใช่ต่อพอร์ตโฟลิโอ: [2]
- คุณส่งข้อความหรือโทรหาเบอร์ของผู้ใช้ภายใน 30 วันที่ผ่านมา
- คุณได้รับข้อความหรือสายจากเบอร์ของผู้ใช้ภายใน 30 วันที่ผ่านมา
- ผู้ใช้อยู่ใน Contact Book ของคุณ
ดังนั้นบทสนทนาที่กำลังดำเนินอยู่ไม่มีปัญหา เบอร์จะหายไปสำหรับ contact ที่เป็น username-only ใหม่และไม่มีประวัติ ซึ่งบังเอิญเป็นกลุ่มเดียวกันเป๊ะที่ธุรกิจ lead-gen ต้องรับมือทั้งวัน นั่นคือข้อความแรกจากคนที่คุณไม่เคยคุยด้วยมาก่อน
ชื่อ field ของ Cloud API โดยตรงต่างจากชื่อของ BSP คุณ
ถ้าคุณไม่ได้อยู่บน Cloud API โดยตรง Business Solution Provider ของคุณได้เปลี่ยนชื่อ field เหล่านี้ไป การอ่านคู่มือ integration ของ BSP แล้วไปไล่หาชื่อพวกนั้นใน payload ดิบของ Cloud API คือทางตันที่พบบ่อย
| พื้นผิว |
ชื่อ field ของ BSUID |
แหล่งที่มา |
| Direct Cloud API |
contacts[].user_id และ messages[].from_user_id |
[1] |
| Twilio |
ExternalUserId |
[3] |
| Infobip |
contact.userId |
[4] |
| Azure Communication Services |
fromBSUID (ขาเข้า) และ toBSUID (delivery status) |
[2] |
ข้างใต้มันคือ BSUID แบบ opaque ตัวเดียวกันไม่ว่าทางไหน เปลี่ยนแค่ wrapper ที่ห่อรอบมัน
การจ่าหน้าขาออก: endpoint เดิม แต่ raw API เพิ่ม recipient
endpoint การส่งไม่เปลี่ยน แต่ field ของ raw Cloud API เปลี่ยน การส่งด้วยเบอร์โทรยังใช้ to ส่วนการส่งด้วย BSUID ใช้ recipient field ใหม่ [1] ต้องมีอย่างน้อยหนึ่งในสองอันปรากฏ และถ้าคุณส่งทั้งคู่ Meta จะให้ to มีสิทธิ์ก่อน จึงเป็น input การจ่าหน้าที่แยกกัน ไม่ใช่ field เดียวที่ตรวจจับอัตโนมัติว่าคุณยื่นอะไรให้ [1] นี่คือจุดที่ BSP wrapper เบี่ยงออกจาก contract โดยตรงมากที่สุด ตัวอย่างเช่น Azure Communication Services รับได้ทั้งเบอร์โทรหรือ BSUID ในอาเรย์ to เดียวของมันและจัดการให้คุณ [2] ซึ่งเป็นการ normalize ที่สะดวก แต่ไม่ใช่สิ่งที่ raw API ทำ ถ้าบทความของคุณอ้างว่าจะ map Cloud API โดยตรง อย่างที่บทความนี้ทำ recipient คือ field ที่สำคัญ
รูปแบบจุกจิกไม่ว่าทางไหน BSUID คือ ISO 3166 alpha-2 country code แล้วตามด้วยจุด แล้วตามด้วยอักขระ alphanumeric สูงสุด 128 ตัว เช่น US.13491208655302741918 ตัว country code และจุดเป็นส่วนหนึ่งของค่า [2] ดังนั้นการตัดมันทิ้งหรือ "normalize" BSUID แบบที่คุณอาจจัดเบอร์โทรให้เรียบร้อย จะทำให้การส่งพัง
มีข้อยกเว้นจริงอยู่หนึ่งข้อ template หมวด authentication ยังต้องใช้เบอร์โทร template auth แบบ one-tap, zero-tap และ copy-code ส่งไปยัง BSUID ไม่ได้ และการลองทำจะคืน Meta error 131062 [6] ถ้า flow รหัสผ่านครั้งเดียวของคุณรันผ่าน WhatsApp มันต้องใช้เบอร์ ซึ่งเป็นอีกเหตุผลหนึ่งที่ควรคว้าคู่เบอร์โทรกับ BSUID ไว้ตอนที่ยังมีเบอร์อยู่
โมเดลอัตลักษณ์: opaque, scoped และไม่ใช่ย้อนกลับได้เสมอ
พฤติกรรมของ BSUID ตัดสินว่ามันอยู่ตรงไหนในโมเดลข้อมูลของคุณ แต่ละแถวด้านล่าง map ไปยังการตัดสินใจด้านดีไซน์อย่างหนึ่ง
| คุณสมบัติ |
พฤติกรรม |
| Scope |
unique ต่อพอร์ตโฟลิโอธุรกิจ ผู้ใช้คนเดียวกันมี BSUID ต่างกันกับทุกธุรกิจที่เขามีปฏิสัมพันธ์ด้วย จึงไม่ใช่ key ของบุคคลทั่วทั้งแพลตฟอร์ม [1][2] |
| Opacity |
token แบบ opaque มันไม่ใช่เบอร์โทรและไม่มีความหมายที่ parse ได้นอกเหนือจาก country prefix [2] |
| Format |
{ISO 3166 alpha-2}.{alphanumeric สูงสุด 128 ตัว} ใช้ทั้งก้อน รวมถึง country code และจุด [2] |
| การเปลี่ยน username |
คงที่ การเปลี่ยน username ไม่เปลี่ยน BSUID [2] |
| การเปลี่ยนเบอร์โทร |
สร้างใหม่ การเปลี่ยนเบอร์โทรทำให้เกิด BSUID ตัวใหม่ และ Meta ส่ง user_id_update webhook ที่พา BSUID ทั้งตัวเก่าและตัวใหม่มาด้วยเพื่อให้คุณเชื่อมใหม่ได้ [1][2] |
เชื่อมใหม่เมื่อ identifier เปลี่ยน อย่าสร้างซ้ำ
เมื่อมีใครเปลี่ยนเบอร์โทรบนบัญชีของตน BSUID จะถูกสร้างใหม่ และ Meta ประกาศมันผ่าน user_id_update webhook ที่มีเอกสารกำกับ ซึ่งพา BSUID ทั้งตัวเก่าและตัวใหม่มาด้วย [1][2] ใช้ BSUID ตัวเก่าหาระเบียนที่มีอยู่ และใช้ตัวใหม่อัปเดตมัน เพื่อให้การเปลี่ยนแปลงลงเอยเป็นการ merge แทนที่จะเป็น contact ใหม่ ถ้าคุณปฏิบัติกับมันเป็นผู้ใช้ใหม่เอี่ยม คุณจะได้ประวัติของคนคนเดียวถูกแยกออกเป็นสองระเบียน
มีสิ่งหนึ่งที่ต้องทำให้ถูก นี่เป็น payload การเปลี่ยน identifier ของตัวมันเอง ไม่ใช่ delivery status ดังนั้นอย่าต่อการเชื่อมใหม่เข้ากับ statuses[] callback ที่อยู่ที่อื่นในแผนที่นี้ เอกสาร BSP บางรายยังเปิด system message คู่ขนานสำหรับการเปลี่ยนแปลงเดียวกันออกมาด้วย จึงควรยืนยันรูปร่าง payload ที่แน่นอนเทียบกับเอกสารอ้างอิงสด ๆ ของ Meta ก่อนสร้างต่อบนมัน พฤติกรรมเหมือนกันทุกที่: identifier เปลี่ยนแล้ว ดังนั้นเชื่อมใหม่แทนการสร้างซ้ำ
การกู้เบอร์โทรเดินหน้าได้อย่างเดียว
Contact Book ของ Meta เก็บ mapping เบอร์โทรกับ BSUID ให้อัตโนมัติ มัน Meta โฮสต์ เปิดเป็นค่าเริ่มต้น และ scope ไปที่พอร์ตโฟลิโอธุรกิจ [2] จุดที่ทำให้คนแปลกใจคือ มันบันทึกเฉพาะปฏิสัมพันธ์จากหลังจากที่มันเปิดตัวในเดือนเมษายน 2026 ไม่เคยย้อนเติม และไม่มีอะไรให้บันทึกสำหรับ contact ที่เป็น username-only ใหม่เอี่ยมที่ไม่เคยแชร์เบอร์ [2] ดังนั้นคุณวางใจไม่ได้ว่าจะกู้เบอร์โทรสำหรับ contact ที่มีแต่ BSUID ได้ทีหลัง
ซึ่งนำไปสู่นิสัยง่าย ๆ ข้อหนึ่ง เมื่อใดที่ webhook มีเบอร์โทรมาด้วย ให้เก็บคู่เบอร์โทรกับ BSUID ตอนนั้นเลย อย่าทิ้งไว้ทำทีหลัง
รูปแบบโมเดลข้อมูลที่เป็นมาตรฐาน
ทุก CRM และทุก integration ส่งข้อความลงเอยที่รูปร่างเดียวกัน และมันเป็นการเปลี่ยนแปลงเล็ก ๆ ที่สร้างบนกฎข้อเดียว BSUID คือ primary key ส่วนเบอร์โทรคือ alias
- เก็บ BSUID เป็น identity key หลักที่คงทนต่อคู่ (business, contact) เก็บเบอร์โทรเป็น alias เสริมที่เป็น null ได้บนระเบียนเดียวกัน [2][5]
- อ่าน BSUID field (
user_id หรือ from_user_id หรือตัวเทียบเท่าของ BSP คุณ) เป็นอัตลักษณ์ที่เชื่อถือได้ในทุกข้อความขาเข้า เลิกอ่าน to, from หรือ wa_id เป็นเบอร์โทรที่การันตี [2]
- เก็บคู่เบอร์โทรกับ BSUID ทุกครั้งที่มีเบอร์ เพราะ Contact Book จะไม่ย้อนเติมให้คุณ [2]
- merge เมื่อมี identifier คู่ ถ้าคุณมี contact ตามเบอร์โทรอยู่แล้วและ BSUID ตัวใหม่มาถึงสำหรับคนเดียวกันระหว่างบทสนทนาที่กำลังดำเนินอยู่ ให้เชื่อมพวกมันแทนการสร้างระเบียนที่สอง
- เมื่อเกิด event การเปลี่ยน identifier ให้เชื่อม contact เดิมเข้ากับ BSUID ตัวใหม่ [2]
ถ้า schema ของคุณ key WhatsApp contact ไว้ที่เบอร์โทร นั่นคือสิ่งแรกที่ต้องแก้ เพราะตอนนี้เบอร์โทรคือ field ที่หายไปได้ และ BSUID คือ field ที่มาถึงเสมอ
ความเข้าใจผิดที่พบบ่อย
สิ่งเหล่านี้กำลังถูกพูดถึงในโพสต์ของเวนเดอร์และในเธรด integration อยู่แล้ว ส่วนใหญ่เป็นทางลัดที่ฟังดูสมเหตุสมผลซึ่งผ่าน review ไปได้ลื่น ๆ แล้วล้มลงครั้งแรกที่ลีดที่เป็น username-only โผล่มา
BSUID ก็แค่ wa_id field ที่มีค่าชนิดใหม่ ไม่ใช่อย่างนั้น มันเป็น field แยกต่างหาก คือ contacts[].user_id และ messages[].from_user_id นั่งอยู่ข้าง ๆ field เบอร์โทร [1] โค้ดที่เฝ้าดู wa_id เพื่อหา "ค่าที่หน้าตาต่างไป" จะพลาด BSUID ไปเลยในทุก payload ที่มีเบอร์อยู่ด้วย
เบอร์โทรอยู่ตรงนั้นเสมอ ดังนั้นการ parse from เป็นเบอร์จึงปลอดภัย ไม่อีกต่อไป เมื่อผู้ใช้ตั้ง username แล้วและไม่มีประวัติเร็ว ๆ นี้กับคุณ from และ wa_id อาจว่างเปล่าหรือหายไป [2] อะไรก็ตามที่ validate หรือ format field เหล่านั้นเป็นเบอร์แบบ E.164 จะพังกับ contact ที่คุณต้องการมากที่สุดพอดี นั่นคือ contact ใหม่
คุณแค่หย่อน BSUID ลงใน to field แล้ว API จัดการให้เอง นั่นจริงบน BSP wrapper บางรายอย่าง Azure ACS [2] แต่ไม่จริงบน raw Cloud API API โดยตรงเก็บ to ไว้สำหรับเบอร์โทรและเพิ่ม recipient field แยกสำหรับการส่งด้วย BSUID โดย to มีสิทธิ์ก่อนถ้ามีทั้งคู่ [1] ใส่ BSUID ใน to กับ raw API แล้วคุณจะไม่ได้ส่งอย่างที่คุณคิด template authentication เป็นข้อยกเว้นเพิ่มเติม มันยังต้องใช้เบอร์โทรและคืน error 131062 ถ้าคุณชี้มันไปที่ BSUID [6]
คุณตัด country prefix และจุดออกเพื่อ "ทำความสะอาด" BSUID ได้ ทำไม่ได้ ตัว country code และจุดเป็นส่วนหนึ่งของค่า และการเปลี่ยนส่วนใดส่วนหนึ่งของมันทำให้ request ล้มเหลว [2]
BSUID ระบุตัวบุคคลทั่วทั้งแพลตฟอร์ม ไม่เลย มัน scope ต่อพอร์ตโฟลิโอ ดังนั้นคนเดียวกันถือ BSUID ต่างกันกับทุกธุรกิจ คุณใช้มันจดจำใครสักคนข้ามสองธุรกิจหรือแชร์อัตลักษณ์ระหว่างพอร์ตโฟลิโอที่ไม่เกี่ยวข้องกันไม่ได้ [1][2] มันคืออัตลักษณ์ภายในโลกของคุณ ไม่ใช่ข้ามแพลตฟอร์ม
Contact Book หมายความว่าคุณ look up เบอร์โทรทีหลังได้เสมอ มันเดินหน้าได้อย่างเดียว มันบันทึก mapping จากหลังจากที่มันเปิดตัวในเดือนเมษายน 2026 ไม่เคยย้อนเติม และไม่มีอะไรให้บันทึกสำหรับ contact ที่เป็น username-only ที่ไม่เคยแชร์เบอร์ [2] เก็บคู่นั้นไว้เองตอนที่คุณยังมีมัน
event การเปลี่ยนเบอร์โทรหมายถึงผู้ใช้ใหม่ มันคือผู้ใช้คนเดิมที่มี BSUID ถูกสร้างใหม่ ดังนั้นเชื่อมระเบียนเดิมใหม่ [2] ถ้าสร้างซ้ำแทน คุณจะแยกประวัติของคนคนเดียวออกเป็นสอง contact
หมายเหตุสำหรับทีมที่อยู่บน protocol ไม่ทางการ: BSUID ไม่ใช่ @lid
ถ้า stack ของคุณแตะ protocol multi-device ไม่ทางการผ่านไลบรารีอย่าง Baileys ด้วย คุณคงเคยเจอ identifier อีกตัวมาแล้ว นั่นคือ @lid "LinkedID" JID ที่โผล่มาเมื่อ JID เบอร์โทรจริงของผู้ใช้ถูกซ่อนไว้ [8] สิ่งเหล่านี้ดูเหมือนเป็นอันเดียวกัน แต่ไม่ใช่
BSUID เป็น construct ทางการของ Cloud API ที่ scope ต่อพอร์ตโฟลิโอและ opaque ส่งมาใน webhook field ที่มีเอกสารกำกับ ส่วน @lid JID อยู่ภายในการจ่าหน้า multi-device ของ WhatsApp และเป็น global ต่อผู้ใช้ ไม่ได้ scope ไปที่ธุรกิจเดียว [8] ทั้งสองไล่ตามแนวคิดเดียวกันคือเอาอัตลักษณ์ออกจากเบอร์โทร แต่เป็นกลไกคนละตัวบนพื้นผิวคนละที่ และ mapping ที่คุณสร้างให้อันหนึ่งจะใช้กับอีกอันไม่ได้
เส้นตายผูกพันบน WhatsApp มากกว่าบนช่องทางอื่น
บน WhatsApp การเปลี่ยนอัตลักษณ์มาลงบนช่องทางที่รันบนนาฬิกาอยู่แล้ว Business Platform ของ Meta ให้หน้าต่าง customer-service 24 ชั่วโมงแก่คุณ เมื่อผู้ใช้ส่งข้อความหาคุณ คุณมีเวลา 24 ชั่วโมงในการตอบแบบ free-form หลังจากนั้นตัวเลือก outbound เดียวของคุณคือ template ที่ได้รับอนุมัติล่วงหน้าและคิดเงิน [7] ข้อความแรกจากลีดที่เป็น username-only อาจมาถึงพร้อม BSUID ไม่มีเบอร์โทร และ timer 24 ชั่วโมงนั้นกำลังนับถอยหลังอยู่แล้ว integration ที่จดจำ เก็บ และตอบ contact นั้นด้วย BSUID ของมันไม่ได้ ไม่ใช่แค่ขาดโมเดลข้อมูลที่สะอาด มันพลาดหน้าต่างการตอบฟรีได้ และพลาดลีดไปพร้อมกัน
ดังนั้นเราจึงไม่ได้ปฏิบัติกับความพร้อม BSUID เป็นเรื่องที่ทำหรือไม่ทำก็ได้ และเราไม่ได้รอให้การ rollout บีบมือเรา StaffOS รันรูปแบบที่บทความนี้เถียงอยู่แล้ว เรา key WhatsApp contact ไว้ที่ identifier ของแพลตฟอร์มที่คงทน เก็บเบอร์โทรเป็น alias ที่เป็น null ได้ เก็บคู่เบอร์โทรกับ BSUID ทุกครั้งที่มีเบอร์ และเชื่อมใหม่เมื่อเกิด event user_id_update แทนการสร้างซ้ำ สำหรับเรา การสัมผัสครั้งแรกที่เป็น username-only คือ contact ธรรมดาตั้งแต่ข้อความแรก ไม่ใช่กรณีพิเศษที่ต้องพึ่ง logic เบอร์โทร ถ้าคุณกำลังชั่งน้ำหนักเวนเดอร์ WhatsApp รายหนึ่งกับอีกราย ให้ใช้การ audit ข้างต้นเป็นเกณฑ์: งานควรเสร็จไปแล้ว ไม่ใช่ยังนั่งอยู่บน roadmap
ต้องตรวจอะไรก่อน ship
เอกสารแพลตฟอร์มคือ source of truth และมันยังถูกเติมเต็มไปเรื่อย ๆ ในขณะที่การ rollout ฝั่งผู้ใช้ดำเนินต่อ ก่อนเขียนโค้ดเทียบกับ payload ใดอันหนึ่ง ให้ตรวจสามอย่างเทียบกับเอกสารอ้างอิงสด ๆ ของ Meta: รูปร่างที่แน่นอนของ payload การเปลี่ยน identifier ของ user_id_update, ว่า BSP ของคุณยื่น field ดิบหรือเวอร์ชันที่เปลี่ยนชื่อของมันเองให้คุณ, และว่ามี field ใหม่ใดโผล่ในออบเจ็กต์ contacts ตั้งแต่ตอนที่เขียนสิ่งนี้หรือยัง แผนที่ข้างต้นสะท้อนเอกสารหลักและเอกสารพาร์ตเนอร์ ณ มิถุนายน 2026 และเราจะอัปเดตเมื่อ Meta เปลี่ยนพื้นผิว
ถ้าอะไรในนี้ไม่ตรงกับเอกสารสดอีกต่อไป บอกเรา แล้วเราจะแก้ ประเด็นทั้งหมดคือมันยังตรวจสอบได้