I went to send my application to the production environment and received the following message.
Excessive polling does not comply with DocuSign rules and limits
I will have to implement the API Resource Limits,
how can I get the following Headers from my answers?
I'm using java jdk how am I going to get the header response parameters?
EnvelopesApi envelopesApi = createEnvelopesApi(session.getBasePath(), user.getAccessToken());
EnvelopeDefinition envelope = makeEnvelope(args, obj);
EnvelopeSummary sumary = envelopesApi.createEnvelope(session.getAccountId(), envelope);
in java we don't have the CreateEnvelopeWithHttpInfo method as in C#. How will I get to control requests?
Excessive polling most likely is caused because you are requesting information about the same envelope again and again (technically when you go-live it means you did this more than once in 15 min). You don't need to fix this by checking the headers to see the numbers of calls that you made within the allotted window of your resource limit.
Instead I would suggest to use a web hook with DocuSign Connect. This approach means you will know when something changed and you won't need to constantly poll the same envelope.
Related
Im in the process of trying to promote an Integration App to our production DocuSign environment, but receiving the following error.
"Excessive polling does not comply with DocuSign"
Here's the endpoint we are calling with from_date filter and a custom field. The from_date and the clientID custom field values change for each request that is made. Yet we still get the excessive polling error. The DSACCOUNTGUID value does not change.
https://demo.docusign.net/restapi/v2.1/accounts/{DSACCOUNTGUID}/envelopes?from_date=2020-09-21T15:33:08.160Z&custom_field=clientID=1201
Can someone tell what we are doing incorrectly? Thanks ahead of time.
Can
From this article
Polling rate limits
For any specific envelope, polling status requests are limited to once every 15 minutes.
To avoid excessive polling, you can specify a span of time to poll in each Envelopes: listStatusChanges or equivalent listStatusChanges SDK method call. To ensure that you don’t miss any changes, we recommend that you request overlapping times in your polls or subscribing to Connect to get status updates for the envelope.
You should consider using webhooks instead.
The ListStatusChanges call will generally trigger a polling violation if it is called more than once every fifteen minutes.
What query string parameters are you using and how often are you making that call?
I've been working with the DocuSign API for some time now, and it's all fine, but when the signer refuses to sign, I get a rejection message using "EnvelopeRecipients:: List".
However, frequent use of the API is prohibited in the go-Live instructions.What should I do?
enter link description here
enter image description here
RecipientViewRequest viewOptions = new RecipientViewRequest
{
ReturnUrl = returnUrl,
ClientUserId = this.CurrentUserID,//DSConfig.ClientID,
AuthenticationMethod = "none",
UserName = displayName,
Email = userEmail
};
// Use the SDK to obtain a Recipient View URL
var envelopesApi = GetEnvelopesApi();
ViewUrl viewUrl = envelopesApi.CreateRecipientView(JwtAuthClient.JwtAuth.Account.AccountId, envelopeId, viewOptions);
You could use DocuSign Connect webhook or if you're using embedded signing, it's in the URL that goes back to your app after the user finished signing.
" frequent use of the API is prohibited" is not accurate. Polling is what is bad/not allowed. "frequent" is relative. If your app need to make more API calls - you may make more API calls. There are limits etc. but you don't want to also go overboard with the notion you cannot make API calls.
You're facing limitation issues because of bad implementation.
I know it's too late but I recently work on DocuSign API and randomly found this question, that's why decide to answer it for other people if they come to this question to find the solution.
The Latest DocuSign API version is 2.1 and I'll only talk about that version.
In this version, either you call via SDK or your custom code List API Call
end-point has many options which we can use to optimize the Envelope check status.
count, start_position, and continuation_token parameters are useful when you have a large number of envelopes on the Cloud which status do you want to check (include decline) to split the result in chunks or you can say page wise. It will help you to manage frequent call limitation issues like you can filter only those envelopes which status you want to check with further options and fetch envelopes in a bunch instead of each envelope status will help you to reduce the number of calls to DocuSign.
(I'm not going to train you on how you can write code as this is not a platform for that)
For the case which is mentioned in the question, the same API end-point will be useful to fetch only declined envelopes with messages.
Like for that purpose you just need to pass "declined" against the status parameter which is useful to filter cloud envelops status-wise. To include declined message with the response, you need to pass "recipients" against the "include" parameter, which appends the Recipient entity with each envelope object where you can filter out the declined message. "DeclinedReason" or "VoidedReason" there are two properties which can return a decline message with this call. If you want to see the complete schema of the envelope entity, you can go through same link List API Call
In short, to solve the limitation issue you can use "listStatusChanges" end-point which has too many optional parameters which you can utilize as per your need but the performance depends on how you utilize it.
PS: Webhook is a better option to sync data between two services in optimize way or without any calling limitation, my answer is only for those who don't want to use webhook.
I tried calling DocuSign sales and support (transferred around 3 times) and no one could give me a straight answer on this. Their "support" actually told be to try stackoverflow, so here I am...
I'm looking at their API pricing levels here: https://www.docusign.com/products-and-pricing/api-plans-b
If I have the Intermediate API, can I make the following API requests?
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}
GET /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/form_data
The part that's throwing me for a loop is the DocuSign Connect feature in the Advanced API plan. The description of it is:
The DocuSign Connect module lets you configure webhooks for envelope events and recipient actions for some or all users in your account. It can also be used to transport the completed documents back to your app or website and to retrieve any form field data entered by your recipients.
I don't need the webhooks, but I need to be able to get the completed documents as PDFs and get the form field data. Do I really need the DocuSign Connect feature for that?
You will be fine with the intermediate plan. Here is the basic distinction between polling and Connect - With Connect, we will proactively notify YOU when key envelope events occur.
Otherwise, it's up to you to call GET /envelopes and/or GET /form_data to retrieve that information. Be wary of the resource limits when you poll.
As a quick aside, instead of making two requests to retrive that information, just make one - GET /envelopes?include=recipients,tabs. This will provide you all the information you seek in one request.
The important excerpt from that guide:
You may not exceed one GET request per unique envelope endpoint per 15
minutes. If you exceed this limit the request will not fail, but it
will be flagged as a violation of rate limits which can cause your app
to fail review to go-live review.
For example, the following transactions violate API rules due to the repeated GET requests to the first document and second recipient:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:02:00] GET /accounts/12345/envelopes/AAA/recipients/2
[12:03:00] POST /accounts/12345/envelopes
[12:04:00] GET /accounts/12345/envelopes/AAA/documents/1 *
[12:05:00] GET /accounts/12345/envelopes/AAA/recipients/2 *
However, the following set of requests comply with API rules and limits and would not be flagged by the platform:
[12:00:00] POST /accounts/12345/envelopes
[12:01:00] GET /accounts/12345/envelopes/AAA
[12:16:00] GET /accounts/12345/envelopes/AAA
[12:17:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:32:00] GET /accounts/12345/envelopes/AAA/documents/1
[12:40:00] PUT /accounts/12345/envelopes/AAA/recipients/1
[12:41:00] PUT /accounts/12345/envelopes/AAA/recipients/1
How many DocuSign envelope statuses can I get at a time by calling the API
PUT /restapi/v2.1/accounts/{accountId}/envelopes/status?envelope_ids=[list_of_ids]
I have a bulk number of envelope Ids and it is increasing day by day. What I am going to do is, I am going to pull all the envelope statuses (except the voided and completed envelopes) in a scheduler manner.
I have not found anything or I have missed in the documentation. Is there a limitation in docusign with the number or request size ?
There are two limits: the max length of a URL including its query parameters, and the max envelope ids for the call.
Avoiding the URL length limit: As documented, you can set the query parameter to a special value: envelope_ids=request_body. In this case, the method uses the envelope IDs in the request body.
From the documentation:
envelope_ids query parameter -- The envelope IDs to include in the results.
The value of this property can be:
A comma-separated list of envelope IDs. [or]
The special value request_body. In this case, the method uses the envelope IDs in the request body.
I don't know what the second limit is.
As an alternative, consider setting up a webhook. You can receive the webhook notifications of completed envelopes from behind the firewall (without changing the firewall) by using an intermediate queuing system.
Example code for AWS, Azure, and Google Cloud is available for C#, Java, PHP, Python, and Node.js. See the Connect-* repositories in github.com/docusign
While working on a DocuSign embedded signing process (which has worked in the past), I noticed that after signing the document the 'event' parameter was missing from the 'returnUrl' I was being sent back to.
The returnUrl looks like:
http://www.example.com/index.php?param1=value1 ... ¶m10=value10
The parameters were being passed on returning from signing, but no event=signing_complete parameter was being added. I tried removing the parameters, and suddenly the event parameter returned.
After further experimentation, I discovered that the returnUrl parameter has a 500 character limit. Anything more is truncated. This will also truncate the event parameter from the end of the returnUrl.
This does not seem to documented in the DocuSign REST API documentation (https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Post%20Recipient%20View.htm).
So, is this a feature or a bug? Other than using session or database storage, is there a recommended workaround for the 500-character limit?
There might be some limits to the URL that is being passed in by the web servers themselves. I have not seen a lot of people hit this limit because probably most of the time folks do not put that much information into a return URL.
If you are coming from software that has session state you can use the following technique:
1) add the information you were previously sending via URL to a dictionary or a collection object and save it in the session on the server. Follow the best security practices for that one so that this information can't be easily accessed (there is a ton of material on how to do this properly and it's probably beyond this answer)
2) in the url instead of all the keys and values just provide the key to your collection.
3) upon return from DocuSign look up the object and retrieve the passed in information.
If there is no state in your software you can try using other properties of the envelope to put the additional information such as envelope custom fields. You can populate those on create and you can retrieve the information back when the control comes back to your software. Here is the article about custom fields: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Get Envelope Custom Field Information.htm