การจำกัดอัตราคำขอ (Rate Limiting)

Cartrack Fleet API ใช้การจำกัดอัตราคำขอเพื่อปกป้องทรัพยากรเครือข่าย รักษาประสิทธิภาพระบบ และมอบประสบการณ์ที่เสถียรแก่ผู้ใช้ทุกคน

ค่าเริ่มต้น

อัตราคำขอเริ่มต้นคือ 1,000 requests ต่อหนึ่งนาที ใช้กับเกือบทุกเอ็นด์พอยต์ หากเกินลิมิตจะได้ HTTP 429 Too Many Requests

ลิมิตเฉพาะเอ็นด์พอยต์

บางเอ็นด์พอยต์ตั้งลิมิตเข้มงวดกว่าเพื่อความเป็นธรรมและป้องกันการใช้งานเกินควร:

Endpoint	Rate Limit	Description
POST /fuel/consumed	10 requests/minute	ดึงค่าประมาณเชื้อเพลิงที่ใช้ของหลายคัน
POST /fuel/level	10 requests/minute	ดึงข้อมูลเซนเซอร์ระดับเชื้อเพลิงหลายคัน
POST /vehicles/ev-consumption	10 requests/minute	ดึงการใช้พลังงานแบตเตอรีของรถ EV หลายคัน
POST /vehicles/range	10 requests/minute	ดึงเหตุการณ์รายงานระยะทางคงเหลือของรถ EV หลายคัน
POST /vehicles/soc	10 requests/minute	ดึงเหตุการณ์ State of Charge (SoC) ของรถ EV หลายคัน
GET /vehicles/vext	10 requests/minute	ดึงข้อมูล VEXT ไม่ขึ้นกับสถานะกุญแจ

หากเกินลิมิตเฉพาะเอ็นด์พอยต์จะได้ HTTP 429 Too Many Requests เช่นกัน

พฤติกรรมการ retry

เมื่อได้รับ 429 Too Many Requests ให้เคารพค่าเฮดเดอร์ที่ตอบกลับมา ซึ่งบอกเวลาที่ควรรอก่อนส่งใหม่:

• X-RateLimit-Retry-At: เวลาที่สามารถลองใหม่ได้เร็วที่สุด (timestamp)
• X-RateLimit-Retry-After-Seconds: จำนวนวินาทีที่ต้องรอ

ตัวอย่างการตอบกลับ

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Retry-At: 1737592000
X-RateLimit-Retry-After-Seconds: 15

{
    "error": {
        "code": 429,
        "message": "Too many requests. Please wait before retrying."
    }
}

แนวทางจัดการ 429

• รอแล้วค่อยส่งใหม่: ทำตาม X-RateLimit-Retry-At หรือ X-RateLimit-Retry-After-Seconds
• Exponential backoff: ใช้ backoff แบบเพิ่มช่วงเวลาและสุ่ม (jitter) เพื่อลดโอกาสชนลิมิตซ้ำ

หมายเหตุ: หากละเมิดลิมิตซ้ำ ๆ อาจถูกจำกัดการเข้าถึงชั่วคราวหรือถาวร

ขอเพิ่มลิมิต

หากแอปของคุณต้องการลิมิตสูงขึ้น สามารถยื่นคำขอได้ เราจะพิจารณาเป็นรายกรณีให้เหมาะสมกับโครงสร้างพื้นฐาน และแจ้งลิมิตที่อนุมัติให้ทราบ