## Status codes
When processing the response, the client shall first detect, what response
status code was received.
For GET requests for responses with 200 code, it is not necessary to explore
the `errors` part of the response.
For PATCH/PUT requests, which can process more records at the same time and
some records
are not processed successfully, these end with a 200 response code and the
errors key contains info
on skipped rows.
The unknown record is returned with a 404 code, etc. These responses have
the error field filled in, where you can
find detailed info about the error.
The following errors might be expected:
* 400 - Some of the validations on item level have failed. There is no
reason to retry, it will fail always.
* 401 - Invalid token or the token has expired (for addons access tokens).
You have to ask for another one.
* 403 - Forbidden. The token has no rights to the endpoint called. The
endpoints must be allowed for an addon
and the eshop must have approved them. Valid for addons access tokens, private tokens can always access all
endpoints. Can be also returned when required module for request is missing.
* 404 - Either the endpoint is wrong; or most commonly, an entity
identifier, which is part of the URL, does
not exist.
* 409 - Conflict - the action could not be completed for some consistency
rules, such as duplicate data
or relation, which would be broken.
* 413 - Payload too large - update requests can sometimes contain multiple
entities to be amended. There is
however a limit (varying for each request), how many can be specified within one request. If you breach the
limit, you will get this error and nothing will be updated.
* 422 - Unprocessable entity - we were not able to parse the request - it
does not match the expected format.
Something is wrong with the request as whole, it might not be a correct JSON or it does not match the expected
JSON schema. There is no reason to retry, it will always fail.
* 423 - Locked - for update and some read request we apply locks, usually on
an URL level, which should avoid
consistency problems possibly occuring from parallel updates. See [Locks](#section/basic-principles/locks) section. Retry later,
try to avoid parallel update requests.
* 500 - General server error. Yes, this might happen to our software, too.
Most commonly this is a temporary
database issue and it might (but might not), work a few minutes later. We monitor all such errors and we
try to analyze and fix them.
* 503 - System maintenance. Most commonly we move a database to another
database cluster or a database migration is
pending and it will be available in a few minutes. Please try later.