One click — but never by accident: the security design of Pishik review links

We tell people that reviewers approve contracts "from the email." A careful engineer — or a careful lawyer — should immediately ask: from the email how, exactly? What stops a forwarded message, a guessed URL, or a corporate mail filter from approving a contract? Good questions. Answering them is most of the design.

The click that doesn't count

The Approve and Reject buttons in a review email don't record anything. They open a decision page — over a personal link, with the reviewer's choice preselected — that shows the contract, the documents, and an optional comment box, and asks the reviewer to confirm. Only that confirmation, an explicit form submission by a human, records the decision.

This isn't caution for its own sake. Corporate mail security tools routinely prefetch every link in a message to scan the destination — before the recipient has even opened the email. If following a link recorded a decision, your security appliance would be approving your contracts. So reading a link can never change state; only confirming on the decision page can. The confirmation page isn't friction in front of the feature. It is the feature: approve or reject from the email — nothing is recorded until the reviewer confirms.

One link, one reviewer, one decision

Each reviewer's link carries a personal token with roughly 200 bits of randomness — not guessable, not enumerable, and never shared between reviewers. The link is single-use: the moment a decision is confirmed, it closes permanently. Open it again and you get an honest "this link was already used" page — not the document, and not a second chance to decide. A decided decision stays decided; changing course afterward is a deliberate, logged action by the contract team, not a re-click.

Because the token is bound to one reviewer, the decision it records carries that reviewer's name in the audit trail. Which leads to the one rule we ask of reviewers: don't forward your link. It's personal, and anything done with it is attributed to you. That warning, and the rest of what reviewers should know, lives in the reviewer link-security note.

Links that expire — and refresh when nudged

Review links expire. The clock runs from when the email was sent, and the check fails closed: a token with no recorded send timestamp is treated as expired rather than granted an unbounded lifetime. Expired links get a clear explanation page, and the contract team can simply resend.

Expiry has a usability trap, though: reminder emails. If we nudge a reviewer near the end of a link's life and the link dies the next morning, we've sent them to a dead end — and taught them to distrust the next reminder. So every reminder refreshes the link's expiry clock. A nudge never points at a link that's about to die. When a rejected contract is revised and sent back, the old token is discarded entirely and a fresh one is issued — a new review cycle gets a new key, and prior approvals elsewhere in the flow stay intact.

Failing quietly, on purpose

The failure pages are designed to say as little as possible to the wrong audience. An invalid token, a made-up token, and a link into a suspended workspace all get the same generic answer — the public door never confirms what exists behind it. Used links say "used" and expired links say "expired," because the legitimate reviewer holding them deserves to know what happened; but none of them leak contract contents, and the document itself is never served by us at all — it stays in your storage, behind your share-link permissions.

Two clicks, honestly

So the honest count is two clicks: one in the email, one to confirm — and the second click is the one that protects you. The full mechanics, including what each error page means, are in the review-link security reference, and the wider architecture — why our servers never hold your documents in the first place — is on the security page. If you got a review email and just want to know what to do with it, start with how to review.