How to Send a Contract That Can Only Be Opened Once
You can send a contract that opens once by putting the PDF behind a single-use link that returns "gone" the moment the first download completes. Strip the PDF's hidden metadata first, add a password so only your counterparty can open it, and set an expiry so the link can't sit around in an inbox. The combination - one open, one person, one deadline - is what an email attachment can't give you.
Why one-time access for contracts
A contract is not like a marketing flyer. The draft you send during a negotiation often contains numbers, terms, and concessions you don't want forwarded, screenshotted, or sitting in a shared mailbox six months later. The risk isn't usually a sophisticated attacker; it's the ordinary leak - a link forwarded "for context," an attachment that lands in a synced folder, an inbox that gets exported when someone leaves the company.
One-time access shrinks that exposure window to almost nothing. The recipient opens the file, the link dies, and no live copy is left on a server for anyone else to stumble onto. If the wrong address gets the link first, you find out fast - your counterparty reports it's already spent, and you reissue.
Send a single-use contract in 4 steps
The whole flow takes under a minute. Here's the order that matters:
- 1. Upload the PDF. Drag the signed or draft contract into the sender. A practical upload is around 100 MB, which covers essentially any contract, exhibit set, or scanned redline. (The size cap is a deliberate safety choice, not a technical limit we're proud of - large transfers are exactly where abuse hides.)
- 2. Strip the metadata. We rebuild the PDF on our server and clear its document-information fields before the file is ever offered for download. More on what those fields leak below - for contracts this is the step people forget.
- 3. Set single-use + password + expiry. Set the link to one use, add a password you share through a separate channel (a phone call, a different email thread, your messaging app), and pick an expiry such as one hour or one day. One open, one person, one deadline.
- 4. Send the link. Paste it into your email or chat. After the first successful download - or when the expiry passes, whichever comes first - the link returns a "410 Gone" response and the file is purged from our server.
If you're wiring this into a contract-management system or e-signature flow, the same behavior is one API call.
You POST the file with max_uses=1, expires_in, and password as plain
parameters and get back a signed URL. The docs cover the request and response in full.
Single-use link vs email attachment
Email attachments are convenient and universal, and for a finalized, already-public document they're perfectly fine. Where they fall short is control: once an attachment leaves your outbox, you have no say over how many copies exist or where they travel.
| Email attachment | Single-use link | |
|---|---|---|
| Copies after sending | Lives in every inbox it's forwarded to | One download, then the file is purged |
| Access control | Anyone with the email can open it | Password gate + single-use enforced server-side |
| Expiry | Never - it stays until deleted by hand | Hard deadline you set up front |
| Hidden metadata | Travels with the file untouched | Stripped before the first download |
| Forwarding a "wrong recipient" mistake | Irreversible once it's read | Link spends itself; you reissue to the right person |
To be fair, an attachment never expires in a way that locks you out either - and a single-use link does require your recipient to download within the window. For an active negotiation that trade is worth it. For a contract you expect the other side to keep forever, send the attachment.
Don't forget hidden PDF metadata
This is the part that bites legal and deal teams. A PDF carries a document-information block that can include the author's name, the original file title, the producer or creator software, and creation and modification timestamps. Depending on how the file was made, it can also retain revision history or the path it was saved from.
None of that is visible when you open the document, but it's trivial to read. For a contract that's a real problem: an author field can reveal which junior associate actually drafted the "final" version, a modification timestamp can betray that you turned the redline around in twenty minutes when you claimed you needed two days, and a file path can expose an internal matter name or counterparty codename. That is negotiation context you never meant to hand over.
We clear those fields server-side as part of delivery. To be precise about how that works: the stripping happens on our servers, not in your browser, so this isn't zero-knowledge processing - it's thorough processing, after which the file is purged once it's been delivered. If you only need to scrub a document without sending it through us, the standalone strip PDF metadata tool does the same cleanup and hands the file straight back.
Password-protect and set an expiry
A single-use link with no password and no expiry is, for a brief moment, just a public file: anyone who intercepts the URL before your recipient does can spend that one open. The password closes that gap, and the expiry caps how long the link is even worth intercepting.
Two habits make this actually safe rather than theater. First, send the password through a different channel than the link - if both ride in the same email, a compromised mailbox hands over both at once. Mention on the phone or in a separate thread that "the password is the matter number." Second, keep the expiry tight. For a contract you expect to be opened today, an hour or a few hours is plenty; you can always reissue if the recipient misses the window. A week-long link is a week-long liability.
Knowing it was opened
For contracts you usually want one honest signal: did it land? Because the link is single-use, the transition to "spent" is itself your delivery confirmation. When the link starts returning "gone," the download completed - that's your proof the counterparty received the file, without planting a tracking pixel, logging their IP for analytics, or phoning home every time the PDF is reopened.
That's a deliberate line. Read-receipt tracking that follows a document around after delivery is exactly the kind of invasive behavior that makes recipients distrust a link. A clean "delivered once, then closed" is enough to know the handoff happened - and it's a story you can comfortably tell the other side.
Send a contract that opens once · related: strip PDF metadata · send a file that deletes after download · single-use link API