I would like to use the REST API to get a URL to open the sender view:
curl --request POST 'https://demo.docusign.net/restapi/v2/accounts/001122/envelopes/33fef057-1111-1111-8e81-5d93739ae4fd/views/sender' --data '{}' -H 'Accept: application/json' -H 'Authorization: bearer xxxxxxx=' -H 'Content-Length: 2' -H 'Content-Type:application/json'
Response from DocuSign:
{
"url": "https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=888db3ea-1e85-4860-a8e5-e9b37f38d769&DocuEnvelope=29fae057-9213-4485-8e81-5d93739ae4fd&send=1"
}
In our application, I would like to create an envelope in the "created" status with default values and then open the sender view so that the user can complete the envelope and send it.
The end user is not supposed to know the credentials for the authenticating user that I am using to create the envelope and to open the sender view: the url returned by the API contains a token that should work for some minutes.
I have implemented this solution and everything works, but there is something that I was not expecting. I thought that the url returned could be used only to execute a single operation (to send the envelope), but it seems that the user has complete access to the account as if he/she has executed a login.
Is there a way to limit the access just to the sender view for the given envelope?
Thank you,
Marco
Using the embedded Sender view (or the embedded Correct view) will always grant the user (sender) the same access to that DocuSign account as they would have if they logged into the console directly with the credentials supplied in the API request header. i.e., even though they are initially taken directly into the Envelope that the API request specifies, there's nothing to prevent them from navigating outside of that Envelope to other areas of the DocuSign console, where they'll have full access to the account to view/send/delete Envelopes, etc.
I had a similar requirement while using the embedded sending and signing using Docusign APIs. If you want to customize the sender view and restrict him to access the other docusign features of his account, you can look into branding. As an admin user you can edit the branding details of a docusign account to enable and disable certain options like "Go Back" to dashboard options.
Refer to below link for more details,
https://10226ec94e53f4ca538f-0035e62ac0d194a46695a3b225d72cc8.ssl.cf2.rackcdn.com/quick-start-account-branding.pdf
Related
I'm using a service account to send an envelope on behalf of another user. Using the API, I'm then creating an envelope in the "created" status for manual tab placement. Once I get the EnvelopeSummary back from the DocuSign API, I'd like to create a URL that I will send send back to the "send on behalf of" user so he/she can easily begin to place tabs.
I've looked into using the CreateSenderView/CreateConsoleView methods, however I don't know the AccountId/Password of the "send on behalf of" user nor do I want to use their information. Instead, I'd like to redirect the user to DocuSign where they can login and then after login, be redirected to the envelope.
I've also looked into creating my own URL from the envelopeId:
string envelopeId = "1ddff790-ad2d-4fb6-87c2-4b5e449898c9";
string redirectUrl = "https://appdemo.docusign.com/prepare/" + envelopeId;
This appears to redirect the user to the envelope if they are logged in, and if not, they will be prompted to login and then redirected. This is the functionality I am looking for, however, I'd like to use the API to generate this URL if possible since I'm not sure whether the referenced URL will remain static over time.
Any ideas?
If you haven't already done so, I'd suggest that you review DocuSign API documentation for the Send on Behalf Of (SOBO) feature. As the documentation describes:
The SOBO feature can only be used when both users are members of the same DocuSign account.
You (your application / UI) must collect username and password at least one time from the user whom you're sending on behalf of -- because you need their username and password in order to obtain an access token that can subsequently be used to submit API requests on their behalf. Since tokens do not expire (and are valid even if/when the SOBO user changes their password), you only need to collect username/password one time from the SOBO user, then use those credentials to generate an access token which can be used indefinitely to send on their behalf.
I would not recommend using the envelopeId to create your own URL, as this functionality is not supported by DocuSign -- even if it works today, there's no guarantee it'll continue to work in the days ahead.
Finally, issuing a Create Sender View request (using SOBO) will return a URL that can be used to launch the sender (tagging) view for the specified Envelope. Do note, however, that the URL will expire after a short period of time (5 minutes?) -- which means that you should not issue the Create Sender View request to retrieve the URL until the user (sender) is ready to tag/send the Envelope. For example, issuing the request to generate the URL and then emailing that URL to the sender would not be feasible -- since there's no guarantee that the user (sender) would open the email and click the link to launch the sender view before the link expires. Instead, you should provide the sender with a way to indicate to your application when they are ready to tag/send the Envelope, and then issue the Create Sender View request at that time and redirect the user (sender) to that URL immediately upon receiving the URL.
Update (Legacy SOBO)
#EnterTheCode -- thank you for the clarification that you provided in the comments. Your understanding of Legacy SOBO functionality is correct; that is, it does not require that you obtain an access token for the SOBO and it does not require that you obtain the SOBO user's password. You can simply include the X-DocuSign-Authentication request header to specify the username and password of your "service account", the integrator key, and the email address (or user ID) of the user whom you're issuing the API request on behalf of.
(Side Note: Although Legacy SOBO is apparently still supported, it's no longer recommended for service integrations. Instead, DocuSign now recommends this approach.)
Putting SOBO authentication technique aside though, the rest of my original answer still applies to your scenario. That is, to retrieve a URL that can be used to launch the sender (tagging) view for the specified Envelope, you'll need to use the Create Sender View operation. And, as mentioned previously, the URL that's returned by that operation will expire after a short amount of time -- so be sure to account for that in how you design your implementation.
Why you want to use SOBO, if you want someone to update the envelopes then you can add that user as first recipient in the envelope with recipienttype as "Allow To Edit" ("editors" in API term). With recipient type as "Allow to Edit", DocuSign will send an email to the recipient and then recipient has to login into his DocuSign account, after that user will be able to access the envelope and can do the editing of the envelope like doing tagging of document with DS Tabs, adding, removing recipients etc, in same way as "Sender View". In this way you don't need to create a webpage for embedded sending view.
When using the Docusign API (in my case, via the Sandbox/demo env), in the signing view at the top of the screen it displays the name & company of the user account that was used to authenticate with the API.
However, because this is embedded signing from my app, I would have thought we'd only have one user account - for the app. So I want to change what appears at the top there - the information on the sender of the envelope. Either to be the user account that exists in my app that created the envelope, or just to state what company sent the document.
Are there options on the API to do this? I can't see any reference to anything like this in the envelopeDefinition JSON structure in the REST API docs.
You can use the DocuSign SOBO - Send On Behalf Of Functionality
The Send On Behalf Of feature permits automated sending through the API by one account user on behalf of another account user.
More information here
I'm using the REST Docusign API v2 and I have some problems (seems a Docusign bug, but I'm unsure).
I have a website that has a button to view a Docusign document previously sent by us, this button creates an URL and performs the "Post Sender View" resource call, which states:
Post Sender View
This provides a URL to start the sending view of the DocuSign UI. This is a one-time use login token that allows the user to be placed into the DocuSign sending view.
Upon sending completion, the user is returned to the return URL provided by the API application.
The idea of this process is to show the Docusign GUI to view to document and perform some basic operations.
This is done correctly, but the problem I have, in such Docusign view there is a button, it says "Other actions" and after clicking on it, the option "Clone" is presented.
When clicking on "Clone", the session is expired, so the user is unable to perform any action. The message is:
Session Ended
Your session has expired due to an extended period of inactivity. To restart the DocuSign session click the link in the email that initiated the session.
For help: support#docusign.com
So, the point here would be: is there some fix for this? I'm doing something wrong?
I know the documentation says "This is a one-time use login token that allows the user to be placed into the DocuSign sending view"; but, if you decode to click the "Close" button, the session remains open and the user is able to work as usual.
Many thanks in advance.
We have an application that we currently open the DocuSign console in an IFrame. The issue is that currently we are having to open a new tab, log on to DocuSign and then the user can see the console in the Iframe with documents. What is the most common way people are using to automatically logon to DocuSign through their applications ? I see an SSO documentation but it says that it looks at the persons email domain to authenticate them.... our users will have many different email domains.
Your application can use the API to get the console view for the user. The session will correspond to the user credentials in your API request and will skip the logon step. From that API call you get a URL back that you can embed in the iFrame. E.g.: POST to https://demo.docusign.net/restapi/v2/accounts/55555/views/console and you get back a URL like this:
{
"url": "https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=00000000-0000-0000-0000-000000000000&accountid=00000000-0000-0000-0000-000000000000"
}
Edit: If you need the "sending view" (sometimes called "the tagger") for an envelope then you can POST using a URL like this:
https://{server}/restapi/{apiVersion}/accounts/{accountId}/envelopes/{envelopeId}/views/sender
e.g.
https://demo.docusign.net/restapi/v2/accounts/12345/envelopes/f6e755d3-bbcf-44e5-b276-8ae626f97220/views/sender
I'm able to create an envelope with the API which returns the envelopeId which looks like:
13f23354-7eee-41d3-897a-c1353a1e465c
When I navigate to docusign in my browser and open the envelope the url is:
https://na2.docusign.net/MEMBER/EnvelopeSetup.aspx?ti=ad05458248c54654a16a54195bf72ffe
I don't see what that "ad05458248c54654a16a54195bf72ffe" id is. I've tried every envelope API in the documentation (many don't make sense, but I tried them anyways):
/accounts/{accountId}/envelopes/{envelopeId}
/accounts/{accountId}/envelopes/{envelopeId}/audit_events
/accounts/{accountId}/envelopes/{envelopeId}/custom_fields
/accounts/{accountId}/envelopes/{envelopeId}/email_settings
/accounts/{accountId}/envelopes/{envelopeId}/notification
/accounts/{accountId}/envelopes/{envelopeId}/templates
But that id isn't anywhere.
Is there a way to retrieve that URL id? and/or is there another way I can get the url for the envelope?
The ID that appears as part of any URL when you're using the DocuSign web console is an internal ID -- you cannot use it with the API in any way. The Envelope ID value that DocuSign returns in response to the "Create Envelope" API request is the ID that you'll want to use with any API request that requires an Envelope ID.
It's not exactly clear to me what you mean by "[url for] managing an envelope" -- but I'd suggest you explore the following operations in the DocuSign REST API Guide:
Post Envelope Correction (page 146)
Modify or Correct and Resend Recipient Information (page 137)
Post Sender View (page 149)
(I'd guess that "Post Envelope Correction" is likely what you're after.)