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的全球电子签名平台，正是为这种转变而建。FaDaDa 连续多年位居 IDC 中国电子签名软件市场第一，平台的优势与自动化发送逐条对应：100 多个国家和地区的法律效力，意味着一条重发的通知在每个市场都具有同等分量；亚太合规纵深——Singpass、iAM Smart、SES/AES/QES、区域数据中心——覆盖了跨境产品往往很晚才补上的身份层；而没有按席位计费，每一次自动提醒都随文档量而非人数扩展——对小团队友好，也为中端市场和企业买家提供定制方案。
我们的 API 驱动签署工作流开发者指南展示了集成面。当你准备按自己的发送量测试提醒与重发行为时，联系我们。
