Skip to main content

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.
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.
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 info or pattern_info fields
  • Invalid category ID
  • Invalid data structure for the selected category
  • Invalid pattern_info format

How to Handle

  1. Check the response body for field-specific errors
  2. Validate your request payload against the API documentation
  3. Ensure all required fields are present
  4. Verify JSON formatting for info and pattern_info fields

Server Errors

Server errors indicate an issue on Scanova’s end.
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

  1. Retry the request after a short delay
  2. Implement exponential backoff retry logic
  3. If the error persists, contact support with:
    • The request details
    • Timestamp of the error
    • Response body (if available)

Retry Logic Example

If you encounter persistent 500 errors, please contact our support team with details about the request that failed.

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 CodeCategoryMeaningCommon Use Cases
200SuccessRequest successfulGET, PUT, PATCH operations
201SuccessResource createdPOST operations (QR code, lead list, user creation)
204SuccessNo content (deleted)DELETE operations (QR code, lead list, user deletion)
400Client ErrorValidation errorInvalid request data, missing fields
401Client ErrorAuthentication failedMissing or invalid API key
403Client ErrorPermission deniedInsufficient permissions
429Client ErrorRate limit exceededToo many requests
500Server ErrorInternal server errorServer-side issues
For detailed information about specific endpoints and their responses, refer to the API Reference documentation.