Rate Limiting

Cartrack Fleet API stosuje rate limiting dla wszystkich przychodzących API requests, aby chronić zasoby sieciowe, utrzymać wydajność systemu i zapewnić spójne doświadczenie wszystkim użytkownikom.

Default Rate Limit

Domyślny limit API to 1,000 requests na minutę. Limit ten dotyczy większości endpointów API, o ile nie wskazano inaczej. Requests przekraczające ten limit otrzymają HTTP 429 Too Many Requests.

API Endpoint Specific Rate Limit

Niektóre endpointy API mają bardziej restrykcyjne limity, aby zapewnić fairness i zapobiegać nadużyciom. Poniżej limity dla tych endpointów:

Endpoint	Rate Limit	Description
POST /fuel/consumed	10 requests na minutę	Pobiera estymację fuel used dla wielu pojazdów.
POST /fuel/level	10 requests na minutę	Pobiera dane sensora fuel consumed dla wielu pojazdów.
POST /vehicles/ev-consumption	10 requests na minutę	Pobiera zużycie baterii dla wielu pojazdów elektrycznych.
POST /vehicles/range	10 requests na minutę	Pobiera eventy zgłaszanego zasięgu EV dla wielu pojazdów elektrycznych.
POST /vehicles/soc	10 requests na minutę	Pobiera eventy state of charge (SoC) dla wielu pojazdów elektrycznych.
GET /vehicles/vext	10 requests na minutę	Pobiera dane VEXT pojazdów niezależnie od statusu ignition.

Dla endpointów ze specyficznym limitem przekroczenie limitu także zwróci HTTP 429 Too Many Requests.

Zachowanie retry

Jeśli otrzymają Państwo HTTP 429 Too Many Requests, należy respektować nagłówki zwrócone w response. Nagłówki te wskazują moment kolejnego retry:

• X-RateLimit-Retry-At: Timestamp najwcześniejszej możliwej próby.
• X-RateLimit-Retry-After-Seconds: Liczba sekund do najwcześniejszej możliwej próby.

Przykładowy response

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."
    }
}

Jak obsłużyć 429 Too Many Requests

• Wait and Retry: Respektuj nagłówki X-RateLimit-Retry-At i X-RateLimit-Retry-After-Seconds, aby odczekać zalecany czas przed ponowną próbą.
• Exponential Backoff: Zaimplementuj exponential backoff z jitter, aby uniknąć powtarzalnych naruszeń limitów.

Uwagi: Powtarzające się naruszenia limitów mogą skutkować czasowym lub stałym ograniczeniem dostępu.

Zwiększenie limitu

Jeśli aplikacja wymaga wyższego limitu, można złożyć wniosek o jego podniesienie. Wnioski są oceniane case-by-case pod kątem zgodności z naszą infrastrukturą. Zatwierdzone limity będą indywidualnie ustalone i przekazane.