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

วิธีย้ายจาก LINE Mark as Read API (เดิม) ก่อนสิ้นเดือนตุลาคม 2026

การย้ายจาก LINE Mark as read API (old) ทำได้โดยรับ markAsReadToken จาก message event ใน webhook ของ Messaging API แล้วส่งไปที่ POST https://api.line.me/v2/bot/chat/markAsRead endpoint ใหม่ไม่ต้องยื่นคำขอแยกและใช้ร่วมกับ Official Account Chat ได้ สิ่งที่จะสิ้นสุดในปลายเดือนตุลาคม 2026 คือการรับ คำขอใหม่ สำหรับ API เดิม ไม่ใช่การปิด integration ที่ใช้งานอยู่ในวันนั้น

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

LINE ประกาศเมื่อวันที่ 18 พฤษภาคม 2026 ว่าจะหยุดรับคำขอใหม่สำหรับฟังก์ชันองค์กรเดิมในปลายเดือนตุลาคม ส่วนบัญชีที่ได้รับอนุมัติแล้วใช้งานต่อได้
endpoint ใหม่รับ markAsReadToken แบบ opaque จาก webhook message event ไม่ใช่ค่าที่สร้างจาก user ID หรือ message.id
POST /v2/bot/chat/markAsRead จะทำเครื่องหมายข้อความที่ระบุและข้อความก่อนหน้าทั้งหมดว่าอ่านแล้ว ลำดับประมวลผลและเวลาที่ส่งการยืนยันจึงสำคัญ
endpoint ใหม่ใช้ร่วมกับ Official Account Chat ได้ แต่ API เดิมใช้ไม่ได้ การย้ายจึงเปลี่ยนทั้ง endpoint และ workflow ของฝ่ายบริการ
UnifyPort รองรับ inbound flow แยกสำหรับบัญชี LINE ทั่วไป แต่ไม่มี message-read API และไม่สร้าง markAsReadToken ทางการของ LINE

สิ่งที่เปลี่ยนในการย้าย LINE Mark as Read API

ประกาศวันที่ 18 พฤษภาคมของ LINEไม่ได้ระบุว่าจะปิดบริการในเดือนตุลาคม LINE จะหยุดรับคำขอใหม่สำหรับ Mark as read API (old) ในปลายเดือนตุลาคม 2026 อนุญาตให้บัญชีที่ได้รับอนุมัติแล้วใช้งานต่อ และกำลังพิจารณายุติฟังก์ชันเดิมในอนาคต สำหรับ implementation ใหม่ LINE แนะนำ flow ของ Messaging API ในหน้า Mark messages as read

contract สองแบบต่างกัน จึงเปลี่ยนเพียง URL ไม่ได้:

ประเด็น	Mark as read API (old)	Messaging API `markAsRead`
การเข้าถึง	ฟังก์ชันองค์กรที่ต้องยื่นขอ	ไม่ต้องยื่นคำขอแยก
Chat	ใช้ร่วมกับ Official Account Chat ไม่ได้	ต้องเปิด Chat เมื่อต้องการกำหนดอ่านแล้วด้วยตนเอง
input	contract เดิมที่อิงผู้ใช้	`markAsReadToken` จาก webhook message event
ขอบเขต	แสดงสถานะอ่านแล้วสำหรับข้อความของผู้ใช้	ทำเครื่องหมายข้อความของ token และข้อความก่อนหน้าว่าอ่านแล้ว
งานใหม่	ไม่แนะนำ	LINE แนะนำ

ถ้าปิด Chat ใน LINE Official Account Manager ข้อความจากผู้ใช้จะถูกทำเครื่องหมายว่าอ่านแล้วอัตโนมัติ การเพิ่ม API call ใน configuration นี้จึงไม่มีประโยชน์ endpoint ใหม่เหมาะกับทีมที่เปิด Chat ไว้ แต่ต้องการให้ backend ควบคุมเวลาที่สถานะอ่านแล้วปรากฏ

วิธีย้ายไป POST /v2/bot/chat/markAsRead

1. กำหนดความหมายของ “อ่านแล้ว” ในงานบริการ

เลือก business event ที่ควรแสดงสถานะต่อผู้ใช้ เช่น ข้อความเข้าสู่ queue แล้ว พนักงานเปิดอ่านจริง หรือระบบอัตโนมัติรับผิดชอบแล้ว webhook มาถึงไม่ได้แปลว่ามนุษย์อ่านแล้ว และ call เดียวอาจยืนยันหลายข้อความ จึงควรเขียนกติกาให้ชัดก่อนแก้ code

สำรวจ caller ของ API เดิม, retry job, Official Account และ environment ทั้งหมด พร้อมบันทึกว่า Chat เปิดอยู่หรือไม่ เอกสาร API เดิมระบุว่าการใช้ฟังก์ชันเดิมจะปิด automatic read และใช้พร้อม Chat ไม่ได้ ดังนั้น account setting เป็นส่วนหนึ่งของ migration state

2. เก็บ read token เป็นค่า opaque

เมื่อผู้ใช้ส่งข้อความถึง LINE Official Account, message event ของ Messaging API อาจมี message.markAsReadToken LINE ระบุว่า read token ไม่มีวันหมดอายุ แต่ reference ก็ระบุว่าฟิลด์นี้ไม่ได้มีทุกครั้ง ถ้าไม่มี token ให้บันทึกและปล่อย conversation ไว้เป็นยังไม่อ่าน ห้ามคำนวณจาก message.id

เก็บ token คู่กับ webhook event ID, message ID, ผู้รับผิดชอบ conversation, เวลารับ และสถานะประมวลผล อย่าใส่ใน analytics label หรือ client-side log แม้ไม่ใช่ channel access token แต่เป็นค่าที่ใช้สั่ง action ตาม webhook contract ของ LINE

3. เรียก Messaging API endpoint

ใช้ token ล่าสุดที่ตรงกับตำแหน่งซึ่ง workflow ประมวลผลจริงแล้ว:

curl -X POST "https://api.line.me/v2/bot/chat/markAsRead" \
  -H "Authorization: Bearer ${LINE_CHANNEL_ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"markAsReadToken":"30yhdy232..."}'

reference ทางการระบุว่า success ตอบ 200 พร้อม JSON ว่าง, read token ไม่ถูกต้องตอบ 400 และ rate limit คือ 2,000 request ต่อวินาที call ที่สำเร็จจะทำเครื่องหมายทุกข้อความก่อนหน้าและรวมข้อความที่ระบุ ไม่ใช่แค่ record เดียวใน database

4. รักษาลำดับใน conversation และขอบเขต retry

ประมวลผลการยืนยันแยกตาม conversation ถ้าข้อความ B ใหม่กว่า A การยืนยัน B จะครอบคลุม A ด้วย global worker ที่แย่ง token ของ conversation เดียวกันอาจทำให้ UI แสดงว่าอ่านแล้วก่อน internal task เสร็จ

บันทึกสถานะ “กำลังจะยืนยัน” ก่อนเรียก LINE และบันทึก response หลัง call มอง 400 เป็น contract หรือ data error ที่ต้องตรวจสอบ สำหรับ timeout หรือ server error ให้ทำตาม retry guidance ล่าสุดของ LINE และจำกัดจำนวนครั้ง log ควรตอบได้ว่าใช้ token ใดและ business event ใดเป็นตัวเริ่ม

5. ทำ acceptance test ระดับบัญชี

ใช้ Official Account ที่ไม่ใช่ production หรือ test conversation ที่ควบคุมได้ เมื่อเปิด Chat ให้ตรวจว่า:

ข้อความผู้ใช้สร้าง webhook ที่มี markAsReadToken;
สถานะยังไม่ปรากฏก่อน checkpoint ที่เลือก;
endpoint ตอบ 200 ที่ checkpoint;
ข้อความปัจจุบันและข้อความก่อนหน้าแสดงว่าอ่านแล้ว;
token ที่หายหรือผิดไม่ทำให้ข้อความใหม่กว่าถูกยืนยันโดยไม่ตั้งใจ;
Official Account Chat ยังทำงานหลัง migration

ลบ caller เดิมเมื่อทั้ง path ใหม่และงานของพนักงานใน Chat ผ่านการทดสอบแล้ว เดือนตุลาคมเป็นเส้นตายสำหรับคำขอใหม่ ไม่ใช่เหตุผลให้ผู้ใช้เดิมเปลี่ยนแบบเร่งด่วนโดยไม่ทดสอบ

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

flow ทางการของ markAsReadToken เป็นความสามารถของ LINE Official Accounts และ Messaging API ใช้ flow นี้เมื่อ client LINE ของผู้ใช้ต้องแสดงสถานะอ่านแล้วทางการ

UnifyPort แก้โจทย์อีกแบบหนึ่ง: บัญชี LINE ทั่วไปที่เชื่อมต่อแล้วสามารถส่ง conversation inbound ที่รองรับไปยัง backend เป็น message.received event แบบมาตรฐาน โดยใช้ envelope เดียวกับ WhatsApp, Telegram, TikTok, Zalo และ X หาก webhook endpoint มี signing_secret ระบบจะตรวจ HMAC-SHA256 ผ่าน X-Device-Timestamp และ X-Device-Signature

event นี้ไม่มี markAsReadToken ทางการของ LINE และเอกสารปัจจุบันของ UnifyPort ก็ระบุว่าไม่มี message-read API ควรแยก worker สำหรับสถานะ Official Account ออกจาก worker inbound ของ UnifyPort

อ่านบริบทเพิ่มเติมได้จาก วิธีรับข้อความ LINE โดยไม่ต้องมี Official Account และ เหตุผลที่ LINE analytics polling ไม่ใช่ inbound router สำหรับทีมไทยที่ใช้ LINE เป็นช่องทางหลัก การแยกสอง path นี้ให้ชัดช่วยไม่ให้สถานะบน LINE ปะปนกับ queue ข้ามช่องทาง

ข้อจำกัดและสิ่งที่ต้องแลก

ใช้ Messaging API ทางการเมื่อคุณต้องการตัวตน Official Account, Chat, read receipt ทางการ, rich menu, audience tool หรือความสามารถ native อื่นของ LINE endpoint markAsRead ใหม่คือเส้นทางทางการสำหรับสถานะอ่านแล้ว

อินเทอร์เฟซที่ไม่เป็นทางการไม่สามารถให้ฟังก์ชัน Official Account เปลี่ยนนโยบายการสมัครของ LINE หรือทำเครื่องหมาย conversation ใน Official Account ว่าอ่านแล้ว การที่ backend ได้รับข้อความก็ไม่ได้พิสูจน์ว่ามนุษย์เห็นแล้ว หากต้องการเพียง inbound queue ข้ามช่องทาง ให้ประเมินแยกต่างหาก แต่ถ้าหน้า LINE ต้องแสดง “อ่านแล้ว” ต้องคง endpoint ทางการไว้ใน architecture

FAQ

LINE Mark as read API (old) จะปิดในเดือนตุลาคม 2026 หรือไม่

ยังไม่มีประกาศเช่นนั้น LINE จะหยุดรับคำขอใหม่ปลายเดือนตุลาคม ส่วนบัญชีที่ได้รับอนุมัติแล้วใช้งานต่อได้ LINE กำลังพิจารณายุติในอนาคตและแนะนำให้ migration

endpoint LINE markAsRead ใหม่ต้องยื่นขอหรือไม่

ไม่ต้อง POST /v2/bot/chat/markAsRead ใช้ channel access token และ markAsReadToken จาก webhook message event ของ Messaging API

markAsRead ใช้กับ LINE Official Account Chat ได้หรือไม่

ได้ ต้องเปิด Chat เพื่อกำหนดสถานะด้วย Messaging API หากปิด Chat ข้อความ inbound ของผู้ใช้จะถูกทำเครื่องหมายว่าอ่านแล้วอัตโนมัติ

markAsReadToken หมดอายุหรือไม่

LINE ระบุในปัจจุบันว่า read token ไม่มีวันหมดอายุ แต่ควรเก็บตามนโยบาย operation และ retention เท่าที่จำเป็น และใช้ token ที่ตรงกับ checkpoint ที่ต้องยืนยัน

UnifyPort ทำเครื่องหมายข้อความ LINE Official Account ว่าอ่านแล้วได้หรือไม่

ไม่ได้ UnifyPort ส่งข้อความ inbound ที่รองรับจากบัญชี LINE ที่เชื่อมต่อได้ แต่ไม่มี message-read API และไม่ให้ markAsReadToken ทางการของ Messaging API

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

จับคู่ caller เดิมกับ คู่มือ Mark messages as read ทางการ และทำ acceptance test หกข้อใน Official Account ที่ควบคุมได้ หากมีอีกโจทย์คือ inbound routing สำหรับบัญชีทั่วไป ให้ดู คู่มือการยืนยันตัวตน LINE ของ UnifyPort ก่อนออกแบบ path ที่สอง

แหล่งข้อมูล

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