Blog: Stop Sharing Expired Signature Links
Stop Sharing Expired Signature Links
v0.1.363 · Intelligence update
Here's a quiet failure mode we kept seeing: an agent copies a signature request link from the dashboard, pastes it into a WhatsApp message or email, and the tenant clicks it — only to land on an error page. The link expired hours ago. The agent had no idea.
It's a small thing, but it erodes trust fast. The tenant thinks something is broken. The agent has to chase, re-explain, and resend. The signing flow that should take minutes turns into a two-day back-and-forth.
What we changed
The fix is entirely in the signatures dashboard — no new infrastructure, no schema changes. When you look at a pending signature row, we now compute exactly how long is left on the link before it expires.
If there are more than 24 hours left, nothing changes. The link is fine, copy away.
If there are fewer than 24 hours left, you'll see an amber 'Expiring soon' badge next to the expiry date. You can still copy the link — but the moment you do, a toast pops up telling you how many hours remain and nudging you to consider resending a fresh request instead.
If there's less than an hour left, we get out of the way entirely. The 'Copy link' button disappears and a 'Resend (expires soon)' button takes its place. At that point the link is functionally dead — there's no point copying it.
Why this matters
The root issue was a mismatch between what the UI implied (here's a link, copy it) and reality (this link might not work). Showing the expiry date as plain text didn't communicate urgency. Agents read 'Expires 12 Jan' and moved on, not realising that today was 12 Jan.
The new behaviour makes urgency impossible to miss without being disruptive. You still have full control — for near-expiry links we warn you rather than stop you — but for genuinely expired-or-about-to-expire links we simply remove the broken action and replace it with the useful one.
The technical detail
For anyone curious: this is pure client-side logic. We compute hoursUntilExpiry = (tokenExpiresAt - Date.now()) / 3_600_000 and use that to drive the badge state, the toast content, and whether the copy or resend button is rendered. tokenExpiresAt was already present in the pending request payload — we just weren't using it to inform the UI.
This shipped in v0.1.363. See the changelog for full details.