I am getting information from client through internal portal and sending the request for envelope creation (along with details from client) from Server.
Everything is fine.
But the problem is with AUDIT history.
in the Audit history the IP address information is all SERVER information as server is the source for sending REST request.
But in my case Client is the one who provided the details.
I am trying to see if I can send the CLient IP address in the REST API so that it will inline with the actual events.
is this possible or reference to any achievable way is greatly appreciated.
Are you referring to Embedded Signing?
All entries are not changeable.
The Envelope is being created by your server, so you will not be able to change that.
You'll have the client's IP when they enter their signature.
See screenshot below for the web version of this info for a test document.
Unfortunately, I don't think it's possible to set the Client IP address via REST API. The information recorded to the Envelope Audit Trail is based upon data collected by DocuSign throughout the envelope's history. The fact that DocuSign records data exactly as it truly occurs is what gives credibility to the Audit Trail information, and therefore I wouldn't expect DocuSign to ever allow any of the Audit Trail properties to be set explicity via an API call. (Doing so would open the door to fraud, as an integrated application could use the API to falsify information in an envelope's audit trail.)
Related
I am an admin account user and to get insights from data I need to pull the details of all the envelopes from all accounts. The similar thing is what a report provides in Docusign dashboard but I need the list of recipients as well. Can anyone please help me. Thanks.
Listing envelopes sent by your users: Envelopes::listStatusChanges
I think that call may cover envelopes sent by anyone in your account (if the accessToken represents a user with admin privileges). But I'm not sure.
If it doesn't then you can loop through the account's users.
Tracking who has received an envelope through their DocuSign account is done with the Folders::listItems API call. You may need to list both the Inbox and Deleted folders. You also need to check that the person signed the specific envelope vs receiving it for some other reason (cc, certified copy, etc).
Finally, an alternative if you have higher volumes is to purchase the DocuSign Report Feed product (see note below). It will send you DB table dumps about your account activity on a regular basis so you can do your own reporting on DocuSign activity. It is the best way to have full access to report data. Ask your DocuSign contact for more info.
Note: I'm not sure of the exact name for the reporting product.
This can be done if you install DocuSign for Salesforce managed package and use Connect feature in DocuSign. Configure your webhooks to create DocuSign Status and DocuSign Recipient Status records for each send. Any DocuSign objects or custom object can be used in the Connect configuration, after selecting objects, select which events you want the results to be pushed back to Salesforce.
Use a parent object to store envelope details and child object for the recipient data. Use Envelope Id to relate the child records to the parent. Eventually, you will be able to build various reports on Salesforce.
More info here: https://support.docusign.com/guides/dfs-admin-guide-ds-connect-for-salesforce
I am trying to push notifications from DocuSign Connect to our webhook.
Is there any way to provide a header named Appkey and a given value when DocuSign connect pushes notifications to the provided webhook URL?
Our webhook requires a header named AppKey to access it.
Currently, I don't see any such configuration in Docusign Connect UI.
Drew is correct that custom headers can't be supplied at this time.
A possible workaround: you can supply parameters via the URL's query parameters. Eg use URL https://docusign-listener.example.com/?appkey=123
Remember that, thanks to the SSL/TLS protocol, the query parameters are NOT visible to anyone tapping the line since they are only sent after the encrypted channel is set up between the client (DocuSign) and the server (your app).
Also, if you'd like to be able to specify headers for the notification message requests, ask your DocuSign technical contact to add your organization's information to the internal ticket CONNECT-1109. Adding your information will help increase the priority of the enhancement request.
No, DocuSign Connect doesn't support custom headers.
I am trying to embed docusign on my website by using powerform. As of now I am using demo account and I am stuck with using DocuSign connect how would I create a sample connector and fetch XML data.
You don't contact DocuSign connect, it contacts you! (Your application.)
Use the Administration tool--in the Connect section you can add a subscription to Connect, including your application's url.
When an event that you're interested in occurs (eg Envelope.Complete), Connect will make a POST HTTPS request to your application. The body of the post will be the XML notification message with the details on the envelope that had reached the complete (signed) state.
Ask additional questions on StackOverflow if you have additional questions.
Note: your server (your listener) must be on the public internet so it can be contacted by DocuSign.
I have successfully implemented a system that creates documents to be signed via a template using the .NET API, and then has a DocuSign Connect listener that gets called upon the envelope being signed (right now only have Connect reporting on envelope signatures and declines). I have the option set to "Include Documents" on my DocuSign Connect settings. When I create the envelope for signature programmatically with one signer it all works - my Connect listener gets called, the /DocuSignEnvelopeInformation/DocumentPDF/PDFBytes element has Base64 data in it, and I have successfully decoded that and stored it in our doc management system. Cool. Demos well, management loves it.
However, I have noticed at least two scenarios where the /DocuSignEnvelopeInformation/DocumentPDF section isn't being returned at all:
When there are multiple signers.
When the envelope is created manually, even if it uses the same template.
I can still use the Connect response to get the /DocuSignEnvelopeInformation/EnvelopeStatus/DocumentStatuses and extract the document IDs from the DocumentStatus child elements, and then go retrieve those programmatically using the .NET API. But I am wondering why the PDF bytes aren't being consistently returned all the time? Is the above expected behavior? Am I missing something?
I would prefer to save "round trips" and just have Connect deliver all the signed PDFs to me when it calls (and yes, I have read the Recommendations for Receiving Documents section of the DocuSign Connect Guide and understand the trade-offs. Just wondering if I need to code around this issue, or what I am missing?
Hmmm. Envelopes don't get "signed," they get "sent" and "completed." See the envelopeEvents vs the recipientEvents lists in the Connect::Create call.
Currently, there is an existing issue which is that the connect daemon can miss an event if it is quickly superseded by another event. This might be what is happening when you have multiple signers for an envelope. The safest thing to do is to subscribe to all events and then ignore the notifications that are not of interest to you.
The terminal event of an envelope being "completed" will always be sent if you've subscribed to it.
Also, to make your app more bulletproof, I suggest subscribing to the Connect events via the API call (link is above) rather than depending on the human to setup up the subscription correctly. Since an account can easily have more than one connect subscription, you can track which one is your app's by using a specific name for the subscription.
Added
Just now, I created a Connect subscription for just the Envelope Completed event, for all users in my account on demo.docusign.net. As the subscription (listener) url, I used a free account from requestb.in
Using the web user interface (not the API), I created an envelope with two signers. After I completed the envelope, the requestb.in received the notification, it included:
<DocumentPDFs>
<DocumentPDF>
<Name>House architectural overview.pdf</Name>
<PDFBytes>....
as expected. So I'm unable to reproduce your problem. I suggest that you use requestb.in to double-check exactly what is being sent in the notification messages.
My company recently signed up for partnership with DocuSign to build your
signing routine into our software.
The client looking to use our software currently uses DocuSign to sign
documents and has an integration with eOriginal as the eVault for the
documents.
Based on the documentation I'm reading, when the document is sent to
eOriginal, it is removed from DocuSign.
Is that correct? My client vaguely agreed that it wasn't on DocuSign but
I'd like to verify this.
We have our own document storage system as well and while we would like
eOriginal to have the authoritative copy of the document, we'd like a copy
of the document to be stored in our solution.
Our initial thought was that after the document was signed, we would
download a copy through your API and store it on our system.
We now wonder if that document would be there.
How soon after a document is signed would be it be pushed to eOriginal?
If there isn't enough guaranteed time to pull the document down, we'd need
to possibly pull it from eOriginal instead.
If we are pulling it from eOriginal, is there any information on how that
would be identified in eOriginal.
I'm not asking for their API. I get that we most likely need to get in
contact with them but is it identified by the same envelopeID?
Please let us know any insight you can provide on this.
We appreciate your assistance
The Setup
The configuration you're using all depends on your account settings. Please contact your DocuSign Account Manager to get a better explanation of the options and pricing here.
The most commonly used combination that I see with DocuSign/eOriginal is:
DocuSign Transfers Authoritative Copy to eOriginal
eOriginal stores the Authoritative Copy
DocuSign stores a copy
As far as timing goes, the event happens when the envelope has been fully completed. It could be anywhere from less than a second up to 15 minutes, depending on how DocuSign and eOrigional's queue's look. It's normally closer to the "instant" side. But I would plan for latency between the two systems.
How eOriginal Stores Envelopes from DocuSign:
eOriginal uses EmailSubject of your Envelope for the Containter ID.
There is an additional eOriginal Custom Field Xref1 which contains your DocuSign EnvelopeId