Errors

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 be variety, but the structure of the response always looks the following:
Error response structure
1
{
2
    "error_code": "9000",
3
    "error_type": "validation",
4
    "error_message": "name: ensure this value has at most 50 characters. parameters.credentials.access_key: field required.",
5
    "error_details": {
6
        "name": [
7
            "ensure this value has at most 50 characters"
8
        ],
9
        "parameters.credentials.access_key": [
10
            "field required"
11
        ],
12
}
Copied!
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 was several reasons of failure - they will be concatenated as separate sentences, divided with point.
error_details object
 If there is request validation error with key:value pairs - this field represents nicely formatted version of error_message. Otherwise it can be empty object - {}.
Error response example with an empty error_details
1
{
2
    "error_code": "111",
3
    "error_type": "auth",
4
    "error_message": "Authorization is required.",
5
    "error_details": {}
6
}
Copied!
Strategy 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, but  consider that 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 Strategy to get error reason above.
403  Forbidden
The API key doesn't have permissions to perform the request. We recommend to check 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 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).
​

Rate limits

Next - Image Editing API

Image I/O

Last modified 1mo ago

Copy link

Edit on GitHub

Contents

Error response structure

HTTP status codes summary

Get help