Docusign eSignature API has a limit of polling 15 min in 15 minutes for requesting a unique url resources.
However in the documentation it is not explained if normal user behaviour is allowed , which is completely different from polling X in X minutes (e.g. clicking to view an envelope multiple times in a row).
Question 1
Is there a problem in Docusign if the same resource is called multiple times within 15 minutes in normal user actions?
There could be scenarios where the resource needs to be fetched much more frequently within 2 or 3 minutes, but almost 0 the rest of the day for that resource).
Common examples may be: asking for an envelope information, related entities and audit events within a short time span.
Question 2
Do all GET unique resource url have the 15 min rate limiting restrictions in eSignaturesAPI (envelopes, recipients, events, status, templates etc)?
Some documentation indicate only status related endpoints are poll restricted, other docs specify that all GET resources in the eSignaturesAPI are.
Question 3
One alternative for polling is to use Docusign Webhooks (Connect) as suggested in many articles, however to secure it with HMAC, it not possible in combination with oAuth.
The connect keys are associated with the user's account and not the client's app account (each user would have to setup their own keys, which is not feasible). One suggestion seems to be mTLS (which won't be an option).
What other ways exist to secure webhooks when using oAuth?
Wondering how other integrations have done it with the current webhook security limitations.
The reason that DocuSign cares about polling is because developers have built integrations that poll every 1 sec resulting in millions or API calls that clogs the servers.
It sounds like your integration is not doing polling.
Then all you have to do is pass go-live and you should be fine.
The last 20 API calls for your go-live review should adhere to the polling rules, make sure they are so. There's no way for DocuSign to know the intention of API calls, so the polling rule are strict, but they should not be hard for you to figure out.
Related
Good day to all,
In the context of my project, we integrated Docusign to SAP Ariba CLM (contract Lifecycle management).
We are using the esignature task in our contract workspaces.
Once all parties have signed the contract in Docusign, it takes hours for the esignature task status to move from "signing" to "signed" in Ariba. It also takes hours for the contract signed PDF to be pushed from Docusign to the contract workspace in Ariba.
I have already worked with other esignature providers (for instance AdobeSign) and the update of the signature status took 5 minutes at most.
I think we need to change the esignature status refresh frequency but i'd like to know where this would be done. In Ariba ? or in the DocuSign Account ?
Many thanks for your insights and my apologies for my question phrased with simple words. I'm functional, not technical.
screenshot of the Ariba-Docusign integration configuration
Signature status and document could be transmitted by Docusign to Ariba either through API request or a Connect configuration. You would need to verify what has been implemented.
In the 1st case, it would mean to change the frequency when Ariba makes his API call against Docusign to check the envelope status. If you are in this situation, you should contact SAP support to operate this change.
In the 2nd case, you would need to verify if Connect configuration uses aggregate or SIM (Send Individual Messages) mode. When using aggregate mode, messages are not systematically sent to the 3rd party as soon as a Docusign event occurs, but an algorithm will wait to aggregate several messages together, and could explain the delay you observe
If you are in this situation, you should open a support case to Docusign if you need further help.
The default refresh interval for syncing the task status is 120 minutes. You can create a support request with SAP Ariba to have this updated to be more frequent (the minimum is 30 minutes).
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'm using the DocuSign Envelopes: listStatusChanges API to poll DocuSign for updates to envelopes. I'm currently testing this out in the Sandbox environment. The docs say that "you are not allowed to poll DocuSign more than once every 15 minutes" but I've been testing this every 2-3 minutes and not encountering any issues here.
Does anyone know if this 15 minute limit does not apply to the Sandbox environment? I don't have a production version to test against at the moment.
The polling limit does apply to the sandbox accounts but DocuSign is more lenient about the limits in the sandbox platform since it is for development.
Your application will not pass the GoLive testing if it polls more than once per 15 minutes. See Polling Violations on this page.
If your application's polling behavior changes after it is on the production platforms then our automatic monitoring will notify DocuSign staff about your app's violation. The staff will then determine the next step. In the future, actions such as suspending your integration key (client id) may be taken automatically.
Recommended Don't poll. Instead, use the DocuSign Connect webhook feature. If you send your envelopes via the API, then the webhook feature is included with all pricing plans. See the eventNotification attribute of the Envelopes::create call.
I have an application which has the ability to link to a Gmail account via OAuth for a client and send email from the system. I have created the OAuth authorization with Google almost 3 months ago. I received 2 emails from them over that time 1 was resolved within an hour the other was requesting a video which was already included in the original request.
Is google always this slow? I have called cloud support and did not receive any help. Anyone else had to wait months to get OAuth authorization from google?
Facebook and Microsoft were within a day.
Tried calling them cloud support (no help). Send them feedback on the OAuth console page. No reply. Replied to the email they sent a request for more information on but that was over 6 weeks ago no reply. I am trying to get access to send an email. This has to be one of the most common use cases with Gmail. Does not make sense that it is taking so long.
N/A. It is a web application using Gmail oauth2
The first few communications with google regarding verification went relatively quickly with 1-5 day response times. These were the "obvious error" ones. Once we resolved those, we received this on Mar 29:
Thank you for submitting an OAuth App Verification request. We
appreciate your patience during this review period.
The app verification process can take several weeks to complete.
Google will not take action against apps for non-compliance with the
new policy during the verification process if you are acting in good
faith to come into compliance. User access to your app for existing
approved scopes will not be impacted. All apps that have applied are
expected to fully complete the app verification process by May 15,
2019, with the remainder of 2019 to complete the security assessment.
So that is a suggested 6 week timeframe.
Have you received a similar email?
Also note: If your app is not currently available for public use ( or in development ), you can request to skip the verification process.
https://support.google.com/cloud/answer/9110914#skip
This has to be one of the most common use cases with Gmail. Does not
make sense that it is taking so long.
It might make sense in the context of the 2019 Restricted Scope security requirements and the level of chaos that is creating for developers, and therefor their support/verification team.
Based on FAQs, if your project contains multiple OAuth clients, Google needs videos demonstrating usage of restricted scopes for each of those clients. Failure to do so might be resulting in multiple communications. Removing unused clients from your project may help.
Email oauth-feedback#google.com and ask them for an update on your verification status.
Is OAuth API call counted as API request? As you know, the number of API request call is limited to 1,000/account/hour. My customer would like to know whether OAuth API call is included into its limit or not. I coudn't find out any information regarding this topic.
Their developing application now can't keep holding access token after an envelope process is completed. It will be fixed later but at present, OAuth API call happens whenever end-user sends an envelope through their application.
Therefore, they want to confirm this point.
I don't know offhand if OAuth API calls count against the limit. If they don't currently then they will in the future.
All software stacks for web apps include a session storage feature which should be used to store the access token returned from the OAuth process.
In addition, note that your understanding of the API usage limits is not correct. The limit is 1,000 API calls per Integration Key per account per user per hour.
For example, if Joe and Susan are using the same Integration Key (same application) and they both use the same account on DocuSign then each of them can make 1,000 API calls per hour.