Skip to main content
Newcomer
August 24, 2026
Solved

Does the Starter API plan support embedded signing (clientUserId + EnvelopeViews::createRecipient)

  • August 24, 2026
  • 3 replies
  • 41 views

Hi,

  We're currently building on a developer (demo) account and we're about to
  purchase a production API plan. Our volume is ~40 envelopes/month, which matches
  the Starter plan. Before buying, we need to know whether Starter supports the
  embedded signing flow our integration depends on.

  What we need is specifically these two API calls:

  1. Creating an envelope where a signer has `clientUserId` set (so Docusign does
     not send its own signing email to that recipient).
  2. Calling EnvelopeViews::createRecipient
     (POST /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/views/recipient)
     to obtain a signing URL, which we then serve from our own application.

  We are NOT asking about PowerForms or Web Forms — only the REST API calls above.

  On our demo account this works: the envelope is created (HTTP 201), the recipient
  view returns a URL (HTTP 201), and a second call returns a different, single-use
  URL. But demo accounts have every feature enabled, so that tells us nothing about
  the Starter plan.

  The reason we're asking is that the two sources we found contradict each other:

  - The developer plan comparison page (https://ecom.docusign.com/plans-and-pricing/developer)
    lists "Embedded Signing" as included only in the Enhanced tier, and NOT included
    in Starter, Intermediate or Advanced.
  - In this thread (https://community.docusign.com/esignature-111/embedded-signing-plan-22694)
    a moderator states that "if the embedded signing you mention is only via API,
    it is available in all plans", and that the plan restriction applies to
    PowerForms and Web Forms.

  So, three questions:

  1. On a paid Starter API plan, does EnvelopeViews::createRecipient work for a
     recipient with `clientUserId`, or does it return ACCOUNT_LACKS_PERMISSIONS?
  2. Does the Starter plan support the `suppressEmails` property at the recipient
     level?
  3. Does the Starter plan allow configuring Connect keys (HMAC) so we can validate
     the X-DocuSign-Signature-1 header on webhook notifications? On our demo account
     /connect/keys returns errors.

  If any of these requires a higher tier, which is the lowest plan that includes it?

  Thanks!

Best answer by Koll.Klienstuber

@Gu1d0 For all three questions my input would be that the features will be included and should all work correctly in production. 

A general note is that if you’re using embedded signing and setting a clientUserId, the suppressEmails properties shouldn’t be also needed since setting a clientUserId will suppress the emails from Docusign. 

If you run into any issues during the build out in production I’d suggest a formal case with Docusign support. Support can assist if any features need manual enablement. 

3 replies

Docusign Employee
August 25, 2026

@Gu1d0 For all three questions my input would be that the features will be included and should all work correctly in production. 

A general note is that if you’re using embedded signing and setting a clientUserId, the suppressEmails properties shouldn’t be also needed since setting a clientUserId will suppress the emails from Docusign. 

If you run into any issues during the build out in production I’d suggest a formal case with Docusign support. Support can assist if any features need manual enablement. 

Gu1d0NewcomerAuthor
Newcomer
August 28, 2026

We use embedded signing (recipient with clientUserId + EnvelopeViews:createRecipient) on a developer account and
plan to move to a paid Starter API plan. The signing URL returned by createRecipient expires after ~5 minutes and
can only be used once — we verified this on demo. Two questions: (1) Is this behaviour the same on production
accounts, or is it specific to the developer sandbox? (2) Is there any account setting, plan feature, or API
parameter that returns a longer-lived signing URL suitable for embedding in an email we send ourselves (i.e.
without Docusign sending its own notification email)? Thanks.

Docusign Employee
August 28, 2026

@Gu1d0 Yes the 5 minute lifespan of the embedded signing URL is the same in both production and demo accounts. 
No settings exist under the admin menu to extend the time of this URL. 


“The returned URL can be used only once and expires after 5 minutes. Do not store or email the returned URL.”
Reference:  https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopeviews/createrecipient/

Based on our documentation we do not suggest storing or emailing the URL. If needed a work around could be to send your own custom email but you’d need to build out a process that for example has a button in the email or a link and when clicked it redirects over to some server you control that can then trigger the generation of a new URL and display it to the end user at that point. 
Otherwise if you did send the link via email, signers would need to act on that email within five minutes or else it would expire.