บทช่วยสอน July 16, 2026

ย้าย WhatsApp Embedded Signup ไป v4: เช็กลิสต์ Coexistence ก่อน 15 ตุลาคม 2026

หาก integration ของคุณใช้ Coexistence เพื่อ onboarding หมายเลข WhatsApp Business app ที่มีอยู่แล้ว ให้ย้าย Embedded Signup v2 ไป v4 ก่อนวันที่ 15 ตุลาคม 2026 Meta กำหนดให้ v4 ใช้ Facebook Login for Business configuration ใหม่ การเลือก Embedded Signup และผลิตภัณฑ์ที่จำเป็นจะเปลี่ยน flow เป็น v4 ควรมองงานนี้เป็นการย้ายระบบ onboarding ไม่ใช่เพียงการเปลี่ยนหน้าตา interface โดยต้องทดสอบ permissions, callbacks, ตัวเลือก Coexistence, webhooks และการ sync ประวัติใหม่ทั้งหมด

ประเด็นสำคัญ

Meta ระบุว่า Embedded Signup v2 จะถูกยุติในวันที่ 15 ตุลาคม 2026 และแนะนำให้ย้ายไป v4 ก่อนวันดังกล่าวเพื่อหลีกเลี่ยงการหยุดชะงัก
V4 ตั้งค่าผ่าน Facebook Login for Business configuration ใหม่ การเลือกผลิตภัณฑ์จะกำหนด assets และ permissions ที่รวมอยู่ใน flow
WhatsApp Business app user onboarding ซึ่งเป็น flow ที่มักเรียกว่า Coexistence ยังคงรองรับใน v4
การย้ายที่สำเร็จต้องพิสูจน์มากกว่าแค่ “dialog เปิดได้” โดยต้องตรวจตัวเลือก Coexistence, finish callback, asset IDs, token exchange, webhook delivery และกรอบเวลา sync ประวัติ 24 ชั่วโมง
ทีมที่ไม่ต้องการให้ Business app อย่างเป็นทางการและ Cloud API ใช้หมายเลขเดียวกันควรตัดสินใจก่อนว่า Coexistence จำเป็นจริงหรือไม่

เอกสาร v4 ของ Meta ระบุว่า v4 เปิดตัวเมื่อวันที่ 8 ตุลาคม 2025 และปัจจุบันแทนที่ v2 ในฐานะเส้นทาง Embedded Signup เวอร์ชันปัจจุบัน การเปลี่ยนแปลงด้าน implementation ที่สำคัญที่สุดคือตำแหน่งที่ใช้กำหนด flow

ใน v2 ตัวเลือกสำคัญของ flow อยู่ใน object extras ที่ integration ส่งเข้ามา แต่ใน v4 Meta ให้ developer สร้าง Facebook Login for Business configuration ใหม่ เลือก Embedded Signup เป็น login variation และเลือกผลิตภัณฑ์ที่ต้องรวมใน flow ผลิตภัณฑ์ที่เลือกจะกำหนด v4 โดยอัตโนมัติ พร้อมเลือก assets และ permissions ที่จำเป็นไว้ล่วงหน้า

สิ่งนี้ทำให้ขอบเขตการตรวจสอบการย้ายเปลี่ยนไปดังนี้:

ส่วนของการย้าย	สิ่งที่ต้องตรวจใน v4	เหตุผลที่สำคัญ
Login configuration	Facebook Login for Business configuration ที่สร้างใหม่ใช้ variation แบบ Embedded Signup	การใช้ configuration v2 เดิมซ้ำไม่ใช่เส้นทาง v4 ตามเอกสาร
Products	เลือก Cloud API และ messaging products เพิ่มเติมอย่างตั้งใจ	การเลือกผลิตภัณฑ์กำหนดประสบการณ์ onboarding และ assets ที่ต้องใช้
Permissions	ทุก permission ที่ถูกเลือกอัตโนมัติมี Advanced Access	Dialog ที่ดูถูกต้องยังล้มเหลวได้หาก app ไม่มีสิทธิ์เพียงพอ
Coexistence	Flow มีตัวเลือกเชื่อมต่อ WhatsApp Business app account และ number ที่มีอยู่	Flow Cloud API เริ่มต้นไม่ใช่หลักฐานว่า Business app onboarding ยังทำงานหลังการย้าย
Session result	Finish event, asset IDs และ exchangeable token code กลับมาที่ spawning window	Backend ยังต้องใช้ผลลัพธ์นี้เพื่อทำ onboarding ให้เสร็จ
Webhooks	รับ payloads ของ history, state sync และ message echoes ได้	Coexistence พึ่งพาการ sync หลัง signup ไม่ใช่แค่ขั้นตอน signup

V4 ยังรวมการเลือก assets, business information และ permissions ไว้ด้วยกัน และสามารถเพิ่มผลิตภัณฑ์อย่าง Click to WhatsApp Ads และ Conversions API ได้ ส่วนเพิ่มเติมเหล่านี้ไม่จำเป็นสำหรับการย้ายที่ใช้เฉพาะ Coexistence ให้เลือกเฉพาะผลิตภัณฑ์ที่ integration รองรับจริง เพราะ dialog ที่กว้างขึ้นหมายถึง permissions และงานทดสอบที่เพิ่มขึ้น

รองรับ คู่มือ Business app onboarding ที่ Meta อัปเดตระบุชัดว่า WhatsApp Business app user onboarding ยังได้รับการรองรับ คู่มือนี้เรียกฟีเจอร์ดังกล่าวว่า “Coexistence” ในเอกสาร support และ partner

ควรอ่านหน้าเอกสารทางการร่วมกัน คู่มือ versions ทั่วไปแสดง object extras ที่ตั้งใจเว้นว่างสำหรับ v4 ขณะที่คู่มือ Coexistence เฉพาะทางยังระบุ feature selection whatsapp_business_app_onboarding และ session-info version อยู่ อย่าคิดว่าการลบค่าที่เกี่ยวกับ Coexistence ทั้งหมดออกจาก launcher เดิมจะทำให้ flow เดิมยังอยู่ ให้สร้าง configuration v4 ใหม่ ทำตามคำแนะนำ Business app onboarding ปัจจุบัน และตรวจหน้าจอกับ callback จริงด้วย test account

เส้นทางผู้ใช้ที่คาดหวังมีขั้นตอนเฉพาะ: ธุรกิจเลือกเชื่อมต่อ WhatsApp Business app account ที่มีอยู่ กรอกหมายเลขปัจจุบัน ยืนยันการเชื่อมต่อภายใน Business app แล้วทำ Embedded Signup ให้เสร็จ หลังจากนั้น Business app ยังจัดการข้อความแบบ one-to-one ได้ ขณะที่ข้อความ Cloud API และประวัติส่วนที่รองรับจะถูก sync

หากทีมยังตัดสินใจอยู่ว่าต้องใช้ workflow สองส่วนนี้หรือไม่ ให้อ่าน คู่มือตัดสินใจเรื่อง WhatsApp Coexistence ก่อน การย้ายจะคุ้มค่าก็ต่อเมื่อผู้ใช้ต้องการทั้ง Business app และ integration Cloud API อย่างเป็นทางการบนหมายเลขเดียวกันจริง ๆ

เช็กลิสต์การย้าย Coexistence

1. ตรวจ inventory ของ entry point v2 ทุกจุด

ค้นหา production และ staging button, SDK call, configuration ID, callback handler และ feature flag ทุกตัวที่เปิด Embedded Signup ได้ บันทึกว่า customer segment ใดใช้ Coexistence และส่วนใดใช้ flow Cloud API เริ่มต้น launcher ที่ใช้ร่วมกันอาจซ่อน regression ของ Coexistence ไว้จนกว่าผู้ใช้ Business app จริงจะเจอปัญหา

2. สร้าง configuration v4 ใหม่

ใน App Dashboard → Facebook Login for Business → Configurations ให้สร้าง configuration เลือก Embedded Signup เลือกผลิตภัณฑ์ที่ต้องใช้ แล้วคัดลอก configuration ID ใหม่เข้า integration Meta ระบุว่าการเลือกผลิตภัณฑ์จะกำหนด experience เป็น v4

ตรวจ assets และ permissions ที่ถูกเลือกอัตโนมัติ สำหรับ Cloud API ตาราง v4 ระบุ WhatsApp Business accounts พร้อม whatsapp_business_management และ whatsapp_business_messaging ซึ่งทั้งสองรายการต้องมี Advanced Access

3. เปิดและทดสอบเส้นทาง Coexistence อีกครั้ง

ใช้คำแนะนำ Business app onboarding ปัจจุบันของ Meta สำหรับ flow เฉพาะทาง ในการทดสอบให้ยืนยันว่าหน้าเลือกแบบ WABA-only เดิมถูกแทนด้วยตัวเลือกเชื่อมต่อ WhatsApp Business account ที่มีอยู่ หากไม่มีตัวเลือกดังกล่าว ให้หยุด rollout เพราะคุณกำลังทดสอบ onboarding intent คนละแบบ

ตรวจ prerequisites ตามเอกสารด้วย: ลูกค้าใช้ WhatsApp Business app 2.24.17 ขึ้นไป องค์กรของคุณเป็น Solution Partner หรือ Tech Provider, callback ประมวลผล webhooks ที่จำเป็นได้ และเปิด session logging แล้ว

4. ตรวจ finish callback และสถานะ onboarding

คู่มือ Coexistence ระบุ finish event เป็น FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING ให้เก็บ WABA ID, asset IDs และ exchangeable token code ที่ส่งกลับมา จากนั้นทำขั้นตอน customer onboarding ปกติให้เสร็จ โดยข้าม phone-number registration เพราะหมายเลขถูกลงทะเบียนแล้ว

อย่าสับสน version: 3 ที่ระบุไว้ใน session payload กับเวอร์ชันของ Embedded Signup configuration ให้ถือว่าสองค่านี้เป็น contract แยกกันและ assert ทั้งคู่ใน test แทนการ route ด้วย numeric field เพียงค่าเดียว

หลัง onboarding ให้ query field ของ business phone number ที่ Meta ระบุไว้สำหรับการตรวจนี้ สถานะที่คาดหวังคือ is_on_biz_app: true พร้อม platform_type: "CLOUD_API"

5. พิสูจน์ว่าเส้นทาง sync ทั้งสามทำงาน

ก่อน launch ให้ subscribe app กับ WABA webhook fields เพิ่มเติมที่ Coexistence ต้องใช้:

history สำหรับข้อความเดิมที่ลูกค้าเลือกแชร์;
smb_app_state_sync สำหรับ contacts ปัจจุบันและ contacts ที่เปลี่ยนแปลง;
smb_message_echoes สำหรับข้อความใหม่ที่ส่งจาก WhatsApp Business app

Meta ให้เวลา partner 24 ชั่วโมงหลัง onboarding เพื่อเริ่ม sync contacts และประวัติข้อความ การเริ่มแต่ละรายการทำได้เพียงครั้งเดียว หากต้องทำซ้ำ ลูกค้าต้อง offboard แล้วทำ flow ใหม่อีกครั้ง ให้เก็บ request_id ที่ส่งกลับมา รับ webhook batches ขนาดใหญ่อย่างรวดเร็ว และประมวลผลแบบ asynchronous

6. Rollout โดยมีขอบเขต rollback ที่ใช้ได้จริง

ระหว่างที่ Meta ยังอนุญาตทั้งสองเวอร์ชัน ให้รัน configuration v2 และ v4 ควบคู่กันสำหรับ cohort ที่ควบคุมไว้ ติดตาม completion rate, callback receipt, token exchange, is_on_biz_app, synchronization completion และ webhook errors แยกตาม configuration ID หาก v4 ไม่ผ่าน gate ให้ rollback ที่ entry point ไม่ใช่สถานะลูกค้าที่ทำเสร็จแล้ว

เส้นตายเดือนตุลาคมยังมีเวลาเพียงพอ จึงไม่จำเป็นต้องรอทำ cutover ครั้งใหญ่ในช่วงท้ายที่มีความเสี่ยง ให้ทำ migration ทางเทคนิคให้เสร็จก่อน จากนั้นค่อยดู แผนวัดค่าบริการ WhatsApp service message แยกต่างหาก เพื่อไม่ให้การเปลี่ยน onboarding และ pricing กลายเป็น release เดียวกัน

UnifyPort เหมาะกับส่วนไหน

UnifyPort ไม่ได้ย้าย configuration ของ Meta, มอบ permissions ของ Cloud API, sync ประวัติ Business app อย่างเป็นทางการ หรือคงสถานะ Coexistence ของ Meta หากผลิตภัณฑ์ต้องใช้ความสามารถทางการเหล่านี้ v4 คือเส้นทางที่ถูกต้อง และเจ้าของ integration จำเป็นต้องทำ migration

UnifyPort เหมาะกับความต้องการอีกแบบหนึ่ง คือเชื่อมต่อ WhatsApp account ทั่วไปและรับข้อความ inbound ที่รองรับเป็น webhook event มาตรฐาน message.received การ authorization WhatsApp รองรับการ pair ผ่าน QR code และ phone number ส่วน webhook delivery ที่มีลายเซ็นใช้ X-Device-Timestamp, X-Device-Signature และ signing_secret ของ endpoint

ทางเลือกนี้เหมาะเมื่อเป้าหมายจริงคือ inbound queue ไม่ใช่หมายเลขที่ Business app และ Cloud API ใช้ร่วมกัน เปรียบเทียบทั้งสามแนวทางใน คู่มือเส้นทาง WhatsApp inbound ก่อนใช้เวลา engineering กับ migration ที่คุณอาจไม่ต้องการฟีเจอร์ทางการของมัน

ข้อจำกัดและ trade-offs

Embedded Signup v4 เป็นคำตอบที่ถูกต้องสำหรับ Solution Partners และ Tech Providers ที่ onboarding ลูกค้าเข้าสู่ผลิตภัณฑ์ Cloud API อย่างเป็นทางการ และเป็นเส้นทางเดียวในการเปรียบเทียบนี้ที่รักษาพฤติกรรม Coexistence ที่ Meta รองรับ, history-sharing flow, asset model อย่างเป็นทางการ และ permissions ของผลิตภัณฑ์ Cloud API

อินเทอร์เฟซที่ไม่เป็นทางการไม่สามารถให้สิทธิ์เหล่านั้นได้ และไม่สามารถทำให้ธุรกิจมีสิทธิ์ใช้ผลิตภัณฑ์ Meta, แทน customer-service windows ของ Meta หรือเปลี่ยนการเชื่อมต่อ account ทั่วไปให้เป็น Cloud API WABA ได้ ประโยชน์ที่แคบกว่าคือการให้อินเทอร์เฟซ inbound มาตรฐานโดยไม่กำหนดให้ลูกค้าต้องใช้ Coexistence stack อย่างเป็นทางการ

การย้าย v4 ไม่ได้ลบข้อจำกัดการใช้งานของ Coexistence เช่นกัน ปัจจุบัน Meta ระบุ throughput คงที่ 20 messages per second สำหรับหมายเลขที่ใช้ทั้ง Business app และ Cloud API, pricing ของ Cloud API แยกสำหรับข้อความที่ส่งผ่าน API, ไม่รองรับการ sync ประวัติกลุ่ม และมีข้อจำกัดเฉพาะของ companion devices ให้ตรวจข้อกำหนดเหล่านี้กับคู่มือทางการอีกครั้งระหว่าง acceptance testing

FAQ

Meta ระบุว่า Embedded Signup v2 จะถูกยุติในวันที่ 15 ตุลาคม 2026 เจ้าของ integration ควรย้ายไป v4 ก่อนวันดังกล่าวเพื่อหลีกเลี่ยงการหยุดชะงักของ onboarding

ผู้ใช้ WhatsApp Business app ทุกคนต้องย้ายหรือไม่?

ไม่ การย้ายเป็นหน้าที่ของ partner หรือ provider ที่เป็นเจ้าของ integration Embedded Signup v2 ธุรกิจที่ใช้เฉพาะ WhatsApp Business app แบบ standalone ไม่ได้ดูแล Embedded Signup configuration

V4 ยกเลิก WhatsApp Coexistence หรือไม่?

ไม่ Meta ระบุว่า WhatsApp Business app user onboarding ยังรองรับต่อใน v4 การย้ายต้องรักษาและทดสอบตัวเลือก Coexistence เฉพาะทาง แทนการคิดว่า flow Cloud API เริ่มต้นทำงานเทียบเท่ากัน

ต้องใช้ คู่มือ v4 ของ Meta ให้ developer สร้าง configuration ใหม่ เลือก Embedded Signup เป็น login variation และเลือกผลิตภัณฑ์ที่จะรวมไว้

การทดสอบ migration ต้องพิสูจน์อะไรบ้าง?

อย่างน้อยต้องพิสูจน์ว่า: มีตัวเลือกเชื่อมต่อ Business app เดิม; finish callback และ assets ถูกส่งกลับ; token exchange สำเร็จ; is_on_biz_app เป็น true และ platform_type ตั้งเป็น CLOUD_API; รวมถึงเส้นทาง webhook history, smb_app_state_sync และ smb_message_echoes ทำงาน

ขั้นตอนถัดไป

หากคุณเป็นเจ้าของ Meta Embedded Signup integration ให้สร้าง configuration ใหม่ด้วย คู่มือ migration v4 อย่างเป็นทางการ แล้วรันเช็กลิสต์ข้างต้นใน staging หากต้องการเพียง inbound messaging สำหรับ account ทั่วไป ให้ใช้ คู่มือ authorization WhatsApp ของ UnifyPort เพื่อประเมินเส้นทางแยกนี้ก่อนสร้าง Coexistence

แหล่งข้อมูล

ตรวจสอบแหล่งข้อมูลทางการของ Meta เมื่อวันที่ 16 กรกฎาคม 2026: