Currently all error problems from the server side (API) are messages (Strings).
For each of them, an integer code should be added, that is different everytime, and each of those codes should be documented on the API docs: on their own page with details, but also on every other page, every request should document which error codes it can fail with (by linking to the relevant page).
This is important because:
- String errors are not documented anywhere, therefore cannot be considered stable. It's dangerous for the clients to work on unstable APIs. (Eg. If some uppercase is made lowercase, the clients break)
- Integer error codes, although unreadable for humans, are much easier to work with (no upper cases, no special characters, clear rules)
- Integer error codes allow sync with the translation APIs: the translators would get a String to translate for each error code. This would allow users to display errors in their language of choice.
- Since error messages are not documented yet, it is necessary to try potential errors when building the client, which is a pain & has high risks of forgetting some cases.