How can I set up my API in a way that completion emails contain the combined PDF instead of two separate files (signed document + certificate of completion)?
I tried searching in the settings but couldn't find it. Do we need to specify it somehow in the JSON file?
This is not possible. CoC (Certificate of Completion) is always separate in the emails.
You can submit your feedback to DocuSign in this matter (and any other matter) by going to https://feedback.docusign.com/
Related
I'm working on creating a gateway using the docusign API.
And i wonder if it's possible to add dynamically signers through a form.
I have tried many technique but none of them have worked.
For me one of the solution would be to add the signers with their parameters to a list in the model and use this list as a parameter of the controller, but i don't know if the Api have special limitation.
I will share you my code if you need it !
Thank you for your responses.
I think you want to do bulk send, but not sure.
Bulk Send is a feature where you send the same envelope (set of documents with tags etc.) to different signers (recipients). You then set the list and the system clones the original envelope many times and sends it to each user in turn.
Code example showcasing how to do this in 8 different languages can be found here:
https://developers.docusign.com/docs/esign-rest-api/how-to/bulk-send-envelopes
I have a standard custom connect setup that has been working really well for us. We now want to store the signed document in our app. So I go and edit the settings and click on Document PDFs in the include section. However, there is no change in the XML that is in the callback. I would have assumed that the base64 encoded document would be there just like when I send it.
Is it somewhere else? Ho do I get a copy of the document once ALL recipients have signed?
Thank You.
Sorry you're having this problem. I suggest creating a new Connect subscription/config and sending it to https://www.webhookapp.com/ as a test.
If the payload is as you expect, then update the url to be your webhook listener.
It could also be that you're not parsing the xml fully. The documents are included at an initial object level within the xml.
I do know that if you request the Certificate of Completion without asking for the Document PDFs themselves, it won't work. I haven't seen your problem as described though.
This is complicated but I'll try to explain. I've written an API integration in PHP. With this module installed on my website, I'm able to call a web service (on my website), pass it a PDF, and a collection of requisite parameters including a specific template ID in my Docusign account, and get back an embedded signing link, which I can then use to redirect to the Docusign signing experience for that template/document combination.
The PDF document I'm passing is the exact same PDF in the selected template, but with data filled into some of the files, whereas the version in the template is blank. In the template, various fields are defined (signature tab, date signed, SSN, etc..). These are clearly visible and correctly configured. One can verify this by going into the account and editing the template in question from the Docusign web UI.
My problem is that of the 5 templates I have configured, only one is working as expected (PDF shows up, you fill in the fields and sign, and click "Finish"... callback web hook fires delivering the finished PDF back to my server... done.). The rest show none of the configured fields signers are supposed to interact with. You can click continue, but in the left sidebar, you get the tools for adding fields to the document, instead of the pre-configured ones displaying properly in the body of the PDF.
The template that's working, was broken two days ago with the symptoms described above. I've done nothing to the account or that template and it's magically working somehow. I called tech support on Friday and they told me that occasionally templates get corrupted on the docusign server, but that was tier 1 support and I'm not sure that's a valid comment.
That's about the best I can do to describe the problem. I'm unsure what specific information I could supply to help troubleshoot this, but I'll watch the thread and react as quickly as possible.
I'm observing the exact same behavior in both dev and live environments with the exact same group of templates. The one that works in the live environment is the same one that works in dev.
List of templates: (this is for the Dev implementation)
86841739-f12d-460e-9807-23a9b90cff6b (only this one works)
6c3fd328-6f2e-4de1-a9bc-f50df7761ec2
68ce0c9e-a892-4a15-b0f5-39f28aba4588
cd4e3b6d-a8ea-4c78-a0f8-602753996743
9278c78b-f703-429a-ac62-9361bd02f54a
The above represents the 5 templates I'm testing. Only the first one works as expected. I'll add the json later this evening, as I'm out of time at the moment.
Here's the json for each of the templates (zip file):
https://ufile.io/quo3j
Problem solved. It was indeed a discrepancy between the roleName of the template and that passed to the API during envelope creation. They must be the same. If you use a template with a different roleName than the one you pass when creating an envelope, you will get the exact behavior I've described.
The solution is to edit your templates on the Docusign website, and use the same roleName for them all, then make sure that's what you're passing the API when creating envelopes.
Is there a way to restrict the documents types that a signer can upload using the signer attachment? There does not seem to be a way to do this when setting the template. I would like to prevent users from uploading exe or other binary files.
There is currently no way for you to specify which file types to restrict, however the DocuSign platform has certain restrictions already in place.
When you use the Signer Attachment tab in your envelopes only file types that are considered "documents" are allowed as attachments, since once you attach them it shows as another page. Therefore, the recipient can not attach .exes or other binary files. You should be able to confirm this through some quick tests in the demo (developer) environment.
I want to download all emails in a gmail account and also want to get the unique url which will open the exact mail in gmail, off course with authentication. I tried using javax.mail imap library but Imap probably doesn't supports anything like it.
I can use "https://mail.google.com/mail/feed/atom" gmail feeds. but won't give me entire email and it only gives unread email and I don't want to miss any email
You can do this if you are using Google Apps for Business/Education. If you are, you can access the Gmail inbox feed (Atom) by using OAuth. OAuth can also be used to access Gmail via IMAP - you can then have complete access to the IMAP server programmatically, see Gmail IMAP and SMTP using OAuth.
Google has extended IMAP to allow developers to provide a more Gmail-like experience via IMAP, see: (Gmail IMAP Extensions, X-GM-EXT-1).
The unique message (X-GM-MSGID) and unique thread (X-GM-THRID) ids can be used to produce links to Gmail messages directly - you just have to hex encode the id long (e.g. Long.toHexString(x_gm_msgId)). Your link will then need need to be in the form of:
http://mail.google.com/mail?account_id=ACCOUNT_ID_HERE&message_id=MESSAGE_ID_HERE&view=conv&extsrc=atom
supplying ACCOUNT_ID_HERE (something like user#someplace.com) and MESSAGE_ID_HERE as appropriate.
I have been working in this area and think you might find my project useful, see: java-gmail-imap.
[NB: URLs formatted as above do not work on Gmail's mobile site (at least on iPhone/Safari).]
https://mail.google.com/mail/#all/HexEncodeMessageID
replace the HexEncodeMessageID part with the ID. You get it, when you open the email in a new window (use the pop out icon in the upper right corner.
The id looks like this: search=inbox&th=1426b8f59e003aa0
I'm fairly confident this is not possible - that there is no reliable way to get the unique URL that'll lead to a single email in Gmail. I'd love to hear otherwise!
I do believe it is possible to get a URL that will lead to the Gmail thread containing the message - but you have no control over which message(s) are "expanded" in this threaded display.