Developer

Environment- Demo (developer) account b5fe314e-fdf1-4821-893f-5ce7dac2d8fc, integration key a6aa342b-4222-4dc9-9fb0-062ffae667dd- Account settings report signingUiVersion: "2", betaSwitchConfiguration: "mandatory"- Envelopes created from a server template; signer is an embedded recipient (clientUserId set, authenticationMethod: "none", no IDV/KBA/access code)- Docusign JS from https://js-d.docusign.com/bundle.js, loadDocuSign(integrationKey) → signing({ url, displayFormat: 'focused' }) → mount(...)- Chrome, host page http://bmw.localhost:8082 (local dev)Recipient view request{  "returnUrl": "http://bmw.localhost:8082/vdr/folders/…",  "email": "…", "userName": "…", "clientUserId": "…",  "authenticationMethod": "none",  "frameAncestors": ["http://bmw.localhost:8082", "https://apps-d.docusign.com"],  "messageOrigins": ["https://apps-d.docusign.com"]}What happensUntil 20 Oct 2026 this worked: the focused view loaded and we received ready / sessionEnd: signing_complete (e.g. envelope c3e620

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.

Hello,We are developing a SaaS application in Japan that uses embedded signing (focused view) with the eSignature REST API. We are not a Docusign partner.Our planned setup is as follows:- Each customer has its own paid Docusign account.- Each customer creates its own integration key in its own developer account, and later promotes it to its own production account.- We use JWT Grant. We hold one RSA key pair (the private key is stored in a cloud key management service and never leaves it). Each customer uploads our RSA public key to its integration key ("+ Upload RSA"), and grants consent for a dedicated, non-admin sending user.- Our application then sends envelopes from the customer's account as that user.Our questions:1. Classification: When the customer promotes this integration key to production, which integration classification should the customer select, "Private custom integration" or "Third-party integration key"? We understand the classification cannot be changed after review o

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

Hi, I am working on setting up an integration with Docusign for Salesforce, the last thing I did was update the token, then I tried to send an envelope and got the error message:  The specified Integrator Key was not found or is disabled. Invalid account specified for user” in a demo account.Checked in salesforce that integration key is matching with integration key is matching DocuSign account integration key. The below url I am using is this, please advise. Thank youDocusign Account URL https://account-d.docusign.com/oauth/token

Hello DocuSign Community Team,I'm experiencing a problem with Developer/Demo account registration.My existing DocuSign eSignature free-trial account works, and I can sign in successfully. However, I have repeatedly tried to create a separate Developer/Demo account, but registration fails.I'm also not receiving password-reset emails, so I cannot determine whether a Developer account already exists for my email address.I've tried multiple registration attempts and checked my spam and junk folders without success.Could a DocuSign Community moderator please help investigate whether my Developer account registration is blocked, incomplete, or already associated with my email address?I need an authorized Demo environment to test my integration without consuming the three envelopes remaining in my live trial account.I'm happy to provide my email address and screenshots privately to a moderator.Thank you for your help.

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?

I don’t know who’s brilliant idea was to mash all the categories together so we no longer had separation of completed, in progress, deleted and void.  I have a high volume of documents going out everyday, it makes it frustrating and confusing as to what has been completed and what is still pending.  So much so, that I am requesting that we look at another format to send documents out for completion and signature.

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!

Since early October 2026, embedded signing with focused view fails on our demo account. The signer sees "This content is blocked. Contact the site owner to fix the issue." inside the focused-view iframe. The browser console shows:Framing 'https://demo.docusign.net:7802/' violates the following Content Security Policy directive: "frame-src 'self' https://docucdn-a.akamaihd.net/ https://apps-d.docusign.com https://demo.docusign.net ..."Nothing changed on our side: the same code that worked in September fails now, and displayFormat: "default" still works with the same envelopes, so the integration key, recipient view request and frame settings are valid.What we foundWe reproduced it with plain HTTP requests, outside our app and outside any browser. docusign.js (0.0.61, widget @embedded/signing-ui 1.0.221) appends platform=focused to the recipient view URL. With that parameter, the redirect chain ends like this:demo.docusign.net/Signing/MTRedeem/v1/... → account-d.docusign.com/managed_toke

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

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

We have created an external app for Connected Fields. The test calls (getTypeNames, getTypeDefinitions, verify) all pass successfully, but when we try to use it on an actual document, we cannot find the field and we cannot use it for verification.Do we need to submit the app to Docusign for review in order to test it on a document? The app is configured as Private distribution, and we don't want it to be public — we just need it to work for our own account.Any guidance would be appreciated.Thank you

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

Hello Team,I need to integrate DocuSign's signature and editable text functionality into a React Native application. I haven't found any tutorials, guides, or SDKs to help implement this. Could you please provide guidance on how to achieve this functionality in our application?

Getting error: JSON heap size limit exceeded while uplaoding document of 4.3 KB from Salesforce: At this line:                 myEnvelope = dfsle.EnvelopeService.sendEnvelope(myEnvelope, false);, this error is returned . Please suggest 

WE have installed the Docusign Sharepoint Site Edition to a test Sharepoint site. When we try to connect this to the developer docusign admin portal via "Manage Docusign Administration Settings" in the SharePoint document library, it goes to the production link (https://account.docusign.com/oauth/….) not https://account-d.docusign.com/ which is the developer docusign portal. With this how can we grant consent a docusign developer environment to a sharepoint site? 

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

Summary-------When a signing session is embedded with docusign.js, the "Electronic Record andSignature Disclosure" dialog's Print button does nothing. Download in the samedialog works. The browser blocks the print call because the iframe that rendersthe signing document is sandboxed without allow-modals.Environment------------ docusign.js v0.0.61 (js.docusign.com/bundle.js and js-d.docusign.com/bundle.js)- Embedded wrapper: @embedded/signing-ui 1.0.208- Classic view and displayFormat: "focused" both affected- Chrome 152 on macOS (also reproduced on Chromium 147)- Reproduced on demo; the identical iframe sandbox attribute ships in the production bundle, so production is affected tooSteps to reproduce------------------1. Create an envelope with an embedded signer (clientUserId set).2. Create a recipient view with frameAncestors/messageOrigins for the host page.3. Mount it: DocuSign.loadDocuSign(apiKey).then(ds =>   ds.signing({ url }).mount('#container')).4. In the consent dialog, cli

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