LINE replyToken หมดอายุ? จัดการคำตอบที่ล่าช้าโดยไม่ส่งซ้ำ
replyToken ของ LINE Messaging API ใช้ได้ครั้งเดียวและต้องใช้ภายในหนึ่งนาทีหลังรับ webhook หากเกินช่วงนี้ LINE ไม่รับประกันว่าจะใช้ได้ เมื่อ AI สร้างคำตอบช้าหรืองานค้างในคิว อย่าส่ง token เดิมซ้ำไปเรื่อย ๆ หรือเปลี่ยนเป็น push อัตโนมัติทันทีที่คำขอหมดเวลา ก่อนอื่นต้องแยกว่า “ยังไม่ได้ใช้ token” หรือ “ส่งคำตอบไปแล้วแต่ไม่ทราบผล” แล้วจึงตัดสินใจส่งครั้งต่อไป
ประเด็นสำคัญ
- Reply token คือโอกาสตอบกลับระยะสั้น ไม่ใช่ ID ผู้รับหรือข้อมูลรับรองที่ใช้ซ้ำได้
- การส่ง webhook ซ้ำไม่ได้สร้างสิทธิ์ตอบกลับครั้งที่สองที่แยกจากครั้งแรก
- Timeout หมายถึงไม่ทราบผล ไม่ใช่หลักฐานว่ายังไม่ได้ส่งข้อความ
- Push เป็นคนละการดำเนินการ มีเงื่อนไขผู้รับและการนับข้อความของตัวเอง ไม่ใช่การต่ออายุ token
ข้อกำหนดจริงของ LINE reply token
Messaging API reference ระบุ POST /v2/bot/message/reply ซึ่งใช้ replyToken จาก event และอาร์เรย์ messages Token ใช้ได้ครั้งเดียวและควรใช้โดยเร็ว LINE ยังระบุว่าข้อจำกัดเวลาอาจเปลี่ยนได้ จึงไม่ควรออกแบบให้ worker รอจนวินาทีสุดท้าย
ข้อความสั้น ๆ เช่น “กำลังตรวจสอบให้ค่ะ” ก็ใช้ token ไปแล้ว คำตอบฉบับสมบูรณ์ที่เสร็จภายหลังจึงใช้ token เดิมไม่ได้ คู่มือส่งข้อความ อนุญาตให้ใส่ message object ได้สูงสุดห้ารายการในคำขอ reply ครั้งเดียว ไม่ได้หมายความว่าจะเรียก API แยกห้าครั้งด้วย token เดิมได้
| ค่า | หน้าที่ | ใช้แทนสิ่งใดไม่ได้ |
|---|---|---|
| Channel access token | ยืนยันคำขอ API ของ channel | Reply token ใหม่ |
replyToken | ตอบกลับการกระทำที่ทำให้เกิด event | ที่อยู่ถาวรของผู้ใช้ |
| ตัวระบุผู้รับ | ระบุปลายทาง push ที่เข้าเงื่อนไข | สิทธิ์ใช้การ reply ซ้ำ |
หากกำลังทำแจ้งเตือน LINE MINI App ให้อ่านการเปรียบเทียบ service messages กับ Messaging API ก่อน Service notification token อยู่ภายใต้ API คนละชุด
หาสาเหตุก่อนเลือกวิธีส่งทดแทน
ตารางนี้เป็นแนวทางตรวจสอบของแอปพลิเคชัน ไม่ใช่รหัสข้อผิดพลาดใหม่ของ LINE
| หลักฐาน | จุดที่ควรตรวจ | ขั้นตอนถัดไปที่ปลอดภัย |
|---|---|---|
| Worker เริ่มทำงานนานหลังรับ webhook | คิวค้างหรือสร้างคำตอบช้า | อย่าพึ่ง token เก่า ให้ประเมินการส่งภายหลังแยกต่างหาก |
| Worker อื่นได้รับผล reply สำเร็จแล้ว | Token แบบใช้ครั้งเดียวถูกใช้แล้ว | หยุดงานซ้ำ |
| HTTP timeout หลังส่งคำขอ | ไม่ทราบว่า LINE รับคำขอหรือไม่ | เก็บสถานะไม่ทราบผล อย่า push คำตอบเดิมทันที |
| Webhook เดิมมาถึงอีกครั้ง | รับ event ซ้ำ | ตรวจสถานะงานและการส่งของ event เดิม |
| Event ที่เพิ่งรับมาก็ตอบไม่ได้ | เนื้อหาคำขอ ข้อมูลรับรอง channel การเลือก token หรือข้อผิดพลาด API อื่น | ตรวจ response จริง อย่าสรุปว่าทุกปัญหาคือ token หมดอายุ |
บันทึกเวลารับ webhook เวลาเริ่ม worker เวลาส่งคำขอ HTTP status และการส่งก่อนหน้าที่สำเร็จ ห้ามใส่ token หรือ authorization header ใน log ทั่วไป เก็บ token ในพื้นที่ที่ป้องกันไว้เฉพาะช่วงที่จำเป็นต่อการดำเนินการระยะสั้น
ข้อผิดพลาดครั้งเดียวบอกไม่ได้ว่า worker อีกตัวตอบไปแล้วหรือยัง การออก channel access token ใหม่ก็ไม่ทำให้ reply token ที่ใช้แล้วกลับมาใช้ได้
Webhook redelivery ไม่ใช่บริการรีเฟรช token
คู่มือรับข้อความของ LINE ระบุว่า webhook ที่ส่งซ้ำยังมี event ID และ reply token เดิม โดยเปลี่ยนค่า deliveryContext.isRedelivery แอปควรใช้ตัวระบุ channel ร่วมกับ webhookEventId เป็นคีย์ตรวจงานซ้ำ
เอกสารอ้างอิงอนุญาตให้ใช้ token ภายในหนึ่งนาทีหลังรับ webhook ที่ส่งซ้ำ แต่มีข้อยกเว้น: ใช้ไม่ได้หาก token ถูกใช้ไปแล้ว หรือผ่านไปยี่สิบนาทีนับจากเวลาเกิด event นี่เป็นเงื่อนไขช่วยกู้คืนที่จำกัด ไม่ใช่ช่วงเวลาสำหรับตั้งเวลาตอบ และไม่ใช่เหตุผลให้จงใจปฏิเสธ webhook
บันทึก event แบบถาวร แล้วตอบรับการนำเข้าแยกจากงานที่ใช้เวลานาน Webhook ซ้ำต้องค้นงานเดิม ไม่ใช่เริ่ม AI และส่งคำตอบใหม่อีกครั้ง ต้องบันทึกสถานะการส่งด้วย เพราะการกัน event ซ้ำเพียงอย่างเดียวไม่ป้องกันงานส่งที่รันใหม่หลัง worker ล่ม
เลือกเส้นทางตอบก่อนเริ่มงานช้า
ถ้าตอบได้เร็ว ให้ worker เดียวเป็นเจ้าของ event และ reply โดยเร็ว หากงานอาจเกินเวลาที่ token ใช้ได้ ให้เลือกตั้งแต่ต้นว่าจะส่งข้อความรับเรื่องก่อนแล้วค่อยส่งผล หรือรอส่งเฉพาะผลสุดท้าย
แนวทางออกแบบแอปที่แนะนำ:
- รับสิทธิ์ทำงานกับ event เพียงครั้งเดียว ผูก channel และ
webhookEventIdกับการดำเนินการทางธุรกิจหนึ่งรายการ ใช้ข้อกำหนดข้อมูลไม่ซ้ำหรือ transaction เพื่อไม่ให้ worker สองตัวต่างคนต่างส่ง - บันทึกการตัดสินใจส่ง แยก reply ทันทีออกจาก push ภายหลัง ข้อความรับเรื่องคือ reply ที่เสร็จแล้ว ไม่ใช่การจอง token
- เก็บผลตามจริง แยกสถานะภายในเป็นยังไม่ลอง รับคำขอแล้ว ถูกปฏิเสธ และไม่ทราบผล ชื่อเหล่านี้เป็นสถานะของแอป ไม่ใช่ฟิลด์ response ของ LINE หากโปรเซสล่มหลังส่ง ผลอาจยังไม่ทราบ
- ตรวจเงื่อนไขก่อนส่งคำตอบที่ล่าช้า ตรวจว่าคำตอบยังเกี่ยวข้องหรือไม่ มีเจ้าหน้าที่ตอบไปแล้วหรือยัง และผู้รับเข้าเงื่อนไข push ปัจจุบันของ LINE หรือไม่ หากการส่งก่อนหน้าไม่ทราบผล ต้องตัดสินใจอย่างชัดเจนก่อนดำเนินการต่อ
- บันทึก push เป็นการดำเนินการใหม่ ใช้คำขอและมาตรการป้องกันแยกกัน Push ไม่ได้เปลี่ยนผลของ reply ก่อนหน้า
เอกสารค่าบริการของ LINE แยกการนับข้อความ: reply ไม่ถูกนับรวมในจำนวนข้อความของแพ็กเกจ ส่วน push ถูกนับ ตรวจแพ็กเกจที่ใช้อยู่ อย่าคิดว่าการส่งทดแทนมีการนับเหมือนเดิม
สำหรับการลองส่ง push ซ้ำที่รองรับ ให้อ่านคู่มือ X-Line-Retry-Key เอกสาร retry ทางการ ระบุ push, multicast, narrowcast และ broadcast แต่ไม่รวม reply การเพิ่ม header นี้ให้คำขอ reply ไม่ต่ออายุ token และไม่กัน push ภายหลังซ้ำกับ reply ก่อนหน้า
แยกจากสัญญา API ของ UnifyPort
Unofficial interface ของ UnifyPort เชื่อมต่อบัญชีรับส่งข้อความเป็นอีกเส้นทางหนึ่ง ไม่ได้ซ่อม reply token ของ LINE Official Account เอกสารส่งข้อความข้อความล้วน ใช้ POST /v1/messages พร้อม account_id, to และ message ตารางความสามารถแต่ละแพลตฟอร์ม ระบุการส่งข้อความของ LINE แต่การตอบแบบอ้างอิงด้วย token ปัจจุบันรองรับเฉพาะ WhatsApp
อย่านำ replyToken ของ LINE ไปใส่ใน reply_to.reply_token ของ UnifyPort ชื่อคล้ายกันไม่ได้แปลว่าใช้แทนกันได้ สำหรับคำตอบปกติจาก event มาตรฐานที่บันทึกไว้ ให้ใช้บัญชีและตัวระบุบทสนทนาตามเอกสาร และตรวจผลการส่งจริง ไม่มีการรับประกันการกันส่งซ้ำข้าม API หรือการกู้ token
ถ้าผู้ส่งต้องเป็น LINE Official Account ให้ใช้ Messaging API ทางการต่อไป การเปลี่ยนตัวตนของบัญชีที่เชื่อมต่อไม่ใช่ทางเลือกอัตโนมัติที่ปลอดภัยเมื่อผลการส่งเดิมยังไม่ทราบ
คำถามที่พบบ่อย
รีเฟรช LINE reply token ที่หมดอายุได้ไหม?
อย่าจัดการเหมือน access token ที่รีเฟรชได้ Event ใหม่ที่เข้าเงื่อนไขมีโอกาสตอบของตัวเอง ส่วน redelivery มีข้อจำกัดข้างต้น ทั้งสองแบบไม่อนุญาตให้ลองส่งคำตอบทางธุรกิจเดิมได้ไม่จำกัด
ส่งข้อความรับเรื่องก่อน แล้วใช้ token เดิมส่งคำตอบสุดท้ายได้ไหม?
ไม่ได้ Reply แรกที่ได้รับการยอมรับจะใช้ token ไปแล้ว ต้องวางแผนคำตอบภายหลังแยกต่างหาก และตรวจเงื่อนไขผู้รับ push กับการนับข้อความ
ทุกครั้งที่ reply timeout ควรเปลี่ยนเป็น push หรือไม่?
ไม่ควร Reply อาจได้รับการยอมรับแล้ว การ push อัตโนมัติอาจส่งซ้ำ เก็บสถานะไม่ทราบผลและกำหนดนโยบายส่งทดแทนอย่างชัดเจน
ขั้นตอนถัดไปและแหล่งอ้างอิง
ตรวจขั้นตอนตอบช้าหนึ่งรายการเทียบกับ LINE Messaging API reference ใช้ mock ภายในเพื่อทดสอบ webhook ซ้ำ worker สองตัวแย่งงาน ข้อความรับเรื่องตามด้วยผลที่ล่าช้า และ HTTP response สูญหาย ทั้งหมดเป็นการทดสอบที่เสนอ ไม่ใช่ผลจากระบบใช้งานจริง หากเลือกเส้นทางบัญชีที่เชื่อมต่อแยกต่างหาก ให้เริ่มจากสัญญาการส่งข้อความของ UnifyPort
ตรวจเอกสารทางการเมื่อ 2026-10-04:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน