2026年8月28日
簡短答案：用 EnvelopeRecipients:update 加 resend_envelope=true
DocuSign eSignature REST API v2.1 並沒有專用的 POST /recipients/{recipientId}/resend 端點。部分第三方部落格文章和 AI 生成的片段引用過它，但官方的 EnvelopeRecipients 資源文件中並不存在這個端點——基於任何端點開發前，請先對照官方 API 參考文件或在你的沙盒中核實。向指定簽署人重發簽署信封通知的官方做法，是在收件人更新呼叫上加一個查詢參數：
```
PUT /restapi/v2.1/accounts/{accountId}/envelopes/{envelopeId}/recipients?resend_envelope=true
```
請求主體中列出你要再次通知的簽署人——以 recipientId 識別——只要簽署信封仍在進行中，而該收件人尚未完成其操作，DocuSign 便會向該收件人發出全新通知。如果你想一次過提醒所有待處理收件人，DocuSign 記載了一個更簡單的替代方案：對簽署信封呼叫 Envelopes:update，帶上 resend_envelope=true 和空白請求主體。以下兩種模式均直接出自 DocuSign 自家的開發者資料。
resend_envelope 如何把通知路由給指定收件人
resend_envelope 查詢參數是一個布林標誌，可用於兩個端點，其記載的含義在兩者之間一致：設為 true 時，簽署信封會被重發給尚未完成操作的收件人。而決定哪些收件人會收到你通知的，是請求主體。
使用 EnvelopeRecipients:update（PUT .../envelopes/{envelopeId}/recipients?resend_envelope=true）時，你提交一個 recipients 物件——最常見的是 signers 陣列——每個條目給出 recipientId，以及 DocuSign 在更新時要求的 name 和 email。只有你列出的收件人才會成為目標。當某位簽署人遺失了電郵、遲遲沒有動靜，或需要查看更正後的文件，而路由順序中的其他人不應再受打擾時，就應使用這個呼叫。
使用 Envelopes:update（PUT .../envelopes/{envelopeId}?resend_envelope=true，請求主體為空的 {}）時，DocuSign 會重發給所有待處理收件人——即所有尚未操作、正在排隊等候該簽署信封的人。DocuSign 開發者部落格關於更新後重發電郵通知的文章推薦這個變體，原因正是：當你不需要按收件人逐個定向時，它更簡單。
兩條存取規則同時約束這兩個呼叫。你只能重發你的整合有權存取的簽署信封——你自己發送的，或透過 Shared Access 共享給你的，正如 DocuSign 常見 API 任務指南所述。而且重發只會觸及下一個待操作的收件人；它會重發與原始通知相同的電郵（如已配置該渠道，亦包括 SMS）。
重發之前先找出簽署人的 recipientId
要定向某位簽署人，前提是你掌握該簽署人的 recipientId——一個由呼叫方定義的識別碼，在簽署信封內唯一，是你在建立簽署信封時指定的。它既不是簽署人的電郵，也不是 DocuSign 內部的 userId。標籤（tab）和欄位同樣錨定在 recipientId 上，這正是按收件人維度的數據操作——例如從已簽署文件提取標籤與表單數據——同樣以 recipientId 為鍵的原因。
如果你在發送簽署信封時沒有保存這些 ID，可以用 EnvelopeRecipients:list 取回：
```bash
curl -s "{baseUrl}/restapi/v2.1/accounts/{$ACCOUNT_ID}/envelopes/{$ENVELOPE_ID}/recipients" \
--header "Authorization: Bearer {$ACCESS_TOKEN}" \
--header "Accept: application/json"
```
回應會按類型分組收件人（signers、carbonCopies 等）。對每位簽署人，讀取 recipientId、routingOrder、status、name 和 email。有三個欄位決定你是否該重發：
- recipientId —— 你將在重發請求主體中回傳的識別碼。
- status —— 已經
completed的簽署人從重發中得不到任何好處；你要找的是尚未完成、處於sent或delivered狀態的收件人。 - routingOrder —— 尚未輪到的簽署人根本未曾收到簽署信封，所以定向重發的目標是當前正在處理的那個路由順序。
先重發給一位簽署人，再重發給全部待處理收件人
以下是定向重發，遵循 DocuSign 記載的示例。請求主體更新指定簽署人，並因 resend_envelope=true 觸發一封發給該簽署人的新通知：
```bash
curl -s --request PUT \
"{baseUrl}/restapi/v2.1/accounts/{$ACCOUNT_ID}/envelopes/{$ENVELOPE_ID}/recipients?resend_envelope=true" \
--header "Authorization: Bearer {$ACCESS_TOKEN}" \
--header "Content-Type: application/json" \
--data-raw '{
"signers": [
{
"recipientId": "1",
"name": "Bob Zhang",
"email": "bob.zhang@example.com",
"note": "The document was updated — please review and sign."
}
]
}'
```
note 屬性值得了解。DocuSign 開發者部落格指出，簽署信封一旦發出，電郵主旨和內文便無法更改，但你可以透過 note 為每位收件人留下一則私人訊息，收件人會在電郵通知中看到這則訊息。這是自訂重發內容的唯一實用方式。多收件人簽署信封中，收件人層級的可見性規則相當微妙——CC 收件人與私密欄位值得單獨研究亦出於同樣原因——所以在生產環境依賴 note 之前，請先在沙盒中測試。
再看廣播變體，適用於需要提醒所有待處理收件人的場景：
```bash
curl -s --request PUT \
"{baseUrl}/restapi/v2.1/accounts/{$ACCOUNT_ID}/envelopes/{$ENVELOPE_ID}?resend_envelope=true" \
--header "Authorization: Bearer {$ACCESS_TOKEN}" \
--header "Content-Type: application/json" \
--data '{}'
```
DocuSign 開發者 FAQ 確認了這個確切模式——envelopes 端點加 resend_envelope=true 和空白請求主體——是以程式方式重發的標準做法。遇到任何非 2xx 回應，都應視為先重新檢查簽署信封狀態和權限再重試的訊號；具體的錯誤行為因帳戶配置而異，請在你的沙盒中確認。
重發改變不了什麼：狀態、內容與投遞規則
重發機制被刻意設計得很窄。了解它的邊界能節省除錯時間：
- 簽署信封狀態決定一切。 處於
draft、voided或completed狀態的簽署信封無法重發。簽署信封必須仍在進行中、等候下一批收件人。 - 已完成的簽署人不在範圍內。 重發通知的是仍需操作的收件人。如果某位簽署人經已完成，其證據留存在完成紀錄中——當中記錄了什麼，可參閱 DocuSign 完成證明書。
- 電郵主旨與內文是凍結的。 只有按收件人的
note能加入新的可見文字。 - 原始電郵依然有效。 收件人可以透過原始通知進入簽署信封；重發只是提醒它仍在等候。文件更正之後，重發才是明確的觸發器——更正簽署信封並不會自動通知任何人，即使啟用了「發送人更正簽署信封」的帳戶設定亦然。
- 嵌入式簽署人是另一條路徑。 為嵌入式簽署而以
clientUserId建立的收件人，按設計不接收電郵通知；重發是遙距簽署的概念。
如果簽署信封攜帶的文件在發送後有所變更，請緊記 DocuSign 記載的更新已發送簽署信封工作流程是：鎖定簽署信封、更新文件或標籤、解鎖，然後重發通知。跳過鎖定，你的整合、發送人和收件人之間便有並發編輯衝突的風險。
重發還是提醒？跟進工作流程決策表
臨時重發只是三種工具之一。選錯工具，團隊便會要麼滋擾簽署人，要麼無聲地無限等候：
提醒那一行藏著大多數團隊都會踩中的陷阱：透過 API 建立、未帶 notification 物件的簽署信封，會採用 API 預設值——120 天到期、完全沒有提醒——無論帳戶的網頁 UI 設定為何。DocuSign 關於 API 預設提醒與到期設定的說明文章對此直言不諱：要獲得預設值以外的任何行為，你必須在 API 呼叫中明確指定，可以按簽署信封設定（reminderEnabled、reminderDelay、reminderFrequency），亦可設定 useAccountDefaults: true。為 API 簽署信封而設的重發跟進功能並非「錦上添花」——對許多整合而言，它是唯一會真正觸發的提醒機制。
發送量是另一個規劃輸入。每一次重發都是一次消耗計劃額度的 API 呼叫，而跟進自動化對呼叫次數的放大速度遠快於單純的發送——API 速率限制與定價比較背後正是同樣的邏輯。把重發納入你的呼叫量模型預算，而不是等到高峰期才發現。
讓跟進能力隨發送量而非席位擴展：Nota Sign
當提醒邏輯由偶爾執行的腳本，變成產品的核心部分，會帶來什麼改變？平台不再只是一個供應商選項，而是架構的一部分——它的定價模式、合規覆蓋、在你的量級下的 API 行為，全都成為架構決策。
Nota Sign 是 FaDaDa 的全球電子簽名平台，正是為這種轉變而建。FaDaDa 連續多年位居 IDC 中國電子簽名軟件市場第一，平台的優勢與自動化發送逐項對應：在 100 多個國家和地區具備法律效力，意味著重發的通知在每個市場都具有同等分量；APAC 合規縱深——Singpass、iAM Smart、SES/AES/QES、區域數據中心——覆蓋了跨境產品往往很晚才補上的身份層；而不設按席位收費，每次自動提醒都隨文件量而非人數擴展——對小型團隊友好，並為中端市場和企業買家提供度身訂造的方案。
我們的 API 驅動簽署工作流程開發者指南展示了整合面。當你準備按照自己的發送量測試提醒與重發行為時，與我們聯絡。
