openapi-directory
Version:
Building & bundling https://github.com/APIs-guru/openapi-directory for easy use from JS
1 lines • 2.8 MB
JSON
{"openapi":"3.0.0","servers":[{"url":"https://www.docusign.net/restapi"}],"info":{"contact":{"email":"devcenter@docusign.com","name":"DocuSign Developer Center","url":"https://developers.docusign.com/"},"description":"The DocuSign REST API provides you with a powerful, convenient, and simple Web services API for interacting with DocuSign.","termsOfService":"https://www.docusign.com/company/terms-and-conditions/web","title":"DocuSign REST API","version":"v2.1","x-apisguru-categories":["ecommerce"],"x-logo":{"url":"https://twitter.com/DocuSign/profile_image?size=original"},"x-origin":[{"format":"openapi","url":"https://raw.githubusercontent.com/docusign/eSign-OpenAPI-Specification/master/esignature.rest.swagger-v2.1.json","version":"3.0"}],"x-providerName":"docusign.net"},"externalDocs":{"description":"See the DocuSign REST API Guide for more information.","url":"https://docs.docusign.com/esign"},"tags":[{"description":"The AcccountBrands resource provides methods that enable you to create and manage brands for an account.\n\nBranding enables you to add the look and feel of your organization's brand to the sending, signing, and email processes, making it easier for recipients to identify envelopes coming from your organization.\n\nThe DocuSign Account Custom Branding feature enables you to set the colors, logo, and text that recipients see at the account level. The settings associated with a brand are applied to all of the envelopes that use the brand. You can create multiple brand profiles for different corporate brands or internal departments.\n\n**Note:** To use this resource, branding for either signing or sending must be enabled for the account (either `canSelfBrandSend`, `canSelfBrandSign`, or both of these account settings must be set to **true**). ","name":"AccountBrands"},{"description":"The `AccountConsumerDisclosures` resource provides methods that enable you to enable, retrieve, and manage the Electronic Record and Signature Consent Disclosure (ERSD) options for your account. This is the disclosure that displays to each new recipient who is going to sign or add other information, or who is required to view the documents you send to them. The recipient must read and agree to the terms of the disclosure before they can access and take action on the documents you send. The ERSD does not apply to copy-only recipients, but does apply to recipients who must sign or view your documents.\n\nYou can use either the default ERSD that DocuSign provides for U.S.-based transactions, or a custom ERSD. \n\n## Languages\n\n**Important:** The system does not translate the ERSD for you. The default ERSD is always in English. For a custom ERSD, an account administrator must create a version of the disclosure for each language that your signers use. When you create a version of your custom ERSD for a specific signer language, you must:\n\n1. Specify the language code (`langCode`) for the signer language.\n2. Provide the `esignAgreementText` and `esignText` in the language associated with the `langCode`.\n\nFor more information, see [Legal Disclosure](https://support.docusign.com/en/guides/ndse-admin-guide-legal-disclosure).","name":"AccountConsumerDisclosures"},{"description":"Custom fields enable you to record custom information about envelopes that you can then use for sorting, organizing, searching, and other downstream processes. \n\nFor example, you can use custom fields to copy envelopes or data to multiple areas in Salesforce. eOriginal customers can eVault all of their documents from the web app by setting an account custom field with a name like `eVault with eOriginal` to **true.**\n\nYou can also use account custom fields to set the following information:\n\n- Tracking ID\n- Department \n- Use case\n- Other envelope metadata\n\n## Envelope Custom Field Visibility\n\nWhen you create an envelope custom field for your account, you have the following options: \n\n- Make it a required field for senders at the time of sending\n- Display it as an optional field at the time of sending\n- Set a specific value for the field behind the scenes (NOT SURE IF THIS IS RIGHT; MIGHT JUST BE AN UNUSED DRAFT FIELD)\n\nEnvelope recipients do not see the envelope custom fields.\n\n## Types of Envelope Custom Fields\n\nThere are two types of envelope custom fields:\n\n- `text`: Enables the sender to enter the value for the field. \n- `list`: Enables the sender to select the value of the field from a predetermined list.","name":"AccountCustomFields"},{"description":"The EnvelopeCustomFields resource provides methods that allow you manage custom fields in an envelope.\n\nCustom fields can be used in the envelopes for your account to record information about the envelope, help search for envelopes and track information. The envelope custom fields are shown in the Envelope Settings section when a user is creating an envelope in the DocuSign member console. The envelope custom fields are not seen by the envelope recipients.\n\nThere are two types of envelope custom fields:\n\n- `text`: Enables the sender to enter the value for the field.\n- `list`: Enables the sender to select the value of the field from a predetermined list.\n\n","name":"EnvelopeCustomFields"},{"description":"The EnvelopeDocumentFields resource provides methods that allow you to manage custom fields on a document.\n\nCustom fields are name-value pairs that are returned by the API but otherwise not used by DocuSign. They are not seen by the envelope recipients.\n\n\n\n\n\n","name":"EnvelopeDocumentFields"},{"description":"Envelope locks allow you to manage locks on an envelope.\n\nTo prevent users from changing an envelope while another user is\nmodifying it, you can lock the envelope and set the time until\nthe lock expires.\n\nTo use envelope locks, the user must have envelope locking capability enabled.\n\n### Related topics\n\n- [Common API Tasks: Locking and unlocking envelopes](https://www.docusign.com/blog/dsdev-common-api-tasks-locking-and-unlocking-envelopes)\n\n","name":"EnvelopeLocks"},{"description":"The EnvelopeRecipients resource enables you manage the recipients of an envelope.\nAll recipient types share a set of [core parameters](#core-recipient-parameters),\nbut some recipient types have additional parameters.\nYou specify the recipient type using the `recipientType` parameter. The recipient types are as follows:\n\n<br>\n\n| Recipient type | Description |\n| :-------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| [Agent](#agent-recipient) | Agent recipients can add name and email information for recipients that appear after the agent in routing order. |\n| [Carbon Copy](#carbon-copy-recipient) | Carbon copy recipients get a copy of the envelope but don't need to sign, initial, date, or add information to any of the documents. This type of recipient can be used in any routing order. Carbon copy recipients receive their copy of the envelope when the envelope reaches the recipient's order in the process flow and when the envelope is completed. |\n| [Certified Delivery](#certified-delivery-recipient) | Certified delivery recipients must receive the completed documents for the envelope to be completed. However, they don't need to sign, initial, date, or add information to any of the documents. |\n| [Editor](#editor-recipient) | Editors have the same management and access rights for the envelope as the sender. They can make changes to the envelope as if they were using the Advanced Correct feature. This recipient can add name and email information, add or change the routing order, set authentication options, and can edit signature/initial tabs and data fields for the remaining recipients. The recipient must have a DocuSign account to be an editor. |\n| [In-Person Signer](#in-person-signer-recipient) | In-person signer recipients are DocuSign users who act as signing hosts in the same physical location as the signer. |\n| [Intermediary](#intermediary-recipient) | Intermediaries are recipients who can, but are not required to, add name and email information for recipients at the same or subsequent level in the routing order, unless subsequent agents, editors, or intermediaries are added. |\n| [Seal](#seal-recipient) | Electronic seal recipients represent legal entities rather than individuals. Organizations and governments can use electronic seals to show evidence of origin and integrity of documents. |\n| [Signer](#signer-recipient) | Signers are recipients who must sign, initial, date, or add data to form fields on the documents in the envelope. |\n| [Witness](#witness-recipient) | Witnesses are recipients whose signatures affirm that the identified signers have signed the documents in the envelope. |\n\n<br>\n\nNot all recipients are are available to all account types.\nReview your account plan to determine which recipient types are available to you.\nAll recipient types are available in the development environment.\n\n\n## Core Recipient Parameters\n\nAll recipients, regardless of type, have the same common core parameters.\nThe following table contains the descriptions for the core properties for all recipient types:\n\n<br>\n\n| Name | Required | Schema Type | Description |\n| :--------------------------------------- | :------- | :-------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| email | Yes | Email | Email of the recipient. Notification will be sent to this email id.<br/>Maximum Length: 100 characters. |\n| name | Yes | String | Full legal name of the recipient.<br/>Maximum Length: 100 characters.<br/><br/>**Note:** If you are creating an envelope with DocuSign EU advanced signature enabled, ensure that recipient names do not contain any of the following characters: **^ : \\ @ , + <** |\n| accessCode | No | String | This optional element specifies the access code a recipient has to enter to validate the identity.<br/>Maximum Length: 50 characters. |\n| addAccessCodeToEmail | No | Boolean | This optional attribute indicates that the access code is added to the email sent to the recipient; this nullifies the Security measure of Access Code on the recipient. |\n| agentCanEditEmail | No | Boolean | When **true,** the agent recipient associated with this recipient can change the recipient's pre-populated email address. This element is only active if enabled for the account. |\n| agentCanEditName | No | Boolean | When **true,** the agent recipient associated with this recipient can change the recipient's pre-populated name (`UserName`). This element is only active if enabled for the account. |\n| clientUserId | No | String | This specifies whether the recipient is embedded or remote.<br/><br/>If the `clientUserId` property is not null then the recipient is embedded. Note that if the `ClientUserId` property is set and either `SignerMustHaveAccount` or `SignerMustLoginToSign` property of the account settings is set to **true,** an error is generated on sending. Maximum length: 100 characters. |\n| embeddedRecipientStartURL | No | String | This is a sender provided valid URL string for redirecting an embedded recipient. When using this option, the embedded recipient still receives an email from DocuSign, just as a remote recipient would, but when the document link in the email is clicked the recipient is redirected, through DocuSign, to this URL to complete their actions. When routing to the URL, it is up to the sender's system (the server responding to the URL) to then request a recipient token to launch a signing session.<br/><br/>If the value `SIGN_AT_DOCUSIGN` is used for this node, the recipient is directed to an embedded signing or viewing process directly at DocuSign. The signing or viewing action is initiated by the DocuSign system and the transaction activity and Certificate of Completion records will reflect this. In all other ways the process is identical to an embedded signing or viewing operation that would be launched by any partner.<br/><br/>It is important to remember that in a typical embedded workflow the authentication of an embedded recipient is the responsibility of the sending application and DocuSign expects that senders will follow their own process for establishing the recipient's identity. In this workflow the recipient goes through the sending application before the embedded signing or viewing process in initiated. However, when the sending application sets the `EmbeddedRecipientStartURL` property to `SIGN_AT_DOCUSIGN`, the recipient goes directly to the embedded signing or viewing process bypassing the sending application and any authentication steps the sending application would use. In this case, DocuSign recommends that one of the normal DocuSign authentication features (Access Code, Phone Authentication, SMS Authentication, etc.) be used to verify the identity of the recipient.<br/><br>If the `clientUserId` property is NOT set and the `embeddedRecipientStartURL` property is set, DocuSign ignores the redirect URL and launch the standard signing process for the email recipient. Information can be appended to the `embeddedRecipientStartURL` property using merge fields. The available merge fields items are: envelopeId, recipientId, recipientName, recipientEmail, and customFields. The customFields must be part of the recipient or envelope. The merge fields are enclosed in double brackets.<br/><br/>_Example_:<br/>`http://senderHost/[[mergeField1]]/ beginSigningSession? [[mergeField2]]&[[mergeField3]]`|\n| customFields | No | customField | An optional array of strings that allows the sender to provide custom data about the recipient. This information is returned in the envelope status but otherwise not used by DocuSign. String `customField` properties have a maximum length of 100 characters. |\n| emailNotification | No | emailNotification | An optional property that has information for setting the language for the recipient's email information. It is composed of three elements:<br/><br/>*emailBody*: a string with the email message sent to the recipient.<br/>Maximum Length: 10000 characters.<br/><br/>*emailSubject*: a string with the subject of the email sent to the recipient.<br/>Maximum Length: 100 characters.<br/><br/>*supportedLanguage*: The simple type enumeration (two-letter code) for the language to use for the standard email format and the signing view for the recipient. To retrieve the possible values, use the [Accounts::listSupportedLanguages method][ListLang].<br/><br/>**Note:** You can set the `emailNotification` property separately for each recipient. If you set the value only for certain recipients, the other recipients will inherit the this value from the top-level `emailSubject` and `emailBlurb`. |\n| excludedDocuments | No | Array of Strings | Specifies the documents that are not visible to this recipient. Document Visibility must be enabled for the account and the enforceSignerVisibility property must be set to true for the envelope to use this.<br/><br/>When the enforceSignerVisibility property is set to **true,** documents with tabs can only be viewed by signers that have a tab on that document. Recipients that have an administrative role (Agent, Editor, or Intermediaries) or informational role (Certified Deliveries or Carbon Copies) can always see all the documents in an envelope, unless they are specifically excluded using this setting when an envelope is sent. Documents that do not have tabs are always visible to all recipients, unless they are specifically excluded using this setting when an envelope is sent. |\n| idCheckConfigurationName | No | String | Specifies authentication check by name. The names used here must be the same as the authentication type names used by the account (these name can also be found in the web console sending interface in the Identify list for a recipient). This overrides any default authentication setting.<br/><br/>_Example_:<br/> Your account has ID Check and SMS Authentication available and in the web console Identify list these appear as 'ID Check $' and 'SMS Auth $'. To use ID check in an envelope, the `idCheckConfigurationName` property must be set to `ID Check $`. To use SMS, it must be set to `SMS Auth $` and you must add phone number information to the `smsAuthentication` node. |\n| iDCheckInformationInput | No | IdCheckInformationInput | This complex element contains input information related to a recipient ID check. It can include the following information.<br/><br/>*addressInformationInput*: Used to set recipient address information and consists of:<br/><br/>*addressInformation*: consists of six elements, with street2 and zipPlus4 being optional. The elements are: street1, street2, city, state, zip, zipPlus4\\. The maximum number of characters in each element are: street1/street2 = 150 characters, city = 50 characters, state = 2 characters, and zip/zipPlus4 = 20 characters.<br/><br/>displayLevelCode: Specifies the display level for the recipient. Values are: ReadOnly, Editable, or DoNotDisplay.<br/><br/>*receiveInResponse*: A Boolean element that specifies if the information needs to be returned in the response.<br/><br/>*dobInformationInput*: Used to set recipient date of birth information and consists of:<br/><br/>*dateOfBirth*: Specifies the recipient's date, month and year of birth.<br/><br/>*displayLevelCode*: Specifies the display level for the recipient. Values are: ReadOnly, Editable, or DoNotDisplay.<br/><br/>*receiveInResponse*: A Boolean element that specifies if the information needs to be returned in the response.<br/><br/>*ssn4InformationInput*: Used to set the last four digits of the recipient's SSN information and consists of:<br/><br/>*ssn4*: Specifies the last four digits of the recipient's SSN.<br/><br/>*displayLevelCode*: Specifies the display level for the recipient. Values are: ReadOnly, Editable, or DoNotDisplay.<br/><br/>*receiveInResponse*: A Boolean element that specifies if the information needs to be returned in the response.<br/><br/>*ssn9InformationInput*: Used to set the recipient's SSN information. Note that the ssn9 information can never