Envelope admin: void, correct, resend, and when signers decline
How Inkpacket handles an in-flight envelope: signer decline with a reason, void (links stop), correct the recipient on the same envelope, and resend the existing signing link.
Sends do not always complete on the first link. The address is wrong. The message landed in a promotions folder. The signer reads the PDF and refuses. The deal is off. Envelope admin is the set of actions that keep you on the same envelope id instead of cloning a second envelope and losing the audit trail.
On a sent envelope, the desk can void, correct, or resend. Signers can decline with a reason. Completed envelopes cannot be voided. This guide matches the in-app notes at Docs and the envelope admin feature. If you have not sent anything yet, use the five-minute send.
Why in-place admin matters
A second envelope looks harmless and is not. You now have two audit logs, two reminder schedules, and a signer who may complete the old link after you “replaced” it. Inkpacket keeps void, correct, and resend on the original document. The envelope id does not change. Webhooks fire declined, voided, or corrected on that same id so your own systems do not have to merge twins.
The FAQ answer is the short version: void stops signing links; correct updates the recipient on the same envelope; resend emails the existing link without creating a second envelope; signers can decline with a reason and the sender is notified.
When a signer declines
Decline is the signer’s action, not the sender’s. On the signing page — and inside an embed — they can refuse and leave a reason. The envelope status becomes declined. Every signing and embed link on that envelope stops. Reminders stop. The sender is emailed when Resend is configured; otherwise the decline is logged the same way as an invite.
Intentional limit: one decline closes the whole envelope, even when later sequential signers have not been invited yet. If you needed a different person after a refusal, send a new envelope — or, if nobody has signed and you only had the wrong email, correct the recipient before they decline.
Treat the reason as operational data. “Wrong entity” and “terms changed” are different follow-ups. The audit log records the decline; your webhook, if set, receives the declined event with the rest of the lifecycle.
How to void an envelope
Void is the sender stopping an in-flight envelope. Open the document on the desk and void it. You may record a reason. Every signing and embed link on that envelope stops working. The audit log records the void. A webhook fires voided when you have a URL configured.
What voiding does and does not do
- Does: mark the envelope voided, kill tokens, stop reminders, keep the same envelope id.
- Does not: email the signer. The link simply dies. Tell them out of band if they need to know.
- Does not: void a completed envelope. The filed PDF stays filed.
- Does not: mint a replacement envelope. If the work still needs a signature, send a new envelope from the PDF or template.
Use void when the agreement is off, the PDF was the wrong file, or you must stop collection immediately. Use correct when the PDF is right and only the recipient is wrong. Use resend when the recipient is right and they never saw the mail.
How to correct a recipient
Correct updates the outstanding signer’s name or email on the same envelope. A new invite goes out. If the email changes, the previous token is retired so the old inbox cannot finish the envelope. Fields and routing stay where you placed them on the draft. This corrects the signer on the same envelope. It does not create a second one.
Correct is the right tool for a typo, a role change (“send it to the controller, not the intern”), or a display-name fix you want on the audit trail. It is the wrong tool after someone has already signed. It is also the wrong tool if the PDF itself is wrong — void or abandon and send a new envelope from the right file.
Because the envelope id stays put, your webhook consumers can treat corrected as an update to an envelope they already stored. Desk help and the public API use the same word: POST /api/v1/packets/:id/correct.
How to resend the same link
Resend emails the existing signing link to outstanding signer(s) again. The envelope and the signer stay the same. The token stays the same unless you also corrected the email. Resend is idempotent: it does not duplicate the envelope, and it does not rotate the link just because you clicked twice.
Use resend when the invite never arrived, the signer deleted it, or you want another copy in the thread. Do not use resend to change the address — that is correct. Do not use resend to stop the envelope — that is void. If mail is not configured, resend logs the same way as the first invite; copy the URL from the desk if you need it in another channel.
Reminders are separate. A reminder is the scheduled nudge on the cadence you set at send. Resend is a manual “send it again now.” Both leave the envelope id alone. Reminders and expiry and reminder help explain the job that walks outstanding SENT envelopes.
What you cannot do after completion
Once the envelope is completed, the stamped PDF is the record. You cannot void it. You cannot correct the signer as if the send were still open. If the completed file is the wrong document, you issue a new envelope and keep the old one on file. That is deliberate: the audit trail should not pretend the first completion never happened.
Expired envelopes are also closed for signing. The hourly cron marks overdue SENT envelopes expired so the document list stays honest. Ask for a new envelope if the work still needs a signature. Expiration is not a void; it is the window ending.
The same actions on the public API
Owners and admins mint org-scoped tokens in Settings. The envelope-admin routes sit next to send:
- POST /api/v1/packets/:id/void — void a sent envelope (optional reason).
- POST /api/v1/packets/:id/resend — resend the existing signing email without a new envelope.
- POST /api/v1/packets/:id/correct — update the outstanding recipient on the same envelope.
Create and send still accept an Idempotency-Key if your client may retry. Webhooks POST declined, voided, and corrected with the same signature header documented under outbound webhooks. Public API and signed webhooks is the developer guide; the API feature and webhooks feature are the marketing versions of those screens.
Desk help and this guide
Operators who are already signed in should keep More on voiding, correcting and resending open while they click. This article is the public, indexable version of that section: same rules, more context, links out to Features, the home page, and signup if you still need a workspace. The help page links back here so the two copies do not drift into different stories.
Electronic signature software is only as trustworthy as what you can do after send. Void, correct, resend, and decline are that trust. Use them on the same envelope. Then file the completed PDF or start the next one from a template.
Open a workspace on Free
Billing is published, not charging. Send an envelope from the desk without a card.
Open a workspace