2026年8月28日
不能。envelope 一旦發送，透過 DocuSign eSignature REST API 作廢它時，沒有任何受支援的方式可以阻止系統向收件人發出「Envelope Voided」郵件。作廢操作的設計目標就是通知每一位收件人該 envelope 已被取消，請求內文中也不存在任何可以抑制這則通知的參數。如果你需要安靜地取消、擱置或重做一份 envelope，可行路徑全是預防性的：趁它還是草稿時刪除、用更正代替作廢、暫停其工作流程，或者重構你的整合，讓所有取消決策發生在任何內容發出之前。
這就是開宗明義的誠實結論，而它很重要，因為網上充斥著聲稱可以在作廢呼叫上「關閉通知」的程式碼片段。官方行為並非如此，基於一個不存在的開關去搭建方案，只會在最糟糕的時刻出錯。本文將完整說明作廢 API 的實際行為、通知為何被內置於設計，以及四種工程替代方案——只要你的場景允許，就能避開作廢郵件。如果你剛接觸 envelope 生命週期的基礎概念，建議先弄清楚作廢 DocuSign envelope 的基本操作，再深入本文的 API 層細節。
簡短結論：作廢 envelope 一定會通知收件人
DocuSign 官方開發者文件在這一點上沒有任何含糊。作廢一份 envelope 時，系統會向所有收件人發送一封郵件，告知該 envelope 已被作廢，並附上你填寫的作廢原因。這則通知不是可以靠查詢參數、請求內文開關或 API 暴露的帳戶設定關掉的副作用。
這是有意為之。一份已發送的 envelope 是一筆進行中的交易，其他各方都能看到並據以行動。如果它悄無聲息地消失，收件人可能簽署一份他們以為仍然有效的文件，或者對著一個失效的連結一頭霧水。作廢郵件為每一位收件人閉環了這件事，並留下誰在何時取消了什麼的清晰紀錄。從合規與審計的角度看，這種透明是特性，不是缺陷。
還有幾個相關行為值得直說，因為它們在整合開發中反覆出現：
- 只有進行中的 envelope 可以作廢。草稿和已完成的 envelope 無法作廢。
- 作廢是永久性的。不存在「反作廢」操作，已作廢的 envelope 也不能再更正。
- 作廢原因為必填。請求中必須附帶一段文字說明。
所以，對一個 API 驅動的系統來說，真正的問題不是「如何抑制那封郵件」，而是「如何設計流程，讓作廢成為最後手段，而不是日常清理步驟」。
void 請求在 eSignature REST API 中如何運作
作廢操作位於 Envelopes::update 端點上。你向 envelope 資源發出一個 PUT 請求，修改其 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"
}
```
注意確切的欄位名稱：voidedReason。這是一個必填字串，其內容會原樣出現在發給收件人的通知郵件和 envelope 的狀態歷史裡。DocuSign 開發者支援已確認，該欄位內部儲存上限為 200 個字元；超長輸入會被接受但靜默截斷，所以請保持原因簡短，尤其是當你的整合會自動產生原因字串時。
呼叫何時能成功，存在明確約束：
由此引出兩個實際推論。第一，已作廢的 envelope 永遠無法更正或重用，任何把作廢當作常規操作的流程，都在帳戶裡製造死重：只能從零重建的 envelope。第二，已完成的 envelope 無法作廢，所以「簽完之後改協議」完全是另一個話題——如果那是你的處境，你該找的是關於已簽署文件能否再修改的討論，而不是作廢路徑。
還有一個細節常讓自動化系統踩坑：同一個 PUT 端點承擔了多種 envelope 操作，包括發送草稿（"status": "sent"）和清除已完成 envelope 中的文件。務必讓你的整合按條件構造請求內文。從錯誤的程式碼分支複製來的 status 欄位，是誤作廢的經典來源。
為什麼 DocuSign 在作廢時發送通知
理解設計動機，能幫你更好地判斷何時該規避、何時該順勢。作廢郵件同時服務三類對象。
收件人需要閉環。每位收件人手裡都握著一個綁定該 envelope 的簽署連結。envelope 一作廢，連結即失效。通知郵件解釋了原因，並附上你填寫的作廢原因，收件人不會對著壞連結乾著急，也不必猜測自己是否錯過了截止日期。
發送方需要審計軌跡。作廢原因和作廢時間戳都會成為 envelope 紀錄的一部分。發生爭議時，「這份協議是否被取消、為何取消」有據可查。靜默取消會摧毀這一點。
監管方期待透明。美國、歐盟及其他地區的電子簽署框架，都獎勵那種每一方都清楚交易狀態的流程。部分收件人始終不知情的取消，正是合規審查會點名標記的那類缺口。
你能定製的是措辭，而不是發送行為本身。DocuSign 帳戶可以透過品牌設定中的郵件資源檔定製「Envelope Voided」郵件範本，調整主旨行和正文。這對語氣和本地化有用，但它不是抑制機制，也沒有任何文件記載的 API 級開關可以對單次作廢呼叫跳過通知。
不發作廢郵件也能取消或擱置 envelope 的四種方法
既然已發送 envelope 的作廢郵件無法抑制，替代方案就全部落在 envelope 生命週期的其他時點上。實務中有效的是以下四種。
1. 在發送之前刪除草稿。 草稿狀態的 envelope（status 為 created）從未觸碰過任何收件人的信箱，丟棄它不會通知任何人。不要以已發送狀態直接建立 envelope，而是先建成草稿，等系統驗證完一切——收件人信箱、文件、合併欄位、路由順序——再把它翻轉為 sent。狀態變更用的仍是同一個 PUT 端點，請求內文為 "status": "sent"。這種「草稿優先」模式是性價比最高的整合可靠性改造之一，因為你的應用完全掌控發送的那一刻。
2. 用更正代替作廢。 如果問題只是收件人信箱裡的一個錯字、缺一個欄位、或路由順序錯了，更正（correct）操作就是為這種場景設計的。更正會就地修改進行中的 envelope：尚未操作的收件人直接基於更新後的版本繼續，envelope 的 ID 和歷史都保留。沒有作廢，自然沒有作廢郵件。代價是：只有發送方或擁有者可以更正；更正僅在 envelope 仍進行中時可用；資訊被改動的收件人會收到一封帶新連結的新郵件；已通過身份驗證的收件人在更正後可能需要重新驗證。如果你的系統現在遇到任何小問題都作廢重發，改用更正能同時消除噪音和浪費的 envelope。
3. 暫停工作流程，而不是取消。 當問題在於時機而非內容時，暫停工作流程可以把 envelope 停在原地而不終結它。envelope 可以設定為在到達某個路由順序之前暫停，暫停中的 envelope 之後可以透過把工作流程 status 設回進行中來恢復。尚未輪到的收件人根本還沒被啟動，所以沒有人會對著一個死連結等待。內部審批卡住、法務審查要花一週、簽署人主動要求延期——這些場景都適合用它。
4. 把取消決策收進你自己的系統。 對 API 驅動的產品來說，最穩健的模式是把電子簽署平台當作執行層，把取消狀態留在自己的應用裡。透過 webhook 追蹤 envelope 狀態，在你自己的 UI 裡展示「本系統已取消」的狀態，只有當 envelope 確實需要終結時才呼叫真正的作廢操作。多數情況下，務實的答案是：在發送之前做決定。配合草稿優先模式，大量「我們需要安靜取消」的工單，最後都會變成「我們其實只需要在發送前多做一道驗證」。
要警惕一個誘人的捷徑：刪除一份已經進行中的 envelope 並不等於安靜取消。刪除進行中的 envelope 會觸發作廢流程，那封你正想避開的通知照樣發出。安靜刪除只是草稿階段的特權。
在自動化流程裡作廢任何 envelope 之前，還值得先把它當前的狀態和表單資料拉取下來存檔，因為作廢之後再也無法更正——相關端點可先備好，需要時一鍵匯出。
更正、作廢、刪除還是暫停：選對 envelope 操作
值得注意的規律：發送之前採取的一切動作都是靜默的，發送之後採取的一切動作都會告訴收件人一些事。上面所有替代方案的設計，全部建立在這種不對稱之上。
API 驅動流程的作廢前檢查清單
在你的程式碼發出任何作廢呼叫之前，先過一遍這份清單：
- 確認 envelope 確實處於進行中。草稿應當刪除，已完成的 envelope 根本無法作廢。
- 檢查問題能否用更正解決。信箱寫錯或缺欄位，幾乎總是意味著更正，而不是作廢。
- 檢查問題是否出在時機上。暫停工作流程可能比作廢重發便宜得多。
- 備份你需要的東西。作廢前提取文件、tab 資料和你關心的狀態歷史，因為之後 envelope 無法更正，也無法重用。
- 寫一條對收件人得體的
voidedReason，控制在 200 個字元以內——收件人會在通知郵件裡逐字讀到它。 - 在應用中要求明確確認後才允許呼叫作廢，避免自動重試迴圈或一次誤點取消掉一筆進行中的交易。
- 在你自己的系統裡記錄這次作廢，連同 envelope ID 和原因，讓你的審計軌跡與 DocuSign 的紀錄對齊。
用 Nota Sign 降低取消-重發成本
每一輪作廢重發，都意味著為一份協議付兩次錢：一次給死掉的 envelope，一次給它的替代品。能避開這筆成本的工作流程設計，正是 Nota Sign——FaDaDa（法大大）打造的全球電子簽署平台——與整合團隊協作的核心：從更正優先的發送模式，到貼合你的交易對手真實回應方式的生命週期規則，再從靠近簽署人的區域資料中心交付。
中端市場和企業級團隊可以圍繞自己發送、更正、取消的實際方式商定定製方案，而不是硬塞進一個固定的 envelope 計費模型。如果作廢已經在你的整合裡變成日常操作，聯絡我們的團隊，聊聊如何重構這條流程。
