Errors

Livepin endpoints return standard HTTP status codes and usually include structured error payloads. This page shows what to expect and how to recover safely in production.

You can classify almost all integration errors into auth issues, validation issues, missing resources, and temporary server faults.

Always log the request path, method, response status, and correlation/request ID (if available). These details dramatically reduce debugging time.

Status codes

Use status families to decide retry behavior.

Name
200 / 201 / 204
Description
Request completed successfully.
Name
400
Description
Validation or malformed request. Fix payload/query and retry.
Name
401 / 403
Description
Missing, expired, or unauthorized credentials.
Name
404
Description
Resource not found (vehicle, geofence, share link, etc).
Name
409
Description
Conflict state (duplicate operation or invalid state transition).
Name
429
Description
Rate limited. Apply backoff and retry.
Name
5xx
Description
Server-side failures. Retry with exponential backoff and alert if persistent.

Error types

Different services behind Livepin can return slightly different formats. Common patterns include a top-level error object (framework style) or a direct message and type pair.

Build your client parser to gracefully handle both.

Name
validation_error
Description
One or more fields failed validation.
Name
auth_error
Description
Token invalid, expired, or missing required permission.
Name
not_found_error
Description
Requested resource does not exist.
Name
api_error
Description
Unexpected server error while processing request.

Error response example

{
  "error": {
    "status": 400,
    "name": "ValidationError",
    "message": "vehicleId is required",
    "details": {
      "field": "vehicleId"
    }
  }
}

Retry guidance

Retry: 408, 429, 500, 502, 503, 504.
Do not retry until payload is fixed: 400, 401, 403, 404.
Use idempotency keys for critical writes when available.