IpInkpacket

Blog

Void after a partial sign versus decline

After someone has marked an Inkpacket envelope, the sender can still void. A later signer can still decline. Both close the envelope. That is void-versus-decline honesty — two verbs, one dead envelope, not an un-sign.

One signature on a multi-signer envelope is not completion. Status stays sent. From there two closes still work. The sender can Void envelope. An outstanding signer can decline with a reason. Both stop every remaining signing and embed link. Neither erases the signed event. That is void-versus-decline honesty: the sender’s stop and the signer’s refusal are different verbs on the same in-flight id, and neither is an un-sign.

The sender-only stop after a mark is void after a partial sign. The signer close is decline closes the envelope. The three-way fork is correct, void, or decline an envelope. Desk help is Docs. This guide is the comparison after someone has already signed and the rest have not.

The FAQ says completed envelopes cannot be voided and one decline closes the envelope. Features names both limits under envelope admin. Ask Inkpacket for void after a partial sign versus decline to open this article. Ask how to void an envelope or how to decline to open help. Those phrases stay on the product screens. This article is the public version of which verb you still have after a mark.

Same close, different actor

  • Void is yours. Open the sent document. Void envelope. Record a reason if you want it on the audit.
  • Decline is theirs. They refuse on the signing page or inside an embed and leave a reason (500 characters or fewer).
  • Both mark the envelope closed. Reminders stop. Tokens die. The person who already signed does not get an un-sign.
  • Neither emails outstanding people that the link will die. Tell them out of band if they need to know.

Pick void when the deal is off and you do not want to wait for a refusal. Pick nothing — wait — only if you still want their mark. Do not ask an outstanding signer to “just decline it for us” as a polite void. That writes declined, not voided, and you still cannot reopen it. Do not ask them to ignore the link while you send a twin. The old token is still live until you void or they decline.

What neither verb is

  • Not an un-sign. The audit still shows signed, then voided or declined.
  • Not a skip to the next sequential order. There is no skip.
  • Not a refund of the monthly envelope. The send already counted.
  • Not a correct. If only the next email is wrong, correct that outstanding signer — email change retires the signing token.

A later sequential signer who opens early still sees This envelope is waiting for an earlier signer until the current order finishes — or until you void, or until someone outstanding declines. That wait is first-signer waiting message. Shared order does not change the close: if either person at the current order refuses, the whole envelope closes — when recipients share a sequential order.

Mail and the trail

Void does not email the signer. The link simply dies. That silence is its own leftover — void does not email the signer. Decline emails the sender when Resend is configured; otherwise the refusal is logged the same way as an invite. Copy nothing after either close. There is no live signing URL left to share.

A workspace or per-packet webhook can fire voided or declined on that same envelope id. Treat either as a close, not as “next signer please.” Do not send a twin envelope to “retry the webhook.” What the audit log records is the include list. The signed mark stays. The close is the next line.

The click-path

  1. Open the sent document. Read who signed and who is outstanding.
  2. If the agreement is off, Void envelope. Tell outstanding people out of band.
  3. If you still want the remaining marks, leave it sent. Do not invent a second envelope.
  4. If they decline, read the reason. Status is declined. Envelope admin will not reopen it.
  5. If the work still needs a signature after either close, send a new envelope. Count it.

Public API: POST /api/v1/packets/:id/void on that sent id. Decline is the signer’s POST on the token, not a desk verb. The same 409s apply on void: completed, already voided, declined, expired, or not sent. Public API lists the routes. Marketing Ask stays site Q&A and deep links. It will not void or decline from this article.

Caps and what is not open yet

Neither close is a send. The send that created the envelope already counted. Free allows 5 packets a month. Free at 5 packets a month is the live cap desk send, bulk rows, Web Form fills, and API send share. Hitting it returns HTTP 402 ENVELOPE_LIMIT. Starter is 20 envelopes — more than Free — plus 3 published Web Forms. Seat counts are planning numbers; invite does not refuse when a workspace is full.

Billing is published, not charging. Checkout is not open. Text-message (SMS) is coming soon. Drive missing: Drive not configured. Stripe off: Payments not live. Those flags do not un-void an envelope, reopen a decline, or erase a signed event. The FAQ and envelope admin on Features use completed envelopes cannot be voided and one decline closes the envelope in the same words.

Choose the sender stop or wait for theirs. File signed-then-voided or signed-then-declined if that is what happened. Open a workspace on Free — see published pricing — and run a two-signer throwaway so void-versus-decline honesty is a pair of closes you have already watched, not a guess about who can still stop the room.

Open a workspace on Free

Billing is published, not charging. Send an envelope from the desk without a card.

Open a workspace