Observed the Integration APIs (Token Creation, Envelope Creation, Receipient View Creation) itself taking ~5-6seconds & the rest of the time in loading the docusign page in iframe.
This may be normal, it depends on the amount of data (size of documents) and how busy DocuSign servers are.
You don't have to block the UI right away, when you create the envelope and make the next API call, you can have the UI ready, do this in the background and prepare everything and then show it to the user. This way you avoid the 10 seconds delay that, I agree, is not an ideal user experience.
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 wanted to implement a modal where the envelope recipients would be listed with normal recipient data: name, email, status etc. This list would be displayed regardless of the envelope could be any status.
Every time, a user wanted to consult which recipients exist for a given envelope, he would click for example on an envelope icon and the recipients modal would open.
Ideally, it would call the GetRecipients endpoint of the eSignatureAPI to populate the modal on opening.
Is this behaviour considered polling?? As in my scenario, the information is fetched only on runtime and based on user action is it just bounded by 1000 hourly calls per account?
We don't intent to do automatic polling.
According to the Docusign documentation, this subject is not very clear and if it is a blocker for Go live.
Reading what you wrote I would say it's not polling.
But, an automated system cannot easily know your intentions, so the rule is a bit strict. If you make the same API call to get the details of the same envelope more than once in 15 min - we determine this is polling.
Just ensure that when you test your app for the go-live review, you check different envelopes and/or wait longer than 15 minutes before tests.
I understand how to send a request for a document to be signed in my app. It works perfectly. I also understand that I can either poll the Docusign platform or be pushed notifications using DocuSign Connect (aka webhooks).
I'm kind of seeing a 2-phased implementation. Signing being the first phase, and Retrieval being the second. But I'm hoping this can be implemented in one synchronous process.
These are my two questions:
Can I immediately download/retrieve the signed document as part of the initial signing process somehow? Or, is the only way to retrieve the signed document via an asynchronous poll/push?
After the signer completes the signing process, can I immediately retrieve the signed document? If not, how long after the signer completes the signing process could it take before I can download/retrieve the signed document? I'm hoping this is a split-second thing, and that I don't have to wait a minute to retrieve the signed document.
I understand HOW to do this stuff. My questions revolve around - how QUICKLY can a signed document be ready for retrieval.
Via the API you can download the PDF from the DocuSign envelope at ANY time. However, if you download it prior to all signers completing it, you will see the 'in process' watermark, and basically have an incomplete document. So you will want to download it after all signers have completed - from my experience the signing experience will not re-direct the user (final signer) away from the signing experience UI until DocuSign has internally marked the PDF as completed. There is no 'minute' wait time required, so once the final signer sees the 'signing complete', feel free to download the PDF.
I am calling createRecipientView and using the response to generate an iFrame in my application. However, it appears that viewing this iFrame only works one time - subsequent views of the iFrame send the user to the returnUrl.
This is a problem because in my application we maintain documents that the user can sign at their convenience - so they may look at the document and decide to sign it later... which means that we will need to call createRecipientView again and get a new URL for the iFrame.
Am I understanding this correctly? I can't find much documentation on the URL returned - does it only expire once viewed, or does it expire after a certain amount of time / other conditions?
You are correct; the URL will expire either after being used, or after five minutes (token TTL of 300 seconds).
Please note that an iFrame is not a good idea. Especially if your app will ever be used from a mobile or tablet browser.
I have updated the docs for the EnvelopeViews: createRecipient method with information about the one time/limited time use of the URL.
I have just set up and created by first ever SharePoint development effort: a project for a web part, to be hosted in a SharePoint Online instance (my Office 365 trial).
I have figured out how to use the List API to pull the content I am supposed to present, being a rotating list of banner images, but I have one remaining concern. I would like to keep track of where in the list I am, and when last I changed images. Another question of mine answers this quite nicely if I go with local storage, but is there any SharePoint REST or JSOM API I can use to persist this state in the SharePoint service?
I like the local storage answer, but you could also write the state information to another SharePoint list.
Keep track of the information on a per user basis (probably against their user ID, since they'll likely be authenticated) and have send an AJAX request or a JSOM request without any visible callback behavior each time the viewer's state changes (maybe even use a web worker for users that support them).
Writing info to SharePoint lists isn't the fastest operation in the world, so it's possible you could have the banner rotate, the request fire, and the user close the browser before the request was complete -- but in that case they would just wind up on the same slide they were at before (so just repeating the last step in the rare occassion where this happens).