อย่าเดาจากข้อความสั้น ๆ ให้ตรวจตามลำดับ Authentication → JSON → Image → Resource → Rate limit
ตาราง Error ที่พบบ่อย
HTTP status บอกหมวดของปัญหา แต่สาเหตุจริงอยู่ใน response body และขั้นตอนที่กำลังเรียก เก็บ request ID และข้อความผิดพลาดโดยไม่บันทึก Token
| Status | สาเหตุที่ควรตรวจ | การแก้ถาวร |
|---|---|---|
| 400 | JSON ไม่ถูกต้อง, ไม่มีภาพ, ค่าเกินกำหนด | Validate object และตรวจลำดับงาน |
| 401 | Token หาย หมดอายุ หรือผิด Channel | ออก/หมุน Token และส่งเป็น Bearer |
| 403 | ทรัพยากรถูกจัดการจากอีก Channel/เครื่องมือ | ยืนยัน Channel และเจ้าของเมนู |
| 404 | richMenuId ไม่มีหรือไม่มีภาพ | อ่าน ID จากผล Create/List ล่าสุด |
| 413 | คำขอใหญ่เกินเพดานของ Studio/proxy | ลดภาพหรือ payload ก่อนส่ง |
| 415 | Content-Type ภาพไม่ใช่ JPEG/PNG | ส่ง MIME ให้ตรงกับไฟล์จริง |
| 429 | เรียกเกิน rate limit | ใช้ backoff, queue และลดการ retry |
ลำดับตรวจที่เร็วที่สุด
หากแต่ละขั้นผ่านแยกกันแต่ flow รวมล้มเหลว ให้ตรวจว่าระบบใช้ richMenuId เดียวกันตลอดคำขอ และไม่มีงานซ้ำสร้าง/ลบทรัพยากรพร้อมกัน
- เรียก endpoint ข้อมูลบัญชีหรือ List เพื่อพิสูจน์ Token
- ส่ง Rich Menu object เข้า Validate โดยยังไม่สร้าง
- ตรวจภาพด้วยตัวตรวจขนาด
- Create แล้วเก็บ richMenuId จาก response
- Upload ภาพไป api-data.line.me ด้วย Content-Type ที่ถูก
- Set default หลัง Upload สำเร็จเท่านั้น
สิ่งที่ไม่ควรทำเวลาแก้ปัญหา
บันทึก endpoint, status, response body ที่ตัดข้อมูลลับแล้ว, เวลา และขั้นตอนล่าสุด จะช่วยให้แก้ซ้ำได้และเขียน automated test ป้องกันการเกิดซ้ำ
- อย่าวาง Token ลงใน issue, screenshot หรือ log
- อย่า retry แบบไม่จำกัดเมื่อเจอ 429
- อย่าลบเมนูเดิมเพื่อหวังให้ 400 หาย
- อย่าเปลี่ยนหลายตัวแปรพร้อมกันจนไม่รู้ว่าสิ่งใดแก้ปัญหา
เอกสารอ้างอิง
ตรวจสอบข้อกำหนดล่าสุดจากเอกสารทางการก่อนใช้งานกับระบบสำคัญ
พร้อมนำไปทำบน Canvas แล้วหรือยัง?
วางพื้นที่ปุ่มแบบลาก ย้าย ย่อ–ขยาย แล้วตรวจ JSON ก่อนเผยแพร่
เปิด Studio →