Skip to main content
The API immediately informs you, synchronously, what is wrong: there are no validations that take hours or responses that arrive later. Each validation error has a stable code that you can use in your program and a sentence for humans.

Format

Validation errors and refusals with a reason use RFC 9457 (Problem Details), with Content-Type: application/problem+json.

Validation (422)

Each item in errors[] has:
string
The field with the issue, as JSON Pointer: /title, /features/2 (the third element from features), /photos/0/key.
string
The error code. It’s stable: from it, you branch in your code. The list is below.
string
An explanation for humans, in the request language. The text may change at any time; do not compare it in the program.
A field can have multiple errors, each with its own element in errors[].

Refusals with a reason (409, 412)

Here the code is directly in code, at the first level.

Other refusals

All have the same form, with code at the first level:

Message language

detail and title come in Romanian or English. You choose the language with the locale parameter in the address (?locale=en). Without it, the preferred language of the account is used, then the header Accept-Language, then Romanian. Codes are never translated.

Validation codes per field

When a field, taken alone, does not respect its rule, the code is the name of the rule:

Cross-field check codes

Some rules apply to multiple fields at once. Their code is specific to the rule, and pointer indicates the field to correct.

Rejection codes

HTTP statuses

When asking for help for an error, send us the value of the header X-Request-Id from the response. With it, we find the exact request. You can also see it in the API log.