Document link expiration
To safeguard the privacy of recipients and facilitate the security of document content, the lifespan of publicly accessible URLs (provided to recipients via email) must have a finite life span.
However, work processes can have very different tolerances for how long that lifespan should be.
For this reason, Adobe Acrobat Sign administrators can configure, at the account level, how many days a public URL should remain viable after it is generated.
Recipients that trigger an expired URL will be prompted with an option to have a new URL sent to the email address of the current recipient. Redirection to a new email is not allowed through this action.
New link requests are throttled at ten requests (per recipient) in a 60-minute rolling window.
An attempt to request additional new links after ten have been requested within the 60-minute window disables the Send new link button and prompts an error. The recipient then must wait for 60-minutes after their first request to try again.
The throttle is applied per recipient. In a parallel signature flow, each recipient has the authority to request up to ten new links within their respective 60-minute windows.
The default expiration timespan is seven days.
Enterprise and business tier accounts have the option to adjust the expiration time to any value between one and 90 days.
The controls to adjust the lifespan can be found on the Security Settings tab at the account level. (Link expirations cannot be edited at the group level.)
This setting only applies to the URL delivered in the Acrobat Sign email notification.
The agreement itself is not impacted in any way.
Audit Report and Activity log entries
Each time a recipient requests a new document after a link has expired, a record of that request is entered into the audit report and Activity log:
Things to know:
This setting controls how many days the recipient has access to the link to the agreement after the delivery of the email.
The agreement expiration time refers to the lifetime of the agreement.
In the above example, the agreement is viable for 11 days, and any email link sent to the user is viable for three days after delivery.
Suppose the recipient attempts to access the email URL on the fourth day. In that case, the link will trigger an error message indicating the link is expired and offer to deliver a new link to the original email address. The second (and any subsequent) email link has the same lifespan of three days.
If the recipient waits 12 days, the agreement expires. Requesting a new link delivers a message that the agreement has expired and can no longer be signed.
Web URLs generated via API calls set an expiration time span for all agreements and default to 14 days today. The Signing URL/Expiry parameter can be used to alter the default lifespan if needed.
When a new link is requested by the recipient, an agreement event is triggered: URL_REAUTHENTICATION_REQUESTED
A new signing URL for a specific recipient can only be requested ten times per hour. If a recipient requests more than ten new singing URLs in one hour, the Send new link button is disabled and an error is triggered.
Requesting a new URL to view an existing agreement does not consume a transaction.
This feature only applies to the viability of the link to reach the document and has no bearing on the previously input information.
The recipient has already accepted the ToU, and that acceptance is recorded on the transaction. No further acceptance is warranted.
URL Endpoints that will enforce the expiry check:
- /public/resend/ (delegation links)
There are no webhook triggers tied to expiring a public-facing URL.
All public-facing links that target an agreement in email are affected equally.
The Report Abuse links are not impacted, and will always be available.