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?
Related
I can see the below point in docusign documentation https://developers.docusign.com/docs/esign-rest-api/esign101/rules-and-limits/
2. Apps are limited to one GET status request per unique envelope 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. To avoid exceeding this limit, design your app to poll at 20-minute intervals rather than 15 or, rather than polling for envelope status, your integration can subscribe to Connect to get status updates for the envelope.
My requirement is to poll the documents for each user using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&from_date=2021-10-21T04:38:51.0930000Z&include=recipients&order_by=last_modified&order=asc&folder_types=normal,inbox,sentitems,draft&start_position=0
and there documents using API:
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes/<envelope_id>/documents
and I have multiple user connection with same account Id, hitting these two APIs.
will it be flagged as rate limit violation? I have tried these GET api again and again but I can't see this violation status on my client? how can get update of this if in case it happens on my prod instance?
What is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/envelopes?count=10&
from_date=2021-10-21T04:38:51.0930000Z&include=recipients&
order_by=last_modified&order=asc&
folder_types=normal,inbox,sentitems,draft&start_position=0
Is it to monitor incoming envelopes? If so you can use Recipient Connect to receive webhook notifications.
Otherwise, for a given DocuSign user, you can make the API call once every 15 minutes or less often.
You cannot make the call more often than once per 15 minutes per associated user. If your app uses a "system user" such as finance#your-company.com then you cannot call it more than once per 15 minutes since the results would not change.
And what is the goal of this API call?
GET https://demo.docusign.net/restapi/v2.1/accounts/<account_id>/
envelopes/<envelope_id>/documents
The documents in an envelope are generally not going to change.
More often, apps want to know when an envelope has completed, and then download the docs.
Update
The polling limits are:
per user
results must be expected to change
This means that you cannot poll after an envelope reaches a terminal state. IE only poll if the envelope is in the sent or delivered states.
And it is still not clear to me why an envelope's documents will change.
If you want to provide the current version of the envelope's documents to your application's user, give them a button to download the documents. Don't poll for them.
Finally remember the limit of 1,000 API calls per hour per account for your application. Your application will NOT be approved for additional API calls per hour with this type of polling activity.
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.
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
We create PaymentIntents (with capture_method=manual in case that matters) in our iOS/Android apps when the user places an order.
We send the order to the connected venue once the charge.succeeded webhook fires. If this doesn't happen within a couple of minutes, we expired the placed order on our side.
So interestingly 2 out of 10 times we don't get this webhook to fire.
Im wondering if it's actually wise to listen to this webhook in order to decide if we send the order to the connected account's venue or not or if there is a better way to determine that the payment will actually work once we try to capture it.
Webhooks are the recommended way for getting a payment intent's status, but you can also use the API to get its status.
A quote from the Stripe docs:
It is technically possible to use polling instead of webhooks to
monitor for changes caused by asynchronous operations—repeatedly
retrieving a PaymentIntent so that you can check its status—but this
is markedly less reliable and may pose challenges if used at scale.
Stripe enforces rate limiting on API requests, so exercise caution
should you decide to use polling.
In your case, I'd recommend waiting for the webhook and then after a few minutes, call either the PaymentIntents API or the Charges API if you haven't received the webhook yet.
There's likely something else going on here, so I'd suggest you reach out to Stripe - webhooks should fire all the time, and it's a really really rare occurrence that they wouldn't.
I created a webhook I let ran on my forge application. Webhook is "system": "derivative", on "event": "extraction.finished".
After a few weeks, hook was not triggered anymore.
When I query it to check what was going:
webhook is still present
But, I now have "status": "inactive" (it was active at creation time)
I got no feedback why this hook was disabled (only way to figure it out is by being reported my main app was broken from users).
What can deactivate a webhook? is it expected?
Current workaround I have so far is re-create the webhook, which comes back with active status. Unfortunately, this is definitely a short-term solution since I do not know when it will move to inactive again.
Thank you,
Webhook status can be set to inactive if callbackUrl is failing too often (cf. comment from Xiaodong Liang "When webhook tried a couple of times but no any response, it will disable this webhook").
(In my case there was a place in my callbackUrl that was returning 500.)
Thanks
I would recommend this class of Autodesk University: Seamless integration with Forge Webhooks. This class talks about some notes on Webhook such as SLA:
Working on formal SLA
Delivery Guarantees
At least once
Ordering is not guaranteed
Responsibility of Callback URLs
Callback URLs have fixed time window in which to respond (~10 secs)
Best Practice - Return 202 and process asynchronously
3 Retries done, 15 minutes apart
Final retry 24 hours later
If none succeed, we will disable the WebHook
Latency
HTTP Latency: Ideally suited to coarse grained events
In addition,I'd recommend another note of Webhook: signature. I have some practice and this is the blog:
https://forge.autodesk.com/blog/practice-payload-signature-webhook