Documentation / Error Handling
Error Handling
All API errors follow a standard format with consistent HTTP status codes and structured error responses.
Standard Error Format
All error responses follow this consistent structure:
{
"success": false,
"error": {
"code": "ERROR_CODE",
"message": "Human-readable error message",
"details": { /* Optional additional context */ },
"field": "field_name" /* Optional field name for validation errors */
},
"timestamp": "2024-01-15T10:30:00Z"
}HTTP Status Codes
401 Unauthorized
Returned when no API key is provided or the API key is invalid.
403 Forbidden
Returned when the API key does not have sufficient permissions for the requested endpoint.
400 Validation Error
Returned when request parameters or body are invalid or missing required fields.
429 Rate Limit Exceeded
Returned when you exceed your tier's rate limits. Check your dashboard for current usage.
404 Not Found
Returned when the requested resource (device, variant, etc.) does not exist.
500 Internal Server Error
Returned when an unexpected error occurs on the server. If this persists, contact support.
503 Service Unavailable
Returned when a dependent service (e.g., IMEI provider) is temporarily unavailable.
Error Handling Best Practices
- Always check the
successfield before processing responses - Use the
error.codefield for programmatic error handling - Display
error.messageto end users for clarity - Implement exponential backoff for 429 and 503 errors
- Log error details including
timestampfor debugging - For validation errors, check the
fieldproperty to identify the problematic parameter - Monitor your rate limit usage in the dashboard to avoid 429 errors