Hi,

Would you be willing to share the tools/commands you use to generate the API code for the different languages you have on the Developer Site?

I'm trying to generate the 2.1 API code and I'm running into many problems, both with OpenAPI generator and Swagger CodeGen. Eveything works fine with version 2.0 of the DocuSign specs.

Thanks

Environment/Tools:

• e-Signature REST OpenAPI Specification v2.1
• Go-Swagger version: v0.30.5 (commit: ab6a7885723430004f1d7db6395369b6e7f3370b)
• golang version: go1.19.7 darwin/arm64 (on iOS)

Problem Statement: While the go-swagger tooling does successfully generate the set of client/model objects needed for a golang client implementation of the Docusign eSignature v2.1 client , attempting to build those source files in go produces the following error:

$ go build ./...

# github.com/TheWeatherCompany/docusign-esign-client/gen/swagger/apis/v2_1/client/envelope_consumer_disclosures
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:181:2: LangCode redeclared
	gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:129:2: other declaration of LangCode
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:287:86: ConsumerDisclosureGetConsumerDisclosureEnvelopeIDRecipientIDLangCodeParams.WithLangCode redeclared in this block
	gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:276:86: other declaration of WithLangCode
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:288:16: cannot use langCode (variable of type *string) as type string in argument to o.SetLangCode
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:293:86: ConsumerDisclosureGetConsumerDisclosureEnvelopeIDRecipientIDLangCodeParams.SetLangCode redeclared in this block
	gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:282:86: other declaration of SetLangCode
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:294:15: cannot use langCode (variable of type *string) as type string in assignment
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:331:19: invalid operation: o.LangCode != nil (mismatched types string and untyped nil)
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:336:20: invalid operation: o.LangCode != nil (mismatched types string and untyped nil)
gen/swagger/apis/v2_1/client/envelope_consumer_disclosures/consumer_disclosure_get_consumer_disclosure_envelope_id_recipient_id_lang_code_parameters.go:337:18: invalid operation: cannot indirect o.LangCode (variable of type string)

The issue appears to be a possible duplicate "langCode" Param in the "/v2.1/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/consumer_disclosure/{langCode}" section (~ line 8637)

Also, as per the description of that endpoint:

Retrieves the HTML-formatted Electronic Record and Signature Disclosure (ERSD) for the envelope recipient that you specify. This disclosure might differ from the account-level disclosure, based on the signing brand applied to the envelope and the recipient's language settings.\n\nTo set the language of the disclosure that you want to retrieve, specify the langCode as either a path or query parameter.

Why would I do this: specify the langCode as either a path or query parameter? That seems confusing. Wouldn't it just makes more sense, and clarify the intent of, and simplify, the API, to choose one parameter approach.

NOTE: that the successful generation of the golang client source is done using the --skip-validation argument when running the go-swagger, which is why I believe that the code generation succeeds at all.

This feels like a basic OpenAPI validation issue in https://github.com/docusign/OpenAPI-Specifications/blob/master/esignature.rest.swagger-v2.1.json that should be fixed.

OrganizationResponse field identity_providers shows an array of IdentityProvidersResponse (note Providers plural) when it should be an array of IdentityProvidersResponse singular.

See related docusign/docusign-admin-python-client#13

I am trying to use the Docusign Swagger v2.1 to generate code in a Spring app with Maven by using CodeGen. I am running into an issue with the generated files – specifically the List Model

…\client\docusign\ri\model\List.java

This class is called “List” per the swagger specs. However, it contains a few properties with datatypes of java.util.List:

private List<ListItem> listItems = null;

private List<String> tabGroupLabels = null;

Unfortunately, CodeGen is typing those properties at type List from the class definition rather than java.util.List type. This is preventing successful build. Are you aware of a work around for this issue to ensure these members get typed correctly via Maven code generation?

For some languages (I'm using Elixir), the "number" definition and "date" definition are being mapped to built-in types instead of the DocuSign provided type definitions.

The current workaround is to edit the OpenAPI spec to rename these definitions and the references to them. See: neilberkman/docusign_elixir#37

This may be a bug in OpenAPI Generator specific to Elixir, but I was wondering if anyone is seeing this problem with other languages?

radioGroup definition contains a field name "tooltipMetadata". All other tabs have this field name "toolTipMetadata".

The height and width attributes of the tabs are defined as strings in the v2.1. Version 2 defined them as int32. API responses return numeric representation, not strings and samples in the swagger file also show the fields as integers.

Hi

I think there is a problem in the offlineAttributes definition (line 51551)
here is the definition

    "offlineAttributes": {
      "$ref": "#/definitions/offlineAttributes",
      "description": "Reserved for DocuSign."
    },

it references it self..

Thx

In the v2.1 API, there is a schema called BCCEmailArchive that is not referenced anywhere. It seems to be a duplicate of bccEmailArchiveHistoryList. There is also another schema called bccEmailArchive that is referenced. I think BCCEmailArchive should be removed.

Using the OpenAPI Generator to generate Java code on a non-case sensitive file system (e.g. on a Mac) will produce a file BCCEmailArchive.java containing the public class BccEmailArchive which is not allowed and causes compilation to fail.

Workaround: add an ignore file that ignores BCCEmailArchive.java.

SignatureAPI - Settings schema doesn't include accountMangementGranular

Example request/response from Docusign

GET https://demo.docusign.net/restapi/v2.1/accounts/{account_id_here}/permission_profiles?include=user_count, closed_users, account_management, metadata

{
    "permissionProfiles": [
        {
            "permissionProfileId": "13057704",
            "permissionProfileName": "Account Administrator",
            "modifiedDateTime": "2022-05-19T18:03:21.7170000Z",
            "modifiedByUsername": "",
            "userCount": "2",
            "settings": {
                "allowAccountManagement": "true"
            }
        },
        {
            "permissionProfileId": "13057705",
            "permissionProfileName": "DocuSign Sender",
            "modifiedDateTime": "2022-05-19T18:03:21.7170000Z",
            "modifiedByUsername": "",
            "userCount": "0",
            "settings": {
                "allowAccountManagement": "false"
            }
        },
        {
            "permissionProfileId": "13057706",
            "permissionProfileName": "DocuSign Viewer",
            "modifiedDateTime": "2022-05-19T18:03:21.7170000Z",
            "modifiedByUsername": "",
            "userCount": "0",
            "settings": {
                "allowAccountManagement": "false"
            }
        },
        {
            "permissionProfileId": "13404852",
            "permissionProfileName": "Visch",
            "modifiedDateTime": "2022-07-27T00:09:00.4070000Z",
            "modifiedByUsername": "Visch",
            "userCount": "1",
            "settings": {
                "allowAccountManagement": "false",
                "accountManagementGranular": {
                    "allowManageUsers": "False",
                    "allowManageAdmins": "False",
                    "allowManageSharing": "False",
                    "allowManageEnvelopeTransfer": "False",
                    "allowManageAccountSettings": "True",
                    "allowManageReporting": "True",
                    "allowManageAccountSecuritySettings": "False",
                    "allowManageSigningGroups": "False",
                    "allowManageDocumentRetention": "False",
                    "allowManageConnect": "False",
                    "allowViewUsers": "False",
                    "allowManageGroupsButNotUsers": "False",
                    "allowManageStamps": "False"
                }
            }
        }
    ]
}

The description for Envelopes - Update - reminderEnabled says:

When set to true, the envelope expires and is no longer available for signing after the specified number of days. When false, the account default setting is used. If the account does not have an expiration setting, the DocuSign default value of 120 days is used.

This makes sense for an expiration setting, but not one for sending reminder messages. This is in the Swagger definition for v2 and v2.1.

https://developers.docusign.com/esign-rest-api/reference/Envelopes/Envelopes/update#reminders

It is also mentioned under notifications (although I cannot find it on your web page), but that appears to make sense.

reminderEnabled - When set to true, a reminder message is sent to the recipient.

Is this repository being maintained still? Are there plans to provide the 2.1 spec any time soon?

#8 might be related, but both version 2 and 2.1 of the esignature spec have it defined as a string so maybe not.

With this discrepancy between spec and the actual API behavior we end up generating broken rust code that requires manually massaging.

['reserved_domains']['items']['properties']['settings']['items']['properties']['value'] doesn't have the correct type listed

https://github.com/docusign/OpenAPI-Specifications/blob/master/admin.rest.swagger-v2.json#L2884

describes the json object as an object. We are seeing some boolean values here. We're going to assume this value can actually be

"type":["string","boolean","object","number"]

Is this correct? Thank you!

Hello,

It appears the ApiClient object is missing from the definitions.

More Specifically because swagger doesn't contain the ApiClient object, I don't see any actual way of authenticating the requests via the API.

The documentation calls for

`
import * as docusign from 'docusign-esign';

const apiClient = new docusign.ApiClient(); // ApiClient doesn't exist
// use jwt authentication through apiClient object
`

I'm following the logic in your auto-generated Quickstart project for nodejs, the corresponding code location is on github.
Is there a new way to authenticate? If not could you help fix this? thanks!

The BCCEmailArchive object is referenced in other places as bccEmailArchive, and the similar objects for bccEmailArchiveList

userSocialIdResult and newAccountDefinition have a field name "socialAccountInformation" that references "#/definitions/UserSocialAccountLogins". This object does not exist.

"newAccountDefinition": {
      "type": "object",
      "properties": {
      ...
        "socialAccountInformation": {
          "$ref": "#/definitions/UserSocialAccountLogins",
          "description": "Contains properties that map a DocuSign user to a social account (Facebook, Yahoo, etc.)"
        }
     }

"userSocialIdResult": {
      "type": "object",
      "properties": {
        "socialAccountInformation": {
          "description": "Contains properties that map a DocuSign user to a social account (Facebook, Yahoo, etc.)",
          "type": "array",
          "items": {
            "$ref": "#/definitions/UserSocialAccountLogins"
          }
        },
        "userId": {
          "description": "The ID of the user to access. Generally this is the ID of the current authenticated user, but if the authenticated user is an Administrator on the account, `userId` can represent another user whom the Administrator is accessing.\n",
          "type": "string"
        }
      },

I noticed that there is a "socialAccountInformation" object that is not referenced by any other object. Is that the correct type for the fields?

"witness" object contains the field "offlineAttributes" with a reference of "#/definitions/offlineAttributes" which does not exist.

"witness": {
      "type": "object",
      "properties": {
      ...
        "offlineAttributes": {
          "$ref": "#/definitions/offlineAttributes",
          "description": "Reserved for DocuSign use. "
        },

I was trying to generate a golang client using the go-swagger utility and it barks on both swagger files:

swagger generate client -f ../eSign-OpenAPI-Specification/esignature.rest.swagger-v2.1.json -A go-demo-client
2021/01/14 10:35:17 validating spec /Users/gcsadmin/projects/docusign-api/eSign-OpenAPI-Specification/esignature.rest.swagger-v2.1.json
The swagger spec at "/Users/gcsadmin/projects/docusign-api/eSign-OpenAPI-Specification/esignature.rest.swagger-v2.1.json" is invalid against swagger specification 2.0. see errors :

• some references could not be resolved in spec. First found: object has no key "offlineAttributes"

I have corrected files (the ones go-swagger validates) and if you want I can provide them to you as PR.
Timofei Bolshakov, [email protected]

Definitions with an x-ds-definition-name value of "recipients" have an incorrect description for the recipientCount field.
It is currently read
"description": "The list of recipient event statuses that will trigger Connect to send updates to the url. It can be a two-part list with:\n\n* recipientEventStatusCode - The recipient status, this can be Sent, Delivered, Completed, Declined, AuthenticationFailed, and AutoResponded.\n* includeDocuments - When set to **true**, the envelope time zone information is included in the message.",
`
The field appears to be a read-only count of all recipients.