August 28, 2026
No. Once an envelope has been sent, there is no supported way to void it through the DocuSign eSignature REST API without triggering the "Envelope Voided" email to recipients. The void operation is designed to notify every recipient that the envelope was cancelled, and the request body has no parameter that suppresses that notification. If you need to cancel, hold, or redo an envelope quietly, your options are all preventative: delete it while it is still a draft, correct it in place instead of voiding, pause its workflow, or restructure your integration so cancellation decisions happen before anything is ever sent.
That is the honest answer up front, and it matters because the internet is full of snippets claiming you can "disable notifications" on a void call. The official behavior is different, and building on a workaround that does not exist will fail at the worst possible time. This guide covers exactly what the void API does, why the notification is baked in, and four engineering alternatives that let you avoid the void email when your use case allows it. If you are new to envelope lifecycle basics, start with our guide to how to void a DocuSign envelope before diving into the API-level detail here.
The Short Answer: Voiding an Envelope Always Notifies Recipients
DocuSign's own developer documentation is unambiguous on this point. When you void an envelope, an email message is sent to all recipients letting them know the envelope was voided, and the reason you provide is included in that message. The notification is not a side effect you can switch off with a query parameter, a request body flag, or an account setting exposed through the API.
This is intentional. A sent envelope is a live transaction that other parties can see and act on. If it silently disappeared, a recipient might sign a document they believe is still active, or wonder why a link stopped working. The void email closes the loop for every recipient and creates a clear record of who cancelled what and when. From a compliance and audit perspective, that transparency is a feature, not a bug.
A few related behaviors are worth stating plainly because they come up constantly in integration work:
- You can only void envelopes that are in process. Draft and completed envelopes cannot be voided.
- Voiding is permanent. There is no un-void operation, and a voided envelope can no longer be corrected.
- The void reason is required. You must supply a text explanation with the request.
So the real question for an API-driven system is not "how do I suppress the email" but "how do I design my workflow so that voiding is a last resort instead of a routine cleanup step."
How the Void Request Works in the eSignature REST API
The void operation lives on the Envelopes::update endpoint. You issue a PUT request against the envelope resource and change its status:
```
PUT /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}
Content-Type: application/json
Authorization: Bearer {accessToken}
{
"status": "voided",
"voidedReason": "Replaced by corrected agreement sent on 2026-08-26"
}
```
Note the exact field name: voidedReason. This is a required string, and it is the text that appears in the notification email to recipients and in the envelope's status history. DocuSign developer support has confirmed that the stored value is limited to 200 characters internally; longer input is accepted but silently truncated, so keep your reason concise, especially if your integration generates automated reason strings.
There are constraints on when the call succeeds:
Two practical implications follow from this. First, because a voided envelope can never be corrected or reused, any workflow that voids as part of normal operation is generating dead weight in your account: envelopes that must be recreated from scratch. Second, because completed envelopes cannot be voided, questions about changing agreements after the fact belong to a different discussion entirely. If that is your situation, read whether a signed document can be modified after signing rather than looking for a void path.
One more detail that trips up automated systems: the same PUT endpoint is used for several different envelope operations, including sending a draft ("status": "sent") and purging documents from completed envelopes. Make sure your integration builds the request body conditionally. A status field copied from the wrong branch of your code is a classic source of accidental voids.
Why DocuSign Sends a Notification When You Void
Understanding the design rationale helps you make better decisions about when to fight it and when to work around it. The void email serves three audiences at once.
Recipients need closure. Each recipient holds a signing link tied to the envelope. When the envelope is voided, that link becomes dead. The notification explains why, and it includes the void reason you supplied, so recipients are not left clicking a broken link or wondering whether they missed a deadline.
Senders need an audit trail. The void reason and the timestamp of the void become part of the envelope record. In a dispute, the question "was this agreement cancelled, and why" has a documented answer. Silent cancellation would undermine that.
Regulators expect transparency. E-signature frameworks in the United States, the EU, and elsewhere reward processes where every party knows the status of a transaction. A cancellation that some recipients never learn about is the kind of gap that compliance reviews flag.
What you can customize is the wording, not the sending. DocuSign accounts can customize the "Envelope Voided" email template through the email resource file in branding settings, adjusting subject lines and body text. That is useful for tone and localization, but it is not a suppression mechanism, and there is no documented API-level switch that skips the notification for individual void calls.
Four Ways to Cancel or Hold an Envelope Without the Void Email
Since the void email cannot be suppressed on a sent envelope, the workarounds all involve acting at a different point in the envelope lifecycle. Here are the four that work in practice.
1. Delete drafts before they are ever sent. A draft envelope (status created) has never touched a recipient inbox, so discarding it notifies no one. Instead of creating envelopes in sent status, create them as drafts and only flip them to sent when your system has validated everything: recipient emails, documents, merge fields, routing order. The status change is the same PUT endpoint with "status": "sent". This "draft-first" pattern is one of the cheapest reliability improvements you can make to an integration, and it pairs naturally with embedded sending versus remote sending API patterns, where your app controls the moment of send.
2. Correct the envelope instead of voiding it. If the problem is a typo in a recipient's email address, a missing field, or wrong routing order, the correct operation is built for exactly this. Correcting modifies an in-flight envelope in place: recipients who have not yet acted simply continue with the updated version, and the envelope keeps its ID and history. There is no void email because there is no void. The trade-offs: only the sender or owner can correct, correction is available while the envelope is still in progress, and recipients whose information you changed receive a fresh email with a new link. Recipients who had already passed identity verification may need to repeat that check after a correction. If your system voids and resends every time something small is wrong, switching to correct removes both the noise and the wasted envelopes.
3. Pause the workflow instead of cancelling. When the issue is timing rather than content, a workflow pause holds the envelope in place without ending it. Envelopes can be configured with steps that pause before a given routing order, and a paused envelope can later be resumed by setting the workflow status back to in progress. Recipients who have not yet been reached simply are not activated yet, so no one is waiting on a dead link. This is the right tool for approvals that stall internally, legal review that takes a week, or a signer who asks for a delay.
4. Move cancellation decisions into your own system. The most robust pattern for API-driven products is to treat the e-signature platform as an execution layer and keep the cancellation state in your application. Track envelope status through webhooks, show "cancelled in your system" states in your own UI, and only call the actual void operation when the envelope genuinely needs to die. In many cases the practical answer is: decide before you send. Combined with the draft-first pattern, most "we need to cancel quietly" tickets turn out to be "we needed one more validation before sending." Teams planning this kind of integration will find the core benefits of integrating e-signature APIs are easiest to realize when lifecycle decisions like this are designed in from the start.
A caution on one tempting shortcut: deleting an envelope that is already in progress does not give you a silent cancel. Deleting an in-progress envelope initiates the void process, which brings back the very notification you were trying to avoid. Deleting quietly is only a draft-stage move.
Before voiding anything in an automated flow, it is also worth pulling the envelope's current state and form data for your own records, since a voided envelope cannot be corrected afterwards. Our guide to exporting tab and form data from signed DocuSign documents via the API covers the endpoints for that.
Correct, Void, Delete, or Pause: Choosing the Right Envelope Action
The pattern to notice: every action taken before the envelope is sent is silent, and every action after sending tells the recipients something. That asymmetry is the whole design of the workaround strategies above.
A Pre-Void Checklist for API-Driven Workflows
Run through this before your code ever issues a void:
- Confirm the envelope is genuinely in process. Drafts should be deleted, and completed envelopes cannot be voided at all.
- Check whether the problem is fixable with correct instead. Wrong email address or missing field almost always means correct, not void.
- Check whether timing is the issue. A workflow pause may be cheaper than void-and-resend.
- Back up what you need. Extract documents, tab data, and the status history you care about before voiding, because the envelope cannot be corrected or reused afterwards.
- Write a recipient-safe
voidedReason, at or under 200 characters, since recipients will read it verbatim in the notification email. - Require explicit confirmation in your application before calling void, so an automated retry loop or a misclick cannot cancel a live transaction.
- Log the void in your own system with the envelope ID and reason, so your audit trail matches what DocuSign records.
For a broader look at designing these lifecycles, our practical guide to DocuSign workflows walks through routing, correction, and cancellation decisions in one place.
Cut Cancel-and-Resend Costs With Nota Sign
Every void-and-resend cycle means paying twice for one agreement: once for the dead envelope, once for its replacement. Workflow design that avoids that tax is central to how Nota Sign, the global e-signature platform built by FaDaDa (法大大), works with integration teams, from correction-first sending patterns to lifecycle rules tuned to how your counterparties actually respond, delivered from regional data centers close to your signers.
Mid-market and enterprise teams can arrange customized plans around the way they send, correct, and cancel rather than fitting a fixed envelope model. If voiding has become routine in your integration, talk to our team about redesigning that flow.
