Zalo Official Account API เทียบกับ Webhook บัญชีส่วนบุคคล: รับข้อความแบบไหนดี?
หากต้องการตัวตนธุรกิจอย่างเป็นทางการและฟีเจอร์ของ Zalo Official Account (OA) ควรพิจารณา Zalo Official Account API ก่อน แต่ถ้าลูกค้าส่งข้อความมาที่บัญชี Zalo ทั่วไปอยู่แล้ว และเป้าหมายคือส่งข้อความเหล่านั้นเข้าเครื่องมือซัพพอร์ต CRM หรือเวิร์กโฟลว์ AI การใช้ Webhook ที่มีลายเซ็นเชื่อมกับบัญชีเดิมอาจตรงกว่า ประเด็นหลักคือ ลูกค้ากำลังติดต่อบัญชีประเภทใด ไม่ใช่วิธีใดมีรายการฟีเจอร์ยาวกว่า
สรุปสำคัญ
- Zalo อธิบาย Official Account ว่าเป็นบัญชีอย่างเป็นทางการของธุรกิจ และมีขั้นตอนสร้าง ยืนยัน ตั้งค่า และดำเนินงาน OA
- อินเทอร์เฟซสำหรับนักพัฒนาอย่างเป็นทางการระบุชัดว่าเป็น Official Account API
- UnifyPort เชื่อมบัญชี Zalo ทั่วไปด้วย QR code และส่งเหตุการณ์ขาเข้าผ่าน Webhook รูปแบบเดียวกัน
- เลือก API ทางการเมื่อจำเป็นต้องใช้ความสามารถเฉพาะของ OA การสนับสนุนอย่างเป็นทางการ และการกำกับดูแล เลือกอินเทอร์เฟซที่ไม่เป็นทางการเมื่อต้องคงกล่องข้อความของบัญชีทั่วไปเดิม
- ไม่ว่าจะส่งต่อไป Slack, CRM หรือ AI ควรตรวจลายเซ็นและบันทึกเหตุการณ์ก่อนเสมอ
ความต่างระหว่าง Zalo OA API กับ Webhook บัญชีส่วนบุคคล
เว็บไซต์ Zalo Official Account ระบุว่า OA เป็นบัญชีอย่างเป็นทางการของธุรกิจบน Zalo และนำเสนอการสร้างกับการยืนยัน OA เป็นส่วนหนึ่งของเส้นทางเริ่มต้น ส่วนเอกสารนักพัฒนาเรียกพื้นผิวการเชื่อมต่อนี้ว่า Official Account API
Webhook บัญชีส่วนบุคคลเริ่มจากอีกจุดหนึ่ง คืออนุญาตบัญชี Zalo ทั่วไปที่ใช้งานอยู่ แล้วเปลี่ยนข้อความที่บัญชีนั้นได้รับให้เป็นเหตุการณ์มาตรฐานสำหรับแอปพลิเคชัน การอนุญาต Zalo ของ UnifyPort รองรับ QR code เท่านั้น ไม่ต้องเตรียมข้อมูลรับรองนักพัฒนา Zalo ก่อนสแกน และจะทราบตัวตนบัญชีจากการสแกน
| ปัจจัยตัดสินใจ | Zalo Official Account API | Webhook บัญชีส่วนบุคคลผ่าน UnifyPort |
|---|---|---|
| ตัวตนที่ลูกค้าเห็น | Zalo Official Account | บัญชี Zalo ทั่วไปที่มีอยู่ |
| การตั้งค่าเริ่มต้น | สร้างและตั้งค่าเส้นทางนักพัฒนา OA | สร้าง messaging account สำหรับ Zalo แล้วสแกน QR code |
| การส่งข้อความขาเข้า | โมเดล API และ Webhook ของ OA | เหตุการณ์ message.received แบบมาตรฐาน |
| การทำงานหลายช่องทาง | พัฒนาตามโมเดลของ Zalo | ใช้โครงสร้างเดียวกับ Zalo, LINE, WhatsApp, Telegram, TikTok และ X |
| เหมาะกับ | งานที่ใช้ฟีเจอร์ OA และต้องการการสนับสนุนทางการ | คิวขาเข้าที่เริ่มจากบัญชีทั่วไป |
| สิ่งที่ต้องแลก | ข้อกำหนดด้านตัวตนและการตั้งค่า OA | ต้องดูแลความต่อเนื่องของเซสชันและความเสี่ยงของอินเทอร์เฟซที่ไม่เป็นทางการ |
ไม่มีเส้นทางใดดีที่สุดสำหรับทุกทีม เพราะทั้งสองทางแก้คนละงาน
เมื่อใดควรเลือกเส้นทาง OA ทางการ
หาก Zalo Official Account เป็นส่วนหนึ่งของข้อกำหนดผลิตภัณฑ์ เส้นทางทางการเหมาะกว่า ตัวอย่างเช่น ธุรกิจต้องการให้ลูกค้าพบและติดต่อแบรนด์ผ่าน OA กระบวนการปฏิบัติงานพึ่ง OA Manager หรือฝ่ายจัดซื้อและกฎหมายต้องการความสัมพันธ์กับแพลตฟอร์มและช่องทางสนับสนุนอย่างเป็นทางการ
ลองเขียนข้อกำหนดเป็นประโยคเดียวว่า “ลูกค้าจะติดต่อ Zalo Official Account ของเรา และกระบวนการต้องใช้ความสามารถของ OA” หากประโยคนี้ถูกต้อง ให้ประเมิน API ทางการก่อน อินเทอร์เฟซที่ไม่เป็นทางการไม่ใช่ตัวแทนของการยืนยัน Zalo หรือผลิตภัณฑ์เฉพาะ OA ทุกชนิด
เมื่อใด Webhook บัญชีส่วนบุคคลเหมาะกว่า
อีกกรณีหนึ่งคือ “ลูกค้าส่งข้อความมาที่บัญชี Zalo ทั่วไปนี้อยู่แล้ว และทีมต้องส่งข้อความเข้า Slack, CRM หรือคิวซัพพอร์ตรวม” การเปลี่ยนตัวตนที่ลูกค้าคุ้นเคยเพียงเพื่อเชื่อมระบบหลังบ้านอาจเพิ่มขอบเขตงานโดยไม่จำเป็น
ขั้นตอนในคู่มือการอนุญาต Zalo ของ UnifyPortมีดังนี้
- ลงทะเบียน Webhook endpoint ก่อน เพื่อให้เหตุการณ์การอนุญาตและข้อความขาเข้ามีปลายทาง
- สร้าง Zalo messaging account ด้วย
provider: zaloและauth_mode: qrcode - เริ่มการอนุญาต QR และสแกนด้วยบัญชี Zalo ที่ต้องการเชื่อม
- หลังอนุญาตสำเร็จ ให้ประมวลผลเหตุการณ์
message.receivedที่มีdata.message.directionเป็นinbound - ตรวจสอบด้วย
signing_secretตามสัญญา HMAC-SHA256 ก่อนแยกข้อมูลและส่งต่อ
สำหรับทีมไทยที่มี LINE เป็นช่องทางหลัก ประโยชน์ของเลเยอร์นี้คือเพิ่ม Zalo โดยไม่ต้องเปลี่ยนตัวรับเดิม อ่านตัวอย่างได้จากหนึ่ง Webhook สำหรับ LINE, Zalo และ X ส่วนแนวทางลงมือทำดูได้จากบทเรียนให้ Claude Code สร้างตัวรับ Zalo Webhook
ออกแบบเลเยอร์ขาเข้าก่อนเลือกเครื่องมือปลายทาง
สิ่งที่ควรทำให้เสถียรไม่ใช่คำถามว่า “Slack หรือ CRM” แต่คือสัญญาเหตุการณ์ระหว่าง Zalo กับเครื่องมือเหล่านั้น ตัวรับควรตอบรับคำขอที่ถูกต้องอย่างรวดเร็ว บันทึกเหตุการณ์ แล้วค่อยแจกงานแบบอะซิงโครนัส
ซองเหตุการณ์ของ UnifyPort มี id, type, provider, account_id, occurred_at และ data ตามชนิดเหตุการณ์ สำหรับข้อความขาเข้า data มี conversation, sender และ message ใช้ event ID เพื่อทำงานซ้ำอย่างปลอดภัยเมื่อเกิดการส่งใหม่ แต่ต้องเก็บข้อมูลเอง เพราะไม่มี REST API สำหรับอ่านประวัติข้อความและไม่รับประกันว่าจะส่งข้อมูลที่พลาดกลับมาได้
X-Device-Signature คือค่า HMAC-SHA256 แบบเลขฐานสิบหกที่คำนวณจาก timestamp จุดหนึ่งตัว และ request body ดิบ ต้องตรวจไบต์ดิบก่อนแปลง JSON รายละเอียดการตอบรับ การลองส่งใหม่ และลำดับเหตุการณ์อยู่ในเอกสารการส่ง Webhook
ข้อจำกัดและสิ่งที่ต้องแลก
การเชื่อมบัญชีทั่วไปขึ้นกับความต่อเนื่องของเซสชันที่อนุญาตไว้ คู่มือปฏิบัติงานควรตรวจสถานะการอนุญาตและ runtime จัดการ account.auth.required และให้เจ้าของบัญชีสแกน QR ใหม่เมื่อจำเป็น ความพร้อมใช้งานจากแพลตฟอร์มต้นทางอาจต่างกันตามบัญชีหรือภูมิภาค
เส้นทาง OA ทางการใช้ตัวตนธุรกิจและโมเดลนักพัฒนาแยกต่างหาก ซึ่งอาจตรงกับสิ่งที่แบรนด์ต้องการ แต่ไม่จำเป็นต้องเป็นทางที่สั้นที่สุดสำหรับทีมที่ให้บริการลูกค้าผ่านบัญชีทั่วไปอยู่แล้ว
ให้เลือกตัวตนที่ลูกค้าเห็นก่อน ระบุเฉพาะฟีเจอร์แพลตฟอร์มที่จำเป็นจริง แล้วจึงเลือกวิธีเชื่อมต่อ
คำถามที่พบบ่อย
Zalo Official Account API ใช้กับบัญชีส่วนบุคคลได้หรือไม่
อินเทอร์เฟซนักพัฒนาอย่างเป็นทางการมีชื่อว่า Official Account API และมี Zalo Official Account เป็นแกนหลัก บัญชีทั่วไปต้องใช้โมเดลการเชื่อมต่ออีกแบบ
บัญชี Zalo ทั่วไปรับข้อความผ่าน Webhook ได้หรือไม่
ได้ผ่านอินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort หลังอนุญาตด้วย QR code ข้อความขาเข้าจะถูกส่งเป็นเหตุการณ์ message.received
ขั้นตอน QR ของ UnifyPort ต้องใช้ข้อมูลรับรองนักพัฒนา Zalo หรือไม่
ตามเอกสาร ไม่ต้องมีข้อมูลรับรองล่วงหน้า ระบบจะทราบตัวตนเมื่อบัญชีเป้าหมายสแกน QR code
แบบใดเหมาะกับคิวซัพพอร์ตหลายช่องทาง
หากตัวรับเดียวต้องจัดการ Zalo ร่วมกับ LINE, WhatsApp, Telegram, TikTok หรือ X การใช้ Webhook มาตรฐานเดียวกันมักดูแลง่ายกว่า หากตัวตน OA และฟีเจอร์เฉพาะ OA เป็นข้อกำหนด ให้เลือก API ทางการ
อินเทอร์เฟซที่ไม่เป็นทางการเหมาะกับทุกทีมหรือไม่
ไม่เหมาะ หากการยืนยัน การสนับสนุนทางการ การกำกับดูแล หรือความสามารถเฉพาะ OA สำคัญกว่า ให้ใช้เส้นทางทางการ
ขั้นตอนถัดไป
เริ่มจากคู่มือการอนุญาต Zalo จากนั้นตรวจการจัดการลายเซ็นตามเอกสาร Webhook ก่อนเชื่อม Slack, CRM หรือเวิร์กโฟลว์ AI
แหล่งข้อมูลทางการ
ตรวจสอบเมื่อ 2026-08-23
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน