Is it possible to have different webhook endpoints for different apps in docusign? I don't seem to be able to set the app in the configurations for webhook
I think, you can try using DocuSign connect, where you can give two different webhook links for different apps. Docusign connect is also more secured.
https://support.docusign.com/en/guides/ndse-admin-guide-connect
Not through the web console - Account-level Connect configs are mostly all-or-nothing (although you can enable/disable them by sending user).
If you want one application's envelopes to write to one endpoint and another's to another, you need to set up both applications to include EventNotifications in the envelope definition.
EventNotifications are effectively a Connect configuration embedded into the envelope. They are documented in the schema of the CreateEnvelope call (https://developers.docusign.com/docs/esign-rest-api/reference/Envelopes/Envelopes/create/) and code examples are available here: https://www.docusign.com/blog/dsdev-common-api-tasks-add-a-connect-webhook-to-your-envelopes
You can create two or more webhook "subscriptions" for a single account. One subscribing URL can be used for one of the apps, the other for a second app.
However, both URLs will receive all the notifications (for both apps).
So you need a way for both URLs' servers to only pay attention to the notifications for their own application. Easiest way is to set a metadata envelope-level field in the envelopes. This can be done either via the Envelopes:create method or set within a template.
Related
Use Case -
We are an origanization who helps universities manage the sport activities and contract of their students. We are planning to integrate docusign in our system both web and mobile app. One feature that we need is the information regarding the created templates, is there a way to get notified about templates via webhooks(like when it was last used, or created).
So, webhooks may not be suitable to know when a new template is created, because currently the webhook is tied to an existing object, and the object is not yet there, so it's a catch22.
What you can use instead is the DocuSign Monitor API. It's a different approach, but using this API, you can get data about anything that happens in the DocuSign account, including templates.
You can make raw API calls, or use the Monitor SDKs for one of six languages.
I'm not 100% on this but one approach would be to use folders. Put your templates in a named folder and use the listStatusChanges API with a folder id as a query parameter (https://developers.docusign.com/docs/esign-rest-api/how-to/list-envelope-status-changes/)
You can also select "Folders" in the "Include Data:" section of your DocuSign Connect webhook and filter for the folder(s) you're looking for.
Helpers, I want to use Connect services with my DocuSign rest APIs integrated website. Could anyone help me out, Where can I get these in the GitHub? Basically the need is:
Once the document is fully executed, it will be routed via DocuSign connect to a folder which aligns with the name of the employee. This will require work on both the elected system as well as the DocuSign API to configure.
No problemo! These days, I suggest using an intermediate PaaS to queue and deliver the webhook notifications to your application which can live safely behind your firewall.
Here's a blog post on the technique. Note that we have PHP example software for this technique.
Once your PHP app is notified that an envelope is complete (fully signed), just download the documents from DocuSign and store them in your file system. Easy Peasy!
In my testing, I used a web proxy to get thru the firewall here so I could send envelopes. Now I will no longer be using the proxy. Do I need to log in for each web request ( like getting the templates, creating an envelope, etc )? The way we will use docusign is like this: a client consultant will see 3 documents that need to be sent to user X. So they will create an envelope with the 3 documents and send it out. They only need to connect to Docusign for a few rest calls and then they're done. The client consultants will connect to Docusign a few times a day, maybe no times a day if there are no documents to send. I'm assuming that I should go out and see if I can connect to Docusign without a problem before attempting to send out an envelope. What workflow are other people using in similar situations? Thanks for any advice.
I think a short answer here is that every API call you make requires a form of authentication provided, whether it is username/password or an oauth token passed in the appropriate x-header in your API request. I doubt your proxy was adding this on your behalf, so IMO I do not see what you will be gaining/losing by removing the proxy.
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.
We are doing an integration with DocuSign where users can submit documents stored in our system to DocuSign to get the documents signed. We have the DocuSign Connect feature working in our demo account. We can process messages from DocuSign successfully.
We were concerned that getting users to add a Connect Configuration themselves may be too challenging for some and it will be error-prone.
I see now in the documentation that it is possible to automatically get DocuSign to push notifications by passing the information in the EventNotification attribute when we call createEnvelope. Is this an acceptable way to get push notifications from DocuSign? Will this cause issues with getting the integration certified?
Is there any other way to get Connect configured easily in customer accounts?
This is an old question, but I wanted, for the record to have answers, since it's important to anyone who may be reading this.
We see now in the documentation that it is possible to automatically
get DocuSign to push notifications by passing the information in the
EventNotification attribute when we call createEnvelope. Is this an
acceptable way to get push notifications from DocuSign?
Yes, it is. It's a very good way in fact, to reduce polling and make your app better. We highly recommend that you use EvenNotification and sign-up for events going through a webhook to your app such that you can handle them in your code only when they occur, instead of polling DocuSign APIs repeatedly.
Will this cause issues with getting the integration certified?
The opposite is true. If you use polling you may have issues being certified. Using connect events with a webhook is one way to avoid the need for excessive polling which could cause issues with the certification.
Is there any other way to get Connect configured easily in customer
accounts?
You can configure connect like you suggested using EventNotification at the envelope level. This approach works well for ISVs since you don't need your customers to have admin access to their accounts.
The other option is account-level connect configuration, which does require admin level access and there are some other limitations. This approach adds the connect webhook for all envelopes in the account. So it may or may not be better, depending on your scenario.