Error reference

ค้นหาจากรหัสที่ได้รับ เช่น no_text_layer เพื่อดูสาเหตุและวิธีแก้ ใช้ Request ID เมื่อต้องการให้ทีมตามรอยคำขอครั้งนั้น

หมวดปัญหา

HTTP status

พบ 98 จาก 98 รหัส · แสดง 20 รหัส

รูปแบบ response

ค่าเริ่มต้นยังเป็น {error: {code, message, requestId}} โดย HTTP status บอกประเภทความผิดพลาด และ code เป็นรหัสคงที่สำหรับเขียนเงื่อนไขในโปรแกรม อย่าใช้ข้อความ message เป็นเงื่อนไข

REST API ใต้ /api/v1/ เลือกใช้ RFC 9457 ได้ด้วย Accept: application/problem+json เมื่อเกิด error จะได้ Content-Type เดียวกัน ตัวอย่าง:

{
  "type": "https://reefsight.tech/errors/no_text_layer",
  "title": "PDF has no text layer",
  "status": 422,
  "detail": "This PDF has no selectable text",
  "code": "no_text_layer",
  "requestId": "0123456789abcdef0123456789abcdef"
}

ตัวอย่างเป็นข้อมูลจำลอง หากส่งทั้งสองชนิดจะใช้ค่า q และเลือก Problem เมื่อคะแนนเท่ากัน; q=0 ไม่เลือกชนิดนั้น ส่วน Accept ที่ไม่มี Problem หรือมีเฉพาะ wildcard จะยังเป็นรูปแบบเดิม

สำเร็จแล้วได้รูปแบบเดิมของ endpoint เสมอ ข้อผิดพลาดจาก proxy หรือ router, หลังเริ่ม streaming, /api/v1/seo และ MCP JSON-RPC มีรูปแบบของตนเอง ผู้เรียกควรตรวจ Content-Type ก่อนอ่าน JSON

ตามรอย Request ID

คัดลอก requestId จาก body หรือ X-Request-ID จาก response header พร้อม code และเวลาที่เกิดปัญหาให้ทีมตรวจ log ไม่ต้องส่ง API key, cookie หรือไฟล์ต้นฉบับ

code บอกชนิดของปัญหา ส่วน Request ID อ้างถึงคำขอหนึ่งครั้ง ทีมใช้คู่กันเพื่อดู route, HTTP status และระยะเวลา ไม่ใช่เลขบรรทัดของโค้ด

อย่าส่งคำสั่งเขียนซ้ำอัตโนมัติหลัง timeout หรือ 5xx โดยไม่ตรวจผลเดิม หาก endpoint รองรับ Idempotency-Key ให้ใช้ค่าเดิมกับเนื้อหาเดิมเท่านั้น

เมนูเอกสาร

Error reference

รูปแบบ response

ตามรอย Request ID