Closed mkornblum closed 3 years ago
(I should also note I'm guessing this thing is code gen'd via swagger or the like, so it probably can't throw an exception there, but it would still be nice if it could!)
@mkornblum first of all apologies for not responding in a more timely manner. Everything you said makes sense. The "release notes" for version 2.19.0-RC2 had a typo and it should say v2-20.4.01. The typo has been fixed now (thanks to you).
For more information about this SDK's version 2.x VS 3.x please have a quick look on this page (although the exact minor and patch versions might not be up-to-date): https://developers.docusign.com/docs/esign-rest-api/esign101/upgrading-v21/#sdks
If you want to use the latest from the eSign API, you should migrate to version 3 of this SDK. Most of integrations shouldn't see any/lot of breaking changes. Also API v2 is being put on maintenance mode and will be sunset soon. I encourage you to look at the link in the previous paragraph to lean about feature changes between the two versions so you'll have a good idea how much effort is needed for the migration.
thanks for your help!
Howdy,
The release commit here - https://github.com/docusign/docusign-java-client/releases/tag/v2.19.0-RC2 - says the 2.19.0-RC2 release is meant to support v2.1-20.4.01 of the REST API, however, in at least this one code path, it's still calling API V2.
The outcome here is that I can make a call like this:
And it will look like everything is working fine, the code will compile, etc, except that
recipients
will always be null in the last line, becauseinclude=recipients
was reserved for DocuSign use in V2 - https://developers.docusign.com/docs/esign-rest-api/v2/reference/envelopes/envelopes/get/It would have been a lot faster to figure this out if the SDK threw a
NotImplementedException
or something along those lines when it's passed invalid options.Cheers!