LINE webhook โหมด standby: ทำไมจึงไม่มี replyToken

หากอีเวนต์ LINE webhook มี mode: standby การได้รับอีเวนต์ไม่ได้หมายความว่าช่องทางของคุณควรตอบกลับ เอกสาร module channel ของ LINE ระบุว่าช่องทางที่อยู่ในสถานะ standby ควรงดส่งข้อความ และอีเวนต์ที่ได้รับจะไม่มี replyToken นี่คือเงื่อนไขเรื่องผู้มีสิทธิ์ตอบแชตใน Chat Control ไม่ใช่หลักฐานว่าโทเคนหมดอายุหรือ webhook ส่งไม่สำเร็จ ควรตรวจสอบโหมดของอีเวนต์และรูปแบบการเชื่อมต่อก่อนตอบ

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

• ระบบอาจรับ webhook สำเร็จ แต่ช่องทางนั้นไม่ได้เป็นผู้รับผิดชอบการตอบ
• อย่าเปลี่ยนไปส่ง push โดยอัตโนมัติเพียงเพราะไม่มี replyToken
• Module channel เป็นความสามารถสำหรับการเชื่อมต่อระดับองค์กรโดยเฉพาะ ไม่ใช่การตั้งค่าทั่วไปสำหรับทุกบอต
• แยกการรับอีเวนต์ ผู้รับผิดชอบการตอบ และผลการส่งออกจากกัน

active และ standby ใน LINE webhook หมายถึงอะไร

คู่มือ Messaging API สำหรับ module channel ของ LINE กำหนดให้ตรวจสอบ mode ก่อนตอบ ในรูปแบบการเชื่อมต่อโมดูลที่เอกสารอธิบาย จะมีช่องทางที่เป็น active เพียงช่องทางเดียว ส่วนช่องทางอื่นเป็น standby

โหมดในอีเวนต์	ความหมายตามเอกสาร	การตัดสินใจของแอปพลิเคชัน
active	ช่องทางที่รับอีเวนต์มีสิทธิ์ควบคุมการตอบแชต และสามารถส่ง reply หรือ push	ตรวจสอบชนิดอีเวนต์และเงื่อนไขการส่งตามปกติก่อนตอบ
standby	ช่องทางกำลังรอ และอีเวนต์ไม่มี replyToken	ทำงานภายในที่ได้รับอนุญาตได้ แต่ระงับการส่งข้อความถึงลูกค้า
ไม่มีค่าหรือไม่รู้จักค่า	ยังยืนยันสัญญาข้อมูลของการเชื่อมต่อไม่ได้	ตรวจสอบข้อมูลต้นฉบับและตัวแปลงข้อมูล อย่าถือว่าเป็น active

แถวสุดท้ายเป็นนโยบายป้องกันความผิดพลาดที่แนะนำ ไม่ใช่โหมดเพิ่มเติมของ LINE เช่นเดียวกัน active ไม่ได้หมายความว่าทุกอีเวนต์จะมีโทเคนสำหรับตอบหรือต้องได้รับคำตอบ ให้ตรวจสอบนิยามของอีเวนต์ใน Messaging API reference

ประเด็นนี้ต่างจากการนำเครื่องมือทั่วไปหลายตัวมาใช้ Messaging API channel เดียวกัน เช็กลิสต์การใช้หลายเครื่องมือ อธิบายข้อมูลรับรองร่วม ผู้ดูแล webhook และโควตา ส่วนระบบโมดูลต้องตอบคำถามเพิ่มว่า ขณะนี้ช่องทางใดเป็นผู้มีสิทธิ์ตอบ

ยืนยันก่อนว่าเอกสาร Module ใช้กับระบบของคุณ

LINE ระบุว่า Module เปิดให้ลูกค้าองค์กรที่ดำเนินการสมัครตามที่กำหนด อย่าออกแบบบอตทั่วไปโดยสมมติว่ามีสิทธิ์แนบโมดูลหรือเรียกการทำงานของ Chat Control

คู่มือ Chat Control ยังเตือนว่า module channel ที่ให้บริการในปัจจุบันจะได้สิทธิ์ควบคุมแชตโดยอัตโนมัติเมื่อแนบกับบัญชี เรียกว่า Default Active และโดยปกติไม่จำเป็นต้องควบคุมสิทธิ์ด้วยตนเอง ดังนั้นการพบเอกสารนี้ไม่ได้หมายความว่าควรเพิ่มคำสั่งขอหรือคืนสิทธิ์ใน webhook handler ทุกตัว

ตรวจสอบรูปแบบการเชื่อมต่อจริงก่อน:

1. ระบุ Official Account ช่องทางรับอีเวนต์ และผู้ให้บริการที่เกี่ยวข้องกับคำขอ
2. สอบถามผู้รับผิดชอบว่ามี module channel แนบอยู่หรือไม่
3. ตรวจสอบอีเวนต์ต้นฉบับที่จัดเก็บอย่างปลอดภัย ไม่ใช่ดูเฉพาะข้อมูลในคิวที่ผ่านการแปลงแล้ว
4. เปรียบเทียบ mode และการมีอยู่ของ replyToken ก่อนและหลังการแปลง
5. ให้ผู้ให้บริการโมดูลตรวจสอบสิทธิ์ที่ผิดจากคาดการณ์ แทนการเปลี่ยนโทเคนหรือ webhook URL โดยไม่มีหลักฐาน

อย่าเก็บข้อมูลรับรองของช่องทางหรือ reply token ในบันทึกทั่วไป บันทึกเพื่อวินิจฉัยสามารถระบุเพียงว่ามีโทเคนหรือไม่ โดยไม่ต้องเก็บค่า

แยกโทเคนที่ไม่มีออกจากโทเคนที่หมดอายุ

โทเคนที่ขาดหาย โทเคนที่หมดอายุ และการไม่ได้รับผลตอบกลับหลังส่ง ต้องใช้แนวทางต่างกัน

สิ่งที่พบ	สิ่งที่ควรตรวจสอบ	สิ่งที่ไม่ควรทำ
อีเวนต์ต้นฉบับเป็น standby และไม่มีโทเคน	สิทธิ์ควบคุมแชตและผู้ตอบที่ระบบคาดหวัง	สร้างโทเคนขึ้นเองหรือส่ง push อัตโนมัติ
ต้นฉบับมีโทเคน แต่ worker ไม่มี	การแปลงข้อมูล การ serialize และการแมปข้อมูลเข้าคิว	เปลี่ยนผู้ควบคุมแชตเพื่อแก้ข้อผิดพลาดของข้อมูล
อีเวนต์ active ไม่มีโทเคน	โครงสร้างของอีเวนต์นั้นและบริบทการเชื่อมต่อ	คิดว่าทุก webhook ต้องตอบได้
มีโทเคนแต่ตอบไม่สำเร็จ	API response จริง ประวัติการใช้โทเคน และความล่าช้า	สรุปว่าทุกความล้มเหลวเกิดจาก standby
คำขอส่งข้อความหมดเวลารอ	ผลการรับคำขอยังไม่แน่นอนหรือไม่	ส่งคำตอบเดิมทันทีผ่านการทำงานอีกแบบ

หากเคยได้รับโทเคนจริงแต่ใช้ช้าเกินไปหรือใช้ซ้ำ ให้ดู คู่มือแก้ปัญหา LINE reply token ซึ่งเป็นคนละเส้นทางกับอีเวนต์ที่ตั้งใจไม่ส่งโทเคนมาให้

แยกการรับรู้อีเวนต์ออกจากสิทธิ์ตอบ

แนวทางที่แนะนำคือให้ตัวรับตรวจสอบลายเซ็นและบันทึกข้อมูลอย่างคงทนตามปกติ คู่มือรับ webhook ของ LINE อธิบายการรับและส่งซ้ำ อย่าจงใจทำให้การรับ standby ที่ถูกต้องล้มเหลว โดยหวังว่าครั้งถัดไปจะได้สิทธิ์ควบคุมแชต

หลังรับข้อมูล ให้จัดประเภทก่อนสร้างงานส่งออก:

• Standby: เก็บเฉพาะข้อมูลที่จำเป็นสำหรับงานภายในที่ได้รับอนุญาต และบันทึกว่าระงับการตอบลูกค้าแล้ว
• Active และอีเวนต์รองรับการตอบ: ให้การทำงานทางธุรกิจหนึ่งรายการพิจารณาคำตอบ พร้อมป้องกันงานซ้ำและติดตามผลการส่ง
• ยังไม่ยืนยันสัญญาข้อมูล: พักการส่งอัตโนมัติและให้ผู้รับผิดชอบตรวจสอบ อย่าแปลงเป็น active โดยปริยาย

สิ่งเหล่านี้เป็นการตัดสินใจในแอป ไม่ใช่ฟิลด์หรือสถานะ API เพิ่มเติมของ LINE เก็บ mode ที่สังเกตได้จากอีเวนต์ไว้ อย่าแก้อีเวนต์ standby เก่าให้เป็น active เพียงเพราะอีเวนต์ถัดมาเป็น active และอย่าถือว่านั่นเป็นสิทธิ์ใหม่สำหรับตอบข้อความเก่า

สำหรับงานที่รอในคิว ควรตรวจสอบให้สอดคล้องกับนโยบายผู้ตอบปัจจุบันก่อนส่ง หากผู้รับผิดชอบไม่ชัดเจน ให้พักงานเพื่อตรวจสอบ แทนการเลือกวิธีส่งอีกแบบ การกำจัดอีเวนต์ซ้ำอย่างเดียวไม่ได้ตัดสินว่าเครื่องมือใดควรตอบ

กรณีทดสอบที่แนะนำ ได้แก่ standby ต้องไม่ส่งข้อความ อีเวนต์ active ที่ตอบได้ ตัวแปลงข้อมูลทำโทเคนหาย การส่งอีเวนต์ซ้ำ และคำตอบในคิวที่ผู้ตอบกลายเป็นไม่แน่นอน นี่คือข้อเสนอสำหรับการทดสอบ ไม่ใช่ผลที่วัดจากระบบจริง

UnifyPort เหมาะกับส่วนใด และไม่ครอบคลุมอะไร

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort เป็นเส้นทางเชื่อมต่อบัญชีแยกต่างหาก เอกสารการยืนยันตัวตน LINE ระบุการเข้าสู่ระบบด้วย QR และการส่ง QR URL กับ PIN แบบอะซิงโครนัส นี่ไม่ใช่ขั้นตอนแนบโมดูล และไม่ได้รับสิทธิ์ควบคุมแชตของ Official Account

เส้นทางนี้ใช้อีเวนต์มาตรฐาน message.received ตามเอกสาร ข้อกำหนดการส่ง webhook ระบุการตรวจลายเซ็นเมื่อกำหนด signing_secret อย่านำสมมติฐานเกี่ยวกับ mode หรือ replyToken ของ LINE มาใช้กับสคีมานี้ และอย่าอธิบายการส่งผ่าน UnifyPort ว่าเป็นการกู้โทเคนที่ขาดหายของ Official Account

หากผู้ส่งต้องเป็น LINE Official Account ให้ใช้ Messaging API อย่างเป็นทางการและประสานกับผู้ให้บริการโมดูลต่อไป การเปลี่ยนไปใช้บัญชีที่เชื่อมต่ออีกบัญชีไม่ใช่ทางเลือกอัตโนมัติเมื่อพบ standby

คำถามที่พบบ่อย

standby หมายความว่า webhook ออฟไลน์หรือไม่

ไม่ใช่ อีเวนต์อาจมาถึงตามปกติ standby อธิบายสิทธิ์ควบคุมแชตของช่องทางรับ ไม่ใช่สถานะการเชื่อมต่อเซิร์ฟเวอร์

ไม่มี replyToken แล้วใช้ push แทนได้หรือไม่

ไม่ควรใช้เป็นทางแก้อัตโนมัติของ standby LINE ระบุว่าผู้รับในสถานะ standby ควรงดส่งข้อความ ปัญหาคือใครมีหน้าที่ตอบ ไม่ใช่แค่เมธอดส่ง

active รับประกันว่าจะมี replyToken หรือไม่

ไม่รับประกัน ต้องตรวจสอบว่าชนิดอีเวนต์นั้นรองรับการตอบหรือไม่ active เพียงอย่างเดียวไม่ได้ทำให้ทุกอีเวนต์ตอบได้

บอต LINE ทุกตัวต้องเรียก Chat Control หรือไม่

ไม่จำเป็น Module มีเงื่อนไขการสมัครเฉพาะ และคู่มือปัจจุบันระบุพฤติกรรม Default Active ควรยืนยันโครงสร้างจริงก่อนเพิ่มการควบคุม

ขั้นตอนถัดไปและแหล่งข้อมูล

เปรียบเทียบอีเวนต์ที่เก็บไว้อย่างปลอดภัยกับคู่มือ module channel อย่างเป็นทางการ แล้วระบุให้ชัดว่าส่วนใดรับผิดชอบการตอบ หากต้องการเชื่อมต่อบัญชีแยกต่างหาก ให้ดู ข้อกำหนดการยืนยันตัวตน LINE ของ UnifyPort

ตรวจสอบเอกสารทางการเมื่อ 2026-10-27:

• LINE: ใช้ Messaging API จาก module channel
• LINE: Chat Control
• LINE: Messaging API reference
• LINE: การรับข้อความ