I have noticed two problems with the generated Java client code. At the moment, these require manual changes by me in order to use the client API code.
The user ‘pmi’ field is typed as a Java Integer in the InlineResponse20033 model class, but the field is required to have 10-digits. This means that any pmi which represents a number greater than 2147483647 (0x7FFFFFFF) will overflow the Java Integer type, and de-serialization (for example, Jackson libraries) will throw an exception.
The account ‘id’ field is typed as a java.util.UUID in the AccountListAccounts model class, and the UUID type has a specific 36-character format (including 4 dashes). The ids of the test accounts that we have created do not follow this format (they are 22-character strings), and so de-serialization (for example, Jackson libraries) will throw an exception. I am assuming these id’s are generated by the Zoom system.