Overview
The Scanova API uses standard HTTP status codes to indicate the success or failure of API requests. This page documents all response codes organized by category, along with their meanings and example responses.All responses are returned in JSON format (except
204 No Content). Error responses follow a consistent structure with field-level validation details wherever applicable.Success Responses
Success responses indicate that the request was processed successfully.- 200 OK
- 201 Created
- 204 No Content
The request was successful. This status code is used for:
- Retrieving resources (GET requests)
- Updating resources (PUT/PATCH requests)
Example Response
Common Use Cases
- GET
/qr/{qrid}/- Retrieve QR code details - GET
/qr/- List QR codes - PUT/PATCH
/qr/{qrid}/- Update QR code - GET
/lead/- List lead lists - GET
/analytics/qr/- Get analytics data
Client Errors
Client errors occur when the request is invalid, missing data, or lacks correct authentication.- 400 Bad Request
- 403 Forbidden
- 429 Too Many Requests
The request was malformed or contains invalid data. This typically occurs due to:
- Missing required fields
- Invalid field values or formats
- Validation errors
Response Format
The response follows Django REST Framework (DRF) validation error format:Example Response
Common Causes
- Missing required fields (
category,info,name,qr_type) - Invalid JSON in
infoorpattern_infofields - Invalid category ID
- Invalid data structure for the selected category
- Invalid pattern_info format
How to Handle
- Check the response body for field-specific errors
- Validate your request payload against the API documentation
- Ensure all required fields are present
- Verify JSON formatting for
infoandpattern_infofields
Server Errors
Server errors indicate an issue on Scanova’s end.- 500 Internal Server Error
An unexpected error occurred on the server. This is a generic server error that indicates something went wrong on our end.
Example Response
Common Causes
- Temporary server issues
- Database connectivity problems
- Unexpected server errors
How to Handle
- Retry the request after a short delay
- Implement exponential backoff retry logic
- If the error persists, contact support with:
- The request details
- Timestamp of the error
- Response body (if available)
Retry Logic Example
Error Response Best Practices
Always Check Status Codes
Always check the HTTP status code before processing the response body:Handle Field-Specific Errors
For 400 errors, parse field-specific validation errors:Implement Retry Logic
Implement retry logic for transient errors (429, 500):Summary Table
| Status Code | Category | Meaning | Common Use Cases |
|---|---|---|---|
| 200 | Success | Request successful | GET, PUT, PATCH operations |
| 201 | Success | Resource created | POST operations (QR code, lead list, user creation) |
| 204 | Success | No content (deleted) | DELETE operations (QR code, lead list, user deletion) |
| 400 | Client Error | Validation error | Invalid request data, missing fields |
| 401 | Client Error | Authentication failed | Missing or invalid API key |
| 403 | Client Error | Permission denied | Insufficient permissions |
| 429 | Client Error | Rate limit exceeded | Too many requests |
| 500 | Server Error | Internal server error | Server-side issues |
For detailed information about specific endpoints and their responses, refer to the API Reference documentation.