docusign / openapi-specifications Goto Github PK
View Code? Open in Web Editor NEWThe official Docusign REST APIs Swagger Specifications
License: MIT License
The official Docusign REST APIs Swagger Specifications
License: MIT License
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. "
},
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
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
.
Environment/Tools:
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.
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?
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
#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.
The BCCEmailArchive object is referenced in other places as bccEmailArchive, and the similar objects for bccEmailArchiveList
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.
radioGroup definition contains a field name "tooltipMetadata". All other tabs have this field name "toolTipMetadata".
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.
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
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.
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!
Is this repository being maintained still? Are there plans to provide the 2.1 spec any time soon?
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?
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 :
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]
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"
}
}
}
]
}
['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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.