การ review ซ้ำ LINE MINI App: จาก Approved ไป Reflected
LINE MINI App ที่ verified แล้วต้องขอ review ซ้ำเมื่อแก้ setting ที่อยู่ในขอบเขตตรวจ เช่น ชื่อ, privacy policy URL, Published Endpoint, scope, LINE Official Account ที่เชื่อม, Service Message template หรือข้อมูลบริษัท สำหรับ app ที่ publish อยู่ การผ่าน review ไม่ได้ deploy ทันที สถานะจะหยุดที่ Approved จนกด Publish changes แล้วจึงเป็น Reflected หากไม่ทำอะไร LINE จะนำ change ที่อนุมัติแล้วขึ้น production อัตโนมัติในวันที่ 31
ประเด็นสำคัญ
- การแก้ setting ที่ LINE Developers Console ใช้ตรวจต้อง review ซ้ำ ส่วนการ update code หรือ content ที่ไม่แตะ setting เหล่านี้ไม่ได้ทำให้ต้อง review โดยอัตโนมัติ แต่ยังต้องทำตาม LINE MINI App Policy
- MINI App ที่ verified มี internal channel 3 ชุด คือ Developing, Review และ Published โดยแต่ละชุดมี LIFF ID แยกกัน
- สำหรับ app ที่ publish แล้ว
Approvedคือช่วงรอ release การกด Publish changes จึงคัดลอก configuration ที่ผ่าน review ไป Published และเปลี่ยนเป็นReflected - หากไม่ publish เองภายใน 30 วัน LINE จะ reflect อัตโนมัติเวลา 9:00 น. JST ในวันที่ 31 โดยนับวันหยุดและสุดสัปดาห์ด้วย
- การเปลี่ยน Published Endpoint ชั่วคราวเพื่อ maintenance ที่มีเหตุผลถูกต้องเป็นข้อยกเว้นในเอกสาร ไม่ใช่วิธีลง change ถาวรโดยไม่ review ซ้ำ
การเปลี่ยนแปลง LINE MINI App แบบใดต้อง review ซ้ำ?
คู่มือ re-review ทางการของ LINE ระบุ setting ใน Console ที่ทำให้กลับเข้าสู่ review จุดตัดสินใจไม่ใช่ว่ามีการ deploy code หรือไม่ แต่คือ release เปลี่ยน contract ที่เคยผ่าน review ใน LINE Developers Console หรือไม่
| ขอบเขต | ตัวอย่างที่ต้อง review ซ้ำ | ผลต่อ release |
|---|---|---|
| Basic settings | icon, ชื่อ, description, email, privacy policy, terms, localization, Official Account ที่เชื่อม | รวม change ด้าน brand และกฎหมายเป็น review set เดียว |
| Web app settings | shareTargetPicker, consent simplification, Published Endpoint, scope, add-friend option | อย่าเปิด behavior ที่พึ่ง setting ก่อนสถานะ Reflected |
| ข้อมูลธุรกิจและ contact | ข้อมูล service, developer, provider และ contact ทั้งหมด | ให้ legal entity และช่องทาง support ตรงกัน |
| Service Message | ข้อมูล template ทุกส่วน | ใช้ template ที่ Published อยู่เป็น production contract จนกว่าชุดใหม่จะ reflected |
| In-app purchase | ข้อมูลใน tab สมัครใช้ | วางลำดับ review ของ in-app purchase แยกก่อน verification review |
Change ที่ไม่เกี่ยวกับ Console setting เหล่านี้ไม่ต้อง review ซ้ำเพียงเพราะ code หรือเนื้อหา app เปลี่ยน แต่ไม่ได้แปลว่ายกเว้น policy หาก content หรือ creative ที่ release ขัด LINE MINI App Policy LINE ยังขอให้แก้ได้
บทความนี้เริ่มหลัง verification ครั้งแรก สำหรับ submission แรกให้ใช้เช็กลิสต์ verification review หาก change อยู่ที่ use case, variable หรือ link ของ Service Message ให้เตรียมด้วยเช็กลิสต์ review template
Approved คือช่วงรอ release ไม่ใช่ production
คู่มือ submission ทางการแยก flow หลังอนุมัติไว้สองแบบ:
| สถานการณ์ | สิ่งที่เกิดหลัง approval | สิ่งที่ operator ต้องทำ | เส้นตายอัตโนมัติ |
|---|---|---|---|
| Verification ครั้งแรก | เปลี่ยนจาก Approved เป็น Reflected ทันที | เปิด search แยกเมื่อพร้อม | Search เปิดอัตโนมัติ 9:00 น. JST วันที่ 31 หากไม่เปิดเอง |
| Re-review ของ verified app ที่ Published แล้ว | หยุดที่ Approved; production ยังใช้ configuration ปัจจุบัน | กด Publish changes | Change reflected อัตโนมัติ 9:00 น. JST วันที่ 31 หากไม่ publish เอง |
แถวที่สองคือ release-control boundary สำคัญ Approved แปลว่า change สามารถ release ได้ ไม่ได้แปลว่าผู้ใช้เห็นแล้ว เมื่อกด Publish changes configuration ของ Review จะถูกคัดลอกไป Published และสถานะเป็น Reflected LINE ระบุว่าการเปลี่ยนอัตโนมัติวันที่ 31 อาจช้า 1-2 ชั่วโมง
เช็กลิสต์ release จาก Developing ถึง Reflected
- บันทึก setting ที่ส่ง review เก็บ version ที่แน่นอนของชื่อ, URL, scope, account ที่เชื่อม, ชุด template และข้อมูลธุรกิจ
- แยก LIFF ID ทั้งสาม Developing, Review และ Published มี ID คนละชุด ให้ init แต่ละ environment ด้วย ID ที่ตรงกันและทดสอบ Review URL ที่ reviewer จะเปิด
- ทดสอบ dependency ก่อน publish ตรวจ redirect, privacy policy, terms, permanent link, Service Message template, add-friend และ consent ด้วย configuration ที่ส่งไป
- บันทึกเวลา approval และวันที่ 31 นับวันหยุดและสุดสัปดาห์ อย่าคิดว่า auto-release เป็นสถานะพักได้ไม่จำกัด
- กำหนด owner ของ Publish changes ตั้ง go/no-go check และเก็บหลักฐานสถานะจาก
ApprovedไปReflected - ทำ acceptance หลัง release เปิด Published LIFF URL บน LINE client จริง ตรวจชื่อและ setting แล้วเช็กว่าเส้นทางรับข้อความลูกค้าเดิมยังปกติ
เมื่อเป็น Reflected channel จะกลับไป Not yet reviewed เพื่อเริ่มรอบ change ถัดไป การแก้ใหม่จะอยู่ใน Developing และไม่เปลี่ยน app บน production จนกว่าจะผ่าน review และ publish รอบใหม่
เปลี่ยน Endpoint ฉุกเฉินและ rollback
LINE ระบุว่าการเปลี่ยน Published Endpoint ชั่วคราวเพื่อ maintenance หรือเหตุผลที่ถูกต้องไม่ต้อง review ซ้ำและมีผลทันที ใช้ข้อยกเว้นนี้อย่างจำกัด: ชี้ไป maintenance page ที่ควบคุมได้ เก็บ Endpoint เดิม ทดสอบสิ่งที่ผู้ใช้เห็น และคืนบริการที่ผ่าน review หลัง incident จบ
อย่าใช้ข้อยกเว้น maintenance เพื่อ release ผลิตภัณฑ์, scope, identity หรือ template ใหม่แบบถาวร สิ่งเหล่านี้ยังอยู่ในขอบเขต review หากเปลี่ยนข้อมูล in-app purchase ด้วย ต้องจัดลำดับให้ถูก: ส่ง verification review ไม่ได้ขณะที่ใบสมัคร in-app purchase อยู่ระหว่าง review และสมัคร in-app purchase ไม่ได้ระหว่าง verification review
UnifyPort อยู่ตรงไหน?
UnifyPort ไม่ส่ง LINE MINI App เข้า review ไม่เปลี่ยน Approved หรือ Reflected ไม่ copy setting ระหว่าง internal channel และไม่ให้ฟีเจอร์ verified การใช้ identity ของ MINI App, search, Service Message, Quick-fill, shortcut และ in-app purchase ต้องใช้ flow ทางการของ LINE
UnifyPort ดูแลอีกเส้นทางหนึ่ง คือรับข้อความที่รองรับจาก LINE account ทั่วไปที่เชื่อมแล้วเป็น message.received event แบบมาตรฐาน หาก webhook endpoint มี signing_secret ให้ตรวจ X-Device-Timestamp และ X-Device-Signature ด้วย raw request body ก่อน routing
การแยกสองเส้นทางช่วยให้ release MINI App ผ่าน review ของ LINE โดยไม่เปลี่ยน contract รับข้อความ support แบบเงียบ ๆ เริ่มจากคู่มือเชื่อมต่อ LINE และตรวจขอบเขตปัจจุบันในตารางรองรับข้อความตาม provider
ข้อจำกัดและสิ่งที่ต้องแลก
Re-review ทางการจำเป็นเมื่อ change กระทบ setting ที่ตรวจหรือฟีเจอร์สำหรับ verified MINI App เท่านั้น Unofficial interface เร่ง approval หยุด auto-release วันที่ 31 rollback LINE Console change หรือเปลี่ยนข้อความจาก account ทั่วไปให้เป็น MINI App Service Message ไม่ได้
ในทางกลับกัน re-review ที่ผ่านพิสูจน์เพียงว่า LINE รับ configuration ที่ส่ง ไม่ได้พิสูจน์ว่า deployment, deep link, monitoring หรือ inbound queue ทำงาน end-to-end ให้แยก review status และ operational readiness เป็น release gate คนละชุด
FAQ
Approved ต่างจาก Reflected อย่างไร?
Approved หมายถึง LINE ยอมรับ change สำหรับ verified app ที่ publish แล้ว ผู้ใช้ยังเห็น configuration ปัจจุบันจนกด Publish changes หรือถึงเส้นตายอัตโนมัติ Reflected หมายถึง change ที่ review แล้วถูก copy ไป Published
Change ที่ Approved แล้วรอ release ได้นานเท่าไร?
ได้ 30 วัน หากไม่กด Publish changes LINE จะ reflect update เวลา 9:00 น. JST วันที่ 31 โดยนับวันหยุดและสุดสัปดาห์ และอาจช้า 1-2 ชั่วโมง
Deploy code ทุกครั้งต้อง review ซ้ำหรือไม่?
ไม่ต้อง LINE ไม่กำหนด re-review สำหรับ update ที่ไม่เกี่ยวกับ Console setting ที่ตรวจ แต่บริการที่ publish แล้วยังต้องทำตาม LINE MINI App Policy
เปลี่ยน Published Endpoint ชั่วคราวตอน maintenance ได้หรือไม่?
ได้ LINE ระบุว่าการเปลี่ยนชั่วคราวเพื่อ maintenance หรือเหตุผลที่ถูกต้องมีผลทันทีและไม่ต้อง review ควรมี restoration plan ที่ทดสอบแล้ว
แก้ Service Message template ต้อง review ซ้ำหรือไม่?
ต้อง LINE จัดข้อมูล template ทั้งหมดเป็น setting ที่ตรวจ template Reflected ปัจจุบันยังเป็น production contract จนกว่าชุดใหม่จะ approved และ publish
ขั้นตอนถัดไป
สร้าง release calendar จากคู่มือ re-review และขั้นตอน submission กับ publishing ทางการของ LINE หากอีกความต้องการคือรับข้อความลูกค้าจาก LINE account ทั่วไป ให้ใช้คู่มือเชื่อมต่อ LINE ของ UnifyPort
แหล่งข้อมูล
ตรวจสอบแหล่งข้อมูลทางการของ LINE เมื่อ 9 สิงหาคม 2026: