Errors & limits
Handle the response you receive, including legacy error formats and resource access rules.
Error formats vary
The API has several existing response conventions. Sign-in errors use an error value. Dingo exceptions can include message, errors, code and status_code. Validation can return a map from field names to arrays of messages.
{
"fullname": ["The fullname field is required."]
}The example above is synthetic and illustrates the field-validation shape. Do not require every error to use a single envelope. Inspect the HTTP status first, then handle the documented response for that operation.
| Status | Meaning in relevant operations |
|---|---|
| 400 | Invalid date input or upload input |
| 401 | Missing/invalid credentials or failed password verification |
| 403 | Resource policy or current-password rejection |
| 404 | Resource does not exist or is not found in the relevant scope |
| 416 | Historical range exceeds that operation’s limit |
| 422 | Request field validation failed |
| 429 | A request limit was exceeded |
| 500 | Server-side error |
Rate limits
Limits vary by account and route; there is no single quota listed for all operations. Handle 429 responses, respect any retry headers returned by the API, and use bounded retries with backoff. Do not automatically retry an operation that changes data after an uncertain outcome.
Account and resource access
A bearer token does not bypass fleet/device policies. Your account must have access to the requested resource; write operations can require stronger permissions than reads. An absent vehicle or empty list may reflect the account’s accessible scope.