The page provides the description of expected errors of Claid API and guidance how to handle them.

The Claid API provides standard HTTP status codes. Every successful responses are indicated with a 200-series and error responses with non-200-series HTTP code.

Error reasons can vary, but the structure of the response always looks the following:

Error response structure

    "error_code": "9000",
    "error_type": "validation",
    "error_message": "name: ensure this value has at most 50 characters. parameters.credentials.access_key: field required.",
    "error_details": {
        "name": [
            "ensure this value has at most 50 characters"
        "parameters.credentials.access_key": [
            "field required"

Error response attributes:

  • error_code string Claid internal error identifier.

  • error_type string Claid errors are grouped by topics and this field returns the name of that group.

  • error_message string A human-readable description of the error. If there were several reasons for failure - they will be concatenated as separate sentences, divided with . (dot).

  • error_details object If there is a request validation error with key:value pairs - this field represents a nicely formatted version of error_message. Otherwise it can be an empty object - {}.

Error response example with an empty error_details

    "error_code": "111",
    "error_type": "auth",
    "error_message": "Authorization is required.",
    "error_details": {}

How to get error reason

If you want to get a human-readable error message, then it is best to always get data from the error_message attribute.

If you prefer to represent the error yourself according to the key:value pairs of errored fields, use error_details. Note: It can be an empty object if there was no validation error associated with the field. In this case, you can get the message from the error_message attribute.

HTTP status codes summary

200-2xx OK

Everything worked as expected

400 Bad Request

Since this is a generic error, there can be several reasons why we get it, such as when we can't get the object from storage, or can't even parse JSON payload when it's invalid.

In any case, you can get the error reason from error_message attribute. See the How to get error reason above.

401 Unauthorized

You are unauthorized to access the requested resource. Learn how to authenticate via API key.

402 No API calls left

Your account has run out of API calls. Purchase more API call credits to continue using

403 Forbidden

The API key doesn't have permissions to perform the request. We recommend checking the scopes and correctness of the API key.

404 Not Found

The requested resource doesn't exist.

409 Conflict

The request can't be processed, because of conflict in the current state of the resource.

422 Unprocessable Entity

The error indicates that the payload has logical or validation issues. The concrete reasons can be found in error_message and error_details fields.

429 Too Many Requests

Request cannot be served due to the API's rate limit. See Rate Limits page for more information.

500 Internal Server Error

Temporary error, which indicates that we experiencing an internal error.

This is a rare case but if you continue to receive this error, please reach out to API support with request details.

Get help

In case of any issues with image processing, you can reach out to our technical support and provide them details with x-request-id header value (see the API reference).

Last updated