Fleet Complete · Rate Limits

Fleetcomplete Rate Limits

Fleet Complete's Unity GraphQL API does not publish a numeric per-minute or per-day request quota. Instead it enforces a strict concurrency rule - only one active request per user at a time - and rejects a second concurrent request with HTTP 429. Access tokens are short-lived (300 seconds) and must be refreshed using a refresh token valid for up to 12 hours, which bounds how long a session can operate without re-authenticating. The legacy Integration WebAPI does not publish numeric rate limits either.

Fleetcomplete Rate Limits is the machine-readable rate-limit profile for Fleet Complete on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests, seconds, and hours.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Fleet Management, Telematics, GraphQL, and Rate Limiting.

4 Limits Throttle: 429
Fleet ManagementTelematicsGraphQLRate Limiting

Limits

Unity API Concurrency user
requests
1 active request per user
A second request issued while one is in flight returns HTTP 429.
Unity Access Token TTL session
seconds
300
Access tokens issued by POST /login/token expire after 5 minutes.
Unity Refresh Token TTL session
hours
12
Refresh tokens allow renewing an access token without re-entering credentials, for up to 12 hours.
Legacy Integration WebAPI Requests account
requests
not published
No fixed numeric request-rate limit is documented for the legacy Integration WebAPI or EcoFleet/SeeMe instance.

Policies

Single In-Flight Request
Unity API clients must wait for a response (or timeout) before issuing the next request; parallelizing calls for the same user will trigger 429s.
Token Refresh
Clients should refresh the access token proactively before the 300-second TTL expires, using the refresh token, and re-authenticate fully once the 12-hour refresh window lapses.
Backoff Strategy
Clients should implement short exponential backoff with jitter on 429 responses rather than immediate retry, given the strict one-request-at-a-time model.

Sources