The webhooks endpoint is visible by the group member. If the group member share the webhooks endpoint to other. If someone with malicious intent got that URL, he/she could send Actionable Message with form and send the contents of that form to endpoint that is beyond your control.
Is that will caused outsider to send many junk message to Teams?
How can I solve this problem?
Can I set the webhooks endpoint only visible by the group admin?
By definition webhooks are un-authenticated. Anyone who has the URL can send to it...just like an email message.
If the webhook is compromised, delete it. It can no longer be used once it's deleted.
Related
Using the REST API for remote signing and it's been working great for about a year now.
We have a user of our system that wants to send documents for e-signature, and I'd like to limit their access to their own documents, let them get the notifications of document completion, etc.
I know I can create additional users in the admin section but I'm not sure of where to look from there. Is any of the rest possible?
Yes, add the person as a regular (not admin) sender in your DocuSign account. They'll only be able to see envelopes (transactions) that they sent.
They can also see envelopes that were explicitly shared with them by another sender
Added: authenticate as a different person
Your API application sends envelopes by using the credentials of an account member. If this is a non-person such as "finance#yourCompany.com" then we call that a "system user."
Your question was how to send envelopes from a sender who is not an administrator. The answer is to authenticate to the DocuSign API as that person. This can be done with the OAuth JWT or Authorize Code grant flows.
Ask a new question if you have more questions on how to do this.
Is there any guidelines/recommendations for the webhook URL that I can use for setting up the event notifications?
I am thinking of using something like this - /webhook/v1/{uniqueAppID}. The uniqueAppID changes for every envelope, I dynamically construct the URL and set it to the EventNotification object while creating the envelope.
The unique app id is used to track the response from DocuSign, So if at all there is any issue in parsing the response, I would know for which envelope/app id I have got the notification.
I read that the system will retry delivery for failures only after a successful acknowledgement is received from the webhook, In my case, it will be like having multiple webhooks. Will this setup cause any issues in retrying the failures? Does setting up the url like /webhook/v1?uniqueAppID={uniqueAppID} helps?
Thank You
Great questions.
First up, you don't have to use any kind of endpoint/URL schemes. You could have them all go one place. The information that you get from DocuSign in the payload would allow you to know everything you need about the envelope and if you need additional information - you could make API calls to determine this.
However, I would agree that if you need this information, using different endpoints would give you greater flexibility. Also, if it's different apps, you could, in theory, deploy them separately and thus the endpoint code would change without affecting other apps.
As for retry, this is done in case DocuSign does not get a 200, 201 or other HTTP response that's positive from your web server. If DocuSign gets 401 or 500 etc. If no response is received, DocuSign would retry again in 24 hours.
That should not impact your decision about the design.
One last thing to consider, you cannot be behind firewall/VPN etc. Highly recommend you consider a public cloud provider (Azure, AWS, Google) for your app to avoid networking issues.
When using envelope-level webhooks, the triggers and destination URI are embedded into that envelope. After the envelope enters a predefined state like 'sent' or 'completed', the writeback targets the URI that you provided. Unless you intentionally change this, it should remain envelope-specific.
This is different from our typical Connect setup, which would have a single URI per listener and envelopes writebacks would be directed to the listener URI at the time they're processed.
Any subsequent failure or retry attempts would follow the standard guidelines outlined here: How to get docusign webhook to retry on failure?
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 have a web service that creates Docusign envelopes with a PDF that needs to be signed. On my test environment, after the envelope gets created I query for the envelope status, as well as the recipient status. When using the API call, the respondents with bad email addresses have the status "autoresponded".
Now on my Docusign Connect implementation, I have two separate routes that get hit. One for when the email gets successfully sent or if the request is completed, and another one specifically for email delivery failures. When I had a single route, none of the recipients were marked as "autoresponded" like the API call returned (the API call result ends up being returned before the Connect implementation gets hit by Docusign).
After splitting them apart, I expected the email delivery failure-specific route to have the correct signature status. Unfortunately when this route gets hit, all recipients have the status of "Sent", regardless if their email is valid or not.
I'd contacted Docusign a while ago and their response was the number of events a single Connect implementation was listening for. By that assumption, this delivery failure-specific route should be getting a status of "autoresponded" like our API call is receiving, which doesn't seem to be happening. How can I get the Connect implementation to return the correct recipient statuses?
Every time I've opened a support ticket on their website, the corresponding account can no longer log in, meaning it's always a one-way communication to their support team. Has anyone gotten around this issue before?
My thought is that if the email failure route gets hit, flag that account as having a bad email address for one of the recipients and force the user to log into their accounts to see the actual status. Another option would be to query the API for that envelope's status, however I feel like a lot of delivery failures could easily trigger the max number of API calls.
Posting an answer, the original poster figured it out in the comment, but here is the answer for everyone else per Ricky Story:
"Return Recipient Auto Responded Status in Connect/API" that DocuSign Support should be able to enable.
To do that you would need to contact the DocuSign Customer Support and request them to enable this option.
I'd like to set up a part of my site as a 'restricted' area that you need to pay via Paypal to access. Can anyone offer some advice on how to do this? Ideally I'd like to have a 'subscribed' value in my database that I can check when people attempt to access the site to check if they have subscribed. I've started looking into IPN which might be the way to do it?
Many thanks
I'm working on a new store that will integrate with PayPal. From what I've read, yes, IPN seems like the way to do it. Have a Subscribe button, and when you receive an IPN message that indicates successful payment, update the user's 'subscribed' field. I think IPN also sends a message when their subscription runs out.