Expiry & audit trail
Requests can carry an expiry date, and every completed document ships with a full audit trail for compliance.
Set an expiry
When creating the request, set an expiry date; if unsigned by then, the request auto-closes as expired.
Review the audit trail
On a completed request, open the audit trail to see each signer’s action, timestamp, and IP — bundled with the signed PDF for legal defensibility.
When to use
Set an expiry so unsigned requests do not stay open forever, and use the audit trail when you need proof of who signed what and when, for example in a dispute or a compliance review.
Before you start
- Viewing the log and downloading evidence requires
signatures:read. - Default signing behaviour is configured at
/signatures/settingsby users withsignatures:manage. - Evidence depends on the signing method used (OTP, password, biometric or digital signature).
What is recorded
| Item | Purpose |
|---|---|
| Signer evidence | Records how the signer was verified (OTP, password or biometric). |
| Document fingerprint | Taken at send time and compared at signing; a mismatch is refused. |
| Completion certificate | A PDF certificate produced when the request completes. |
| Signed file | The final signed PDF, downloadable from the detail page. |
Tips & common mistakes
- A daily job flips overdue requests to
expiredand sends reminders; do not rely on it for same-day deadlines. - An expired request can be re-issued with a fresh signing link or recreated.
- Download the signed file and certificate together when you archive evidence.
- If the signed file is missing on a completed request, regenerate it from
/signatures/[id].
Related
