eSignature API

Hello, After creating the integration in the demo environment, I am unable to deploy the API to the production environment. It tells me that I don’t have the necessary permissions, but this shouldn’t be possible, since I have all the permissions for Esignature and the organization, and I’ve also been granted developer admin access. The integration is already configured, and we also have a Docusign partner. We urgently need to deploy the API; what could be the problem?Thank you for your help.

Is there a documentation for how to do this from scratch. Will need step-by-step instructions

I am trying to get in touch with Docusign Support to troubleshoot envelope deliverability issues. I have tried to start a chat as instructed on the Support page [https://support.docusign.com/s/contactSupport?language=en_US], but the “chat with us” button does not work.How can I get in touch with Support if I am testing things from a developer account?

We are integrating the Docusign eSignature REST API and need to test Advanced Electronic Signatures (AES) and Qualified Electronic Signatures (QES) in our developer/demo account before production go-live.AccountSignatureProviders::List currently returns only DS Electronic (universalsignaturepen_imageonly). The official Docusign developer documentation states that Customer Service can add QES Signatures to a developer account.Could a Docusign team member please confirm the correct provisioning route and enable, or help us request, suitable AES and QES test signature providers for this demo account? We need to test recipientSignatureProviders/signatureProviderName, Connect identity-verification events, and completed-envelope audit evidence. No production enablement is requested at this stage.

Hi everyone,I’m integrating DocuSign with a C# application. Before sending an envelope, I want to validate the recipient’s email address.Currently, I can perform basic format validation, for example checking whether the email has a valid format such as user@company.com.However, I would like to know if there is a recommended way in the DocuSign API/SDK to determine whether the recipient email address actually exists and is deliverable before sending the envelope.For example: Can DocuSign validate whether the mailbox actually exists? Is there an API or recommended approach to check email deliverability before creating/sending the envelope? If the email is invalid or undeliverable, can I detect this before the envelope is sent? Any guidance on the recommended approach would be appreciated.Thanks!

Hello, We are using embedded signing with the Focused View (DocuSign.js) for a captive recipient (ClientUserId is set) whose recipient definition includes phone-based Identity Verification (RecipientIdentityVerification with a phone_number_list input option). This works correctly in our demo/sandbox environment, but fails in production. In production the Focused View iframe never renders the document, because the identity-verification step attempts to frame https://eu.verify.docusign.net/ and it is blocked by the Content Security Policy served on apps.docusign.com. Browser console error: Framing 'https://eu.verify.docusign.net/' violates the following Content Security Policy directive: "frame-src 'self' https://docucdn-a.akamaihd.net/ https://apps.docusign.com https://na.verify.docusign.net https://eu.docusign.net ... https://verify-d.docusign.net https://verify.docusign.net ...". The request has been blocked. Key point: the frame-src allowlist in that CSP includes https://na.verify.do

I have a Word template that I populate programmatically using C# and the Open XML SDK. The generated DOCX looks correct when I open it in Microsoft Word. However, when I upload the same DOCX directly to DocuSign and open the document for signing, I notice extra spacing between some characters in two paragraphs. The character spacing appears normal in Microsoft Word but changes when the document is displayed in DocuSign. I have added the screenshot for your reference First image: The generated Word document opened in Microsoft Word, where the character spacing appears normal.Second image: The same document opened in DocuSign for signing, where extra spacing between some characters is visible.I have also verified the font and character-spacing settings in the Word document, and they appear to be normal. Additionally, if I convert the generated DOCX to PDF using Microsoft Word and then upload the PDF to DocuSign, the spacing issue does not occur.Could you please help me understand why thi

We had an issue wherein the first name had extra spaces causing the signing to not work. Perhaps Docusign can recognize that there are 2 spaces in the name field and trim the extra space.  Btw, the document was sent from an integration. 

We have isolated a recipient email-delivery issue in our DocuSign Demo account.Manual envelopes created in the DocuSign UI deliver recipient invitation emails successfully, but envelopes created through the eSignature REST API do not, even when sent to the exact same recipient from the same Demo account.API-created envelope:Status: sent deliveryMethod: email Standard remote signer No clientUserId No embedded-signing configuration No email-suppression flags Envelope History shows Sent Invitations No bounce, rejection, or autoresponded status Envelope appears normally in DocuSign and can be signed successfully Recipient invitation email never arrivesControl tests:Manual envelope from the same Demo account to the same Yahoo recipient delivered immediately. Separate manual envelope to Gmail also delivered immediately.Controlled comparison:We have specific envelope IDs available for both the failed API-created envelope and the successful manually created envelope, but I have omitted them fr

Using the Android Mobile SDK (com.docusign:androidsdk:2.1.7) to launchcaptive/embedded signing from a pre-generated signing URL (obtainedserver-side via the eSignature REST API's EnvelopeViews: createRecipient),not via SDK-driven OAuth login — our app's signers don't have their ownDocuSign accounts.Setup:  DocuSign.init(context, integratorKey, DSMode.DEBUG)  // integratorKey is a real, valid Integration Key from Apps and KeysCall:  DocuSign.getInstance().getSigningDelegate()    .launchCaptiveSigning(activity, signingUrl, envelopeId, listener)DocuSign.init() succeeds with no error. But launchCaptiveSigning() alwaysfails before the signing UI ever appears, with:  com.docusign.androidsdk.exceptions.DSAuthenticationException:  DSAuthUser data is nullFull stack trace shows the failure originates inside the SDK's ownenvelope fetch:  E DocuSign_Auth: DSAuthUser is null  E DocuSign_EnvelopeRepository: Error while fetching the envelope    com.docusign.androidsdk.exceptions.DSAuthenticationExcep

Hello,I have a use case in a custom .NET application where users enter the information required to create a DocuSign envelope and are then redirected to the DocuSign web application with the envelope opened in draft/edit mode (status: created). They use the tagging page to place tabs such as Sign Here, Date Signed and Full Name.When they save and exit, they are returned to the originating application, which then uses the DocuSign API to change the envelope status to sent and initiate the workflow. This is a standard embedded sending scenario and has been working well for us.My question concerns a feature that used to be available during this process. When editing an envelope, there was previously a Preview or View As option that allowed the sender to preview the signing experience from the recipient's perspective. We found this extremely useful for demonstrations and for validating tab placement before sending.I noticed a few weeks ago that this option appears to have disappeared. Unfo

Hi DocuSign team, I am connecting the DocuSign MCP server from Cursor (demo environment) for Drew White & Co. Issue: unauthenticated requests to the MCP endpoint return HTTP 403 with body “RBAC: access denied” and no WWW-Authenticate header. MCP clients that follow the auth spec need HTTP 401 plus a WWW-Authenticate challenge to start OAuth. Because of the bare 403, Cursor never reaches the OAuth consent flow, so our Integration Key and Secret are never used. Repro (demo):POST https://mcp-d.docusign.com/mcpResponse: 403, body: RBAC: access denied, no WWW-Authenticate Related discovery issue: https://account-d.docusign.com/.well-known/oauth-authorization-server does not return OAuth authorization-server JSON (redirects to HTML login). Account: Drew White & Co. (developer/demo)Integration Key (DWC Servicing): b788aaf7-6b83-45b5-8255-0640d273736fAccount Base URI: https://demo.docusign.netContact email: **PII removed** Request: please update the MCP gateway so unauthenticated reque

Hi all,On our developer sandbox account, notification emails for one envelope were never delivered to either recipient. Both recipients have since confirmed directly that nothing arrived — inbox, spam and promotions all checked. Two manual resends produced nothing either. The envelope was eventually completed, but only because we reached the signers outside DocuSign; no notification email ever arrived for it.Setup: eSignature REST API, JWT Grant, demo environment (demo.docusign.net), two signers at the same routing order, both ordinary emailed signers.The audit trail records the invitations as sent, and records no bounce. Neither recipient ever moved to autoresponded, and neither carries an autoRespondedReason:  23:22:23Z  Registered        Envelope created  23:22:25Z  Sent Invitations  invitation to recipient 1  23:22:25Z  Sent Invitations  invitation to recipient 2  23:34:32Z  Resent            resent to recipient 1  23:35:12Z  Resent            resent to recipient 1A comparable enve

I am converting code from the legacy authentication to OAuth and using the new DocuSignClient in .net.  I am able to get the Access Token, but when I call the CreateEnvelope, it returns Misused header name, 'Authorization'.My code (in VB.NET)            Dim docuSignClient = New DocuSignClient("https://demo.docusign.net/restapi")            docuSignClient.Configuration.AddDefaultHeader("Authorization", "Bearer " & accessToken)            Dim envelopesApi = New EnvelopesApi(docuSignClient)            Dim envelopeDefinition = GetEnvelopeDefinition()            Dim results = envelopesApi.CreateEnvelope(clientID, envelopeDefinition)  

Hi all — I found a couple of similar threads here (linking below) but no resolution, and I've now isolated this about as far as I can from the outside. Hoping someone from DocuSign or with deeper API experience can help.Setup: Integrating via the eSignature REST API (JWT Grant / impersonation) from our own Laravel backend. Envelopes are created successfully and show status: sent (correct recipient, correct document, correct routing order), but the recipient's signing-invitation email never arrives — not in inbox, not in spam.What's been ruled out, with evidence:Payload correctness — verified the exact JSON sent to POST /v2.1/accounts/{accountId}/envelopes is well-formed and never sets clientUserId (so the recipient isn't misclassified as an embedded signer, which I know can silently suppress email). "Suppress emails to embedded signers" — checked and disabled on the account; not applicable anyway since clientUserId is never sent. Recipient-side filtering — tested with multiple previous

Hi everyone,I’m working on a Salesforce + DocuSign integration and would like some guidance on the best approach for storing completed/signed documents in Salesforce Files.Currently, I’m using a DocuSign Workflow that is triggered when the envelope status changes to Completed. The workflow then stores the signed document back in Salesforce.My requirement is:A document is generated/sent from Salesforce through DocuSign. The recipient signs the document. Once the DocuSign envelope status becomes Completed, I want to automatically retrieve the signed document. The signed document should be stored as a Salesforce File (ContentVersion) and related to the appropriate Salesforce record, such as an Opportunity or Quote.I would like to understand:Is there a native DocuSign Workflow step that can directly save the completed/signed document into Salesforce Files? Is using the DocuSign Workflow + Salesforce/API approach the recommended solution? Can this be handled automatically through the DocuSi

Hi guys I am developing Send Envelope Programs on SAP system we using docusign API and My client wants to automatically send purchase orders, contract terms, and quotations to their supplier representatives with each document attached. These attachments are stored in SAP as base64-encoded data. My client wants to use anchor-based signing for purchase orders, and initial-based signing for the remaining contract terms and quotations, placing initial signatures at both ends of the documents for the purchasing manager and the supplier's seller. (I will only use inline Templates ) I developed the program using signHere tabs for the anchor method and initialHere tabs with specified positions for the initial method, but I received the following message:"The Envelope is not Complete. A Complete Envelope Requires Documents, Recipients, Tabs, and a Subject Line."Could you take a look to see if my API request/response structure is wrong? I am really desperate, and I would appreciate the opinions

Hi, I'm building an integration against a developer demo account and I've run into RECIPIENT_LIMIT_EXCEEDED. I'd like to understand the limit before deciding how to move forward.The account is on the plan DEVCENTER_DEMO_RESTRICTED_JUNE2025, which I got from GET /restapi/v2.1/accounts/{accountId}/billing_plan. It was created a couple of days ago and sent around 19 envelopes, mostly with 4 to 6 recipients each. Now every send fails with:{"errorCode":"RECIPIENT_LIMIT_EXCEEDED","message":"You have reached the maximum number of recipients permitted for a single transaction in your account. Please ask your administrator to increase your limit."}It is not a per envelope problem. I reproduced it with a direct API call creating an envelope with a single recipient and "status": "sent", both as a signer and as a certified delivery, and both return the same 400. Envelopes sent earlier that same day went through fine, so it looks like a cumulative allowance rather than a per envelope cap.Three ques

While reviewing DocuSign integrations, I identified some important file size limitations that impact both the DocuSign eSignature REST API and the DocuSign Power Automate Connector. REST API LimitationsThe total envelope size (all documents combined) cannot exceed 200 MB.Each document must be less than 50 MB.For standard API uploads, individual document upload requests are subject to API size limits and large documents may require chunked upload methods.Envelopes are limited to 130 unique documents.Large or complex documents may fail during DocuSign's PDF conversion process, especially when conversion exceeds processing thresholds. Power Automate Limitations The DocuSign Power Automate connector has a known limitation where API gateway timeout errors may occur for documents larger than approximately 12 MB and/or envelopes containing more than 1,500 pages.

Hello Developers, I’m Hudson. In our integration, we create templates (name, description, upload document, add recipients, add fields, save). From the template list we copy the unique templateId from the history screen. When sending envelopes in bulk, we currently paste that templateId into a custom field (TEMPLATE_ID) and then use EnvelopesApi.listStatusChanges with options.setCustomField("TEMPLATE_ID=...") to filter envelopes. This works fine — we can import only the envelopes created from that template.However, if we don’t add the custom field at envelope creation, the envelope JSON does not expose the templateId directly. We can fetch envelopes, but we cannot tell which template they were created from.Code snippet (current approach): EnvelopesApi.ListStatusChangesOptions options = envelopesApi.new ListStatusChangesOptions();options.setFromDate(fromDate);options.setFromToStatus("sent,delivered");options.setCustomField("TEMPLATE_ID=" + templateId);EnvelopesInformation envelopesInfo =

After our Go-Live Form was approved, JWT Grant authentication to https://account.docusign.com/oauth/token consistently fails with:{"error": "invalid_request"}No error_description is returned. The identical code and request structure work without any issue against the demo environment (account-d.docusign.com).Setup:Integration Key: 9711fda1-8ceb-44d8-bb4f-1f8c54e29956 Production API Account ID: a0f9faaf-32b6-43cf-b88c-f5d5cf726596 Auth method: JWT Grant, scopes signature impersonationWhat I've already verified/ruled out:RSA keypair is registered under the app in the production account (freshly generated, single key registered, no stale/duplicate keys) User consent has been granted — visited the /oauth/auth consent URL logged in as the impersonated user, clicked Allow, and the redirect returned a valid authorization code Integration Key, impersonated User ID, and API Account ID all match exactly what's shown in production under Settings → Apps and Keys JWT payload (iss, sub, aud, scope,

Hello DocuSign Support Team,We are currently integrating with the DocuSign eSignature REST API v2.1 and have a question regarding the following endpoint:GET /v2.1/accounts/{accountId}/envelopes/{envelopeId}In our application, we use this endpoint to retrieve information about previously created envelopes. However, we have identified some cases where the request fails with errors that are not currently mapped in our application.One specific scenario we are investigating is related to the age of the envelope/signature. We have cases where the document was signed more than three months ago, and when we try to retrieve the envelope using the endpoint above, the request fails.Could you please confirm whether DocuSign has any retention, expiration, or API access limitation for envelopes or signatures older than three months?Additionally, we would like to know where we can find the official documentation for the possible errors returned by this endpoint, including the errorCode, HTTP status,

I have a question about what is considered to be “best practice” for the use of service accounts connecting to integrations.  Our company is starting to request more external application integrations with DocuSign.  The few are connected currently each have their own service account created and given an exception to bypass SSO with admin privileges. I see this becoming more of a burden since accounts require an email address and a mailbox must be configured to receive external mail for verification of any edits to that DS account registered to the email address.On the flip side, I also feel that it is less secure to have 1 service account for connecting all integrations.How is this being managed elsewhere?  Thanks for any feedback!

Hello DocuSign team,We are migrating our eSignature integration from Adobe Sign to DocuSign and have encountered a limitation with automated recipient reminders.Our integration uses hybrid signing. Each signer is created with:A clientUserId deliveryMethod: "email" embeddedRecipientStartURL: "SIGN_AT_DOCUSIGN"This allows recipients to receive the initial signing email while also letting them open an embedded signing session from our application using the Create Recipient View API.We configure envelope reminders through the notification.reminders properties, but understand that automated reminders and expiration notifications may not be sent to this type of embedded/hybrid recipient.Could you please confirm:Is this expected behavior for recipients using clientUserId and embeddedRecipientStartURL: "SIGN_AT_DOCUSIGN"? Is there a supported way to enable automated reminders while retaining both embedded signing and the initial email invitation? Is there an API-supported alternative for perio

Hi,After mapping signature fields in the forms in Keystone to Docusign, we are able to submit forms from Keystone to Docusign without having to check the Suspend On Start checkbox in keystone before submitting to avoid the SOAP error. The form automatically submits, but only the primary gets notified. The joint does not get notified. Has any one else faced this issue?