สามวิธีรับข้อความขาเข้า WhatsApp: เปรียบเทียบ Cloud API, BSP และอินเทอร์เฟซที่ไม่เป็นทางการ — UnifyPort
คำถามเกี่ยวกับวิธีรับข้อความขาเข้า WhatsApp ดูเหมือนเป็นปัญหาที่แก้ไขได้แล้ว แต่มีความแตกต่างที่มีนัยสำคัญระหว่างสามแนวทางที่มีอยู่ การเลือกผิดอาจทำให้ต้องรออีกหลายสัปดาห์หรือจ่ายเงินมากขึ้น
สิ่งหนึ่งที่ควรทราบก่อน: WhatsApp On-Premises API ได้สิ้นสุดการให้บริการเมื่อวันที่ 23 ตุลาคม 2568 หากคุณกำลังอ่านเอกสารเก่าที่กล่าวถึงการรัน Docker container ของ WhatsApp บนโครงสร้างพื้นฐานของตัวเอง เส้นทางนั้นปิดแล้ว ปัจจุบันเหลือเพียง Cloud API หรือทางเลือกอื่นที่อยู่นอกระบบ API อย่างเป็นทางการเท่านั้น
วิธีที่ 1: Meta Cloud API (เชื่อมต่อโดยตรง)
เส้นทางอย่างเป็นทางการ คุณลงทะเบียนหมายเลขโทรศัพท์บน Meta Business Platform กำหนดค่า webhook และรับอีเวนต์ขาเข้าโดยตรงจากเซิร์ฟเวอร์ Meta โดยไม่ผ่านตัวกลาง
สิ่งที่ต้องเตรียม: บัญชี Facebook Business Manager, บัญชี Meta for Developers, หมายเลขโทรศัพท์ที่ไม่เคยลงทะเบียนบน WhatsApp มาก่อน และเอกสารสำหรับยืนยันธุรกิจ (เลขประจำตัวผู้เสียภาษี, หนังสือจดทะเบียนบริษัท หรือใบเสร็จค่าสาธารณูปโภค)
ระยะเวลาติดตั้ง: งานด้านเทคนิค ได้แก่ การสร้างแอป ลงทะเบียนหมายเลข และกำหนดค่า webhook ใช้เวลาไม่ถึงหนึ่งชั่วโมง จุดคอขวดคือการยืนยันธุรกิจ (Business Verification): หลังจากส่งเอกสารแล้ว โดยทั่วไปใช้เวลา 2–5 วันทำการเพื่อรับการอนุมัติจาก Meta และบางกรณีอาจนานถึงสองสัปดาห์
ก่อนยืนยันธุรกิจเสร็จสิ้น: บัญชีถูกจำกัดที่ 250 การสนทนาที่ธุรกิจเริ่มต้นในช่วง 24 ชั่วโมงแบบกลิ้ง การสนทนาที่ผู้ใช้เริ่มต้น (ที่ผู้ใช้ส่งข้อความมาก่อน) ไม่อยู่ภายใต้ข้อจำกัดนี้ หากกรณีการใช้งานของคุณเน้นการรับข้อความขาเข้าเป็นหลัก คุณสามารถเริ่มรับข้อความได้ก่อนที่การยืนยันจะเสร็จสิ้น เพียงแต่ไม่สามารถส่งข้อความเชิงรุกจำนวนมากได้
หลังยืนยันธุรกิจ: ขีดจำกัดเพิ่มขึ้นเป็น Tier 1 (1,000 การสนทนาที่ธุรกิจเริ่มต้นต่อ 24 ชั่วโมง) โดยสามารถขอระดับที่สูงขึ้นได้เมื่อคะแนนคุณภาพดีขึ้น
ค่าใช้จ่าย: การเข้าถึง API ฟรี ตั้งแต่วันที่ 1 กรกฎาคม 2568 ข้อความแม่แบบที่ส่งถึงแต่ละฉบับจะถูกเรียกเก็บเงินแยกกัน ตามประเภทข้อความ (การตลาด, ยูทิลิตี้, การยืนยันตัวตน, บริการ) และประเทศของผู้รับ ทุกเดือนมีการสนทนาบริการฟรี 1,000 ครั้ง คุณต้องสร้างและดูแลรักษาโครงสร้างพื้นฐาน webhook endpoint เอง
วิธีที่ 2: BSP (ผู้ให้บริการโซลูชันธุรกิจ)
BSP (Business Solution Provider) คือบริษัทที่ได้รับการรับรองจาก Meta ในการขายต่อการเข้าถึง WhatsApp Business API แทนที่จะติดต่อ Meta โดยตรง คุณเข้าสู่กระบวนการ onboarding ผ่านแพลตฟอร์มของ BSP ซึ่งจัดการการเชื่อมต่อ API และการส่ง webhook พร้อมมักมีอินเทอร์เฟซการจัดการให้ด้วย
BSP ที่รู้จักกันดีได้แก่ Twilio, WATI, 360dialog, SleekFlow, 1msg และ Vonage
ระยะเวลาติดตั้ง: โดยทั่วไปเร็วกว่าการเชื่อมต่อ Cloud API โดยตรง โดย BSP มีกระบวนการ onboarding แบบมีคำแนะนำ บางรายอ้างว่าสำหรับกรณีการใช้งานพื้นฐานสามารถทำได้ภายในไม่กี่ชั่วโมง อย่างไรก็ตาม ข้อกำหนดการยืนยันของ Meta ยังคงใช้สำหรับขีดจำกัดข้อความที่สูงขึ้น
ค่าใช้จ่าย:
- ค่าข้อความของ Meta (อัตราพื้นฐานเดียวกับการเข้าถึงโดยตรง)
- ส่วนเพิ่มของ BSP: โดยทั่วไป $0.003–$0.010 ต่อข้อความ หรือ 10–30% บวกเพิ่ม
- ค่าแพลตฟอร์มรายเดือน: ตั้งแต่ประมาณ $29/เดือน (แผนพื้นฐาน) ถึง $500+/เดือน (องค์กร)
- ค่าต่อหมายเลข: BSP บางรายเก็บค่าใช้จ่ายเพิ่มเติมต่อหมายเลข WhatsApp ที่เชื่อมต่อ (เช่น $15/เดือน/หมายเลข)
ที่ปริมาณน้อย ค่าแพลตฟอร์มรายเดือนจะเป็นต้นทุนหลัก ที่ปริมาณสูง ส่วนเพิ่มต่อข้อความจะกลายเป็นต้นทุนสำคัญ ไม่ว่าจะอย่างไร ค่าใช้จ่ายรวมจะสูงกว่าการเชื่อมต่อ Cloud API โดยตรง
สิ่งที่คุณได้รับ: โครงสร้างพื้นฐานที่จัดการแล้ว, อินเทอร์เฟซสำหรับกล่องจดหมายขาเข้าและการจัดการแม่แบบ, คำแนะนำด้านการปฏิบัติตามข้อกำหนด และทีมสนับสนุนที่เข้าใจนโยบายของ WhatsApp
วิธีที่ 3: อินเทอร์เฟซที่ไม่เป็นทางการ
เส้นทางที่สามไม่ใช้ระบบ API ของ Meta เลย อินเทอร์เฟซที่ไม่เป็นทางการเชื่อมต่อกับ WhatsApp ผ่าน WhatsApp Web ซึ่งเป็นกลไกเดียวกับที่เบราว์เซอร์ใช้ เพื่อรับข้อความขาเข้าเป็นอีเวนต์ webhook ที่มีโครงสร้าง
นี่คือวิธีที่ UnifyPort จัดการข้อความขาเข้า: บัญชี WhatsApp ทั่วไป (หมายเลขใดก็ได้ รวมถึงหมายเลขส่วนตัวหรือหมายเลขที่ใช้สำหรับการสนับสนุนอยู่แล้ว) เชื่อมต่อครั้งเดียว หลังจากนั้น ข้อความขาเข้าทุกฉบับจะถูกทำให้เป็นมาตรฐานเป็นอีเวนต์ message.received มาตรฐาน และส่งไปยัง webhook ของคุณพร้อมลายเซ็น HMAC-SHA256
สิ่งที่ต้องเตรียม: บัญชี WhatsApp ที่มีอยู่แล้ว และ webhook endpoint
ระยะเวลาติดตั้ง: โดยทั่วไปภายในหนึ่งวัน ไม่ต้องใช้เอกสาร ไม่ต้องรอการอนุมัติ ไม่ต้องใช้บัญชี Business Manager
ค่าใช้จ่าย: ค่าสมัครสมาชิกบริการ ไม่ใช่การเรียกเก็บเงินต่อข้อความ ไม่มีค่าใช้จ่าย Meta ในฝั่งข้อความขาเข้า
สิ่งที่คุณได้รับ: เริ่มต้นได้รวดเร็ว ใช้หมายเลขเดิมต่อเนื่อง (หมายเลขที่ลูกค้าบันทึกไว้ในรายชื่อแล้ว) และอีเวนต์ message.received ที่มีโครงสร้างเหมือนกันกับอีเวนต์จาก Telegram, LINE, TikTok, Zalo และ X — schema เดียว ครอบคลุมทุกช่องทาง
สิ่งที่คุณรับผิดชอบ: วิธีนี้ดำเนินการนอกข้อกำหนดการใช้งานของ WhatsApp WhatsApp ตรวจจับการใช้ API ที่ไม่เป็นทางการอย่างแข็งขันผ่านการวิเคราะห์พฤติกรรมและการจับคู่รูปแบบ บัญชีที่ถูกตรวจจับมีความเสี่ยงที่จะถูกระงับ นี่คือการแลกเปลี่ยนหลัก และไม่ใช่ความเสี่ยงทางทฤษฎี
เปรียบเทียบแบบ side-by-side
| Cloud API (โดยตรง) | BSP | อินเทอร์เฟซที่ไม่เป็นทางการ | |
|---|---|---|---|
| เวลาถึง webhook แรก | ไม่กี่ชั่วโมง + 2–14 วัน (ยืนยัน) | ไม่กี่ชั่วโมงถึงหลายวัน | ภายในหนึ่งวัน |
| ต้องยืนยันธุรกิจ | ใช่ | ขึ้นอยู่กับผู้ให้บริการ | ไม่ |
| ใช้หมายเลขที่มีอยู่ได้ | ไม่ (ต้องเป็นหมายเลขที่ยังไม่ได้ลงทะเบียน) | ไม่ | ได้ |
| ค่าใช้จ่าย API พื้นฐาน | ฟรี (เสียค่าข้อความ) | ฟรี + ส่วนเพิ่ม 10–30% | สมัครสมาชิก |
| ค่าแพลตฟอร์มรายเดือน | ไม่มี | $29–$500+ | สมัครสมาชิก |
| การกำหนดเส้นทางข้อมูล | Meta → โดยตรง | ผ่าน BSP | ผ่านบริการ |
| สอดคล้องกับ ToS ของ WhatsApp | ใช่ | ใช่ | ไม่ |
| การทำให้เป็นมาตรฐานหลายช่องทาง | ไม่ | ไม่ | ใช่ (6 แพลตฟอร์ม) |
วิธีใดเหมาะกับสถานการณ์ใด
Cloud API โดยตรง: เหมาะสำหรับการขยายขนาด เมื่อต้องการสถานะการปฏิบัติตามข้อกำหนดอย่างเป็นทางการ มีเวลารอการยืนยัน และต้องการต้นทุนต่อหน่วยต่ำที่สุดในระยะยาว
BSP: เหมาะสำหรับทีมที่มีความเชี่ยวชาญด้านเทคนิคน้อยและอินเทอร์เฟซการจัดการมีความสำคัญ ไม่ต้องการสร้างการจัดการแม่แบบเอง และยอมรับค่าใช้จ่ายเพิ่มเติมเพื่อความเร็วในการเริ่มต้น
อินเทอร์เฟซที่ไม่เป็นทางการ: เหมาะสำหรับเมื่อต้องรับข้อความได้ทันที หมายเลขที่มีอยู่อยู่ในรายชื่อผู้ติดต่อของลูกค้าแล้ว คิวการยืนยันจะทำให้การเปิดตัวล่าช้าหลายสัปดาห์ และประเมินและยอมรับความเสี่ยงด้าน ToS แล้ว เหมาะสำหรับเมื่อต้องการ schema อีเวนต์มาตรฐานเดียวสำหรับทุกช่องทาง
สามแนวทางไม่ได้แข่งขันกันเพื่อลูกค้ากลุ่มเดียวกัน ทีมส่วนใหญ่จะกลับมาตรวจสอบการเปรียบเทียบนี้ในที่สุดหลังจากตัดสินใจแล้ว ควรทำความเข้าใจทั้งสามแนวทางก่อนเลือก