Skip to main content
Every response reports the result on two levels:
  • The HTTP status code tells the kind of error: is the request invalid (400), is a permission missing (403), does the record not exist (404)?
  • ResultCode tells exactly what went wrong, e.g. 1002 the customer code is already used. All codes are listed on the Result codes page.

Error response

boolean
false for errors.
string
0000 on success. On failure, the code of the first error.
string
All error messages joined into one text, separated by spaces (English).
array
Code and Message for each error. Only present on failure.
If a request has several validation errors, all of them are returned in one response. ResultCode is then the code of the first error; check the Errors list when you look for a specific error.
Base your integration logic on Code, not on the Message text. Message wording may be improved, but the meaning of a code never changes.

HTTP status codes

Order of checks

If a request has problems at different stages, the errors of the first stage are returned. Checks run in this order:
1

Token (401)

Is there a token, and are its signature and lifetime valid?
2

Headers (400)

Are X-UserID, X-CompanyID and X-PeriodID valid, and is the user assigned to the company?
3

Permission (403)

Does the key have the required read or write permission for the module?
4

Daily limit (429)

Has today’s limit been exceeded?
5

Body format (400)

Can the JSON body be read?
6

Business rules (400 / 404)

Are the fields valid, and does the record exist and is it visible?

Malformed body errors

If the JSON body cannot be read (malformed JSON, an invalid value in a GUID field, text in a number field and so on), the API returns 400 with code 0002. The message contains the JSON path of the invalid field:

Handling errors

Retry only 401 (after refreshing the token), 429 (the next day) and 500. 400, 403 and 404 return the same result if the request is repeated unchanged.