Hi developers,
We're sharing advance notice of a change to the URL domain returned by the createRecipientView and related EnvelopeViews endpoints. For most integrations no action is needed, but you should verify your application can handle longer URL strings.
Details and common questions are below. For additional information, you can check our release notes or reply to this thread.
What's changing?
The URL returned by createRecipientView and related EnvelopeViews endpoints is moving to a new domain.
Instead of the older docusign.net/Signing/... style links, these endpoints will return URLs on apps.docusign.com/authenticate -- the existing entry point where signing sessions live today.
Are my API base URLs changing?
No. Your request endpoints (na2.docusign.net, na3.docusign.net, etc.) are not changing. Only the URL returned by the API is changing.
What do the new URLs look like?
| Environment | Old Domain | New Domain |
|---|---|---|
| Demo | demo.docusign.net | apps-d.docusign.com |
| Production | www.docusign.net | apps.docusign.com |
Do I need to change my code?
If your integration takes the returned URL and immediately redirects the signer to it, you likely don't need to change anything. However, the maximum URL length will increase up to 4,000 characters, so you should verify that your application can handle and redirect longer URL strings.
Is the signing experience changing for my users?
No, the signing ceremony is the same. This is a routing change, not a functional one.
Has the URL TTL (time-to-live) changed?
No. The returned URL remains valid for 5 minutes, same as before.
When is this rolling out?
| Environment | Timeline |
|---|---|
| Demo | Mid-July through Mid-August 2026 |
| Production | Late August through Late September 2026 |
Do I need to do anything to opt in?
No, this rolls out automatically to your account.
I have another question.
If you have questions or encounter issues during the transition, please reply to this thread.
Back to Docusign.com

