如何通过DocuSign REST API实现单URL多签署人嵌入式签名

• 开发适配桌面/笔记本、平板、移动端的响应式Web应用，需支持终端客户完成销售合同PDF签署，计划基于DocuSign REST API实现多签署人嵌入式签名（Embedded Signing）
• 预期业务流程：
  1. 经销商对接售方，由售方完成签署
  2. 经销商对接付款方，由付款方完成签署
  3. 经销商完成最终签署后，所有签署人通过邮件收到已签署完成的文档
• 当前开发进展：
  1. 已成功生成第一位签署人的签名URL，第一位签署人完成签署后可正常跳转回自有Web页面
  2. 尝试复用第一位签署人的URL供第二位签署人签署时，页面直接重定向回自有Web页面，无法进入签署流程
• 核心疑问：
  是否可以不为售方、付款方、经销商分别生成3个独立的recipients view，仅打开一个签署视图搭配手机身份验证，就实现所有签署人通过单个签名URL完成手机验证后依次走完签署流程。此前曾尝试配置单个接收人对应3个签名框并开启手机验证，但第一位签署人完成签署后页面直接跳转回主网页，无法继续后续签署。个人推测该方案无法实现，理由是每个envelope id似乎仅对应单个签署人会话，多个签署人使用同一个envelope id签署同一份文档、填写不同内容，无法保障各签署方签名的完整性，需要明确的技术解答。

你的推测完全正确，DocuSign原生不支持单个嵌入式签名URL供多个不同签署人依次完成签署，不存在可直接实现该需求的配置方案，核心原因如下：

• 嵌入式签名生成的recipient view URL和具体的recipientId强绑定，每个URL仅对应当前envelope下的一个指定签署人。签署人完成自身签署动作后，该recipient对应的签名会话就会直接结束，触发预设的跳转逻辑，这就是你复用第一个签署人URL时直接跳回自有站点的根本原因——系统判定该绑定的签署人已经完成签署动作，不会再加载签署流程。
• 你尝试的「单个接收人对应3个签名框+手机验证」方案不符合DocuSign的签署人身份校验逻辑：单个recipient在DocuSign的定义里就是同一个法律主体，就算配置多次手机验证，系统也只会判定为同一个签署人的多次身份校验，不会识别为三个独立的签署主体。第一个签名动作完成后，该recipient的签署义务就会被判定为履行完毕，自然直接结束会话触发跳转。
• 从合规和签名有效性层面，DocuSign的签名审计日志会把同一个recipient下的所有签名动作都归到同一个主体名下，就算前端自行做了三次手机验证，最终生成的合同审计轨迹也只会显示一个签署人完成了所有签名，不满足售方、付款方、经销商三个独立主体分别签署的法律效力要求，也无法保障各签署方签名的可溯源、不可篡改特性。

要实现你描述的依次签署流程，必须按照签署顺序为每个签署人生成独立的嵌入式签名URL，标准实现逻辑如下：

1. 创建envelope时，按照业务流程给三个签署人设置routingOrder参数：售方设为1，付款方设为2，经销商设为3，同时给每个签署人配置对应的签名框、身份验证方式（比如你需要的手机短信验证），配置签署完成后的跳转地址。
2. 流程启动后，首先调用createRecipientView接口，传入售方对应的recipientId生成第一个签署URL，引导售方完成签署。
3. 监听DocuSign的webhook回调（或者在跳转回自有站点后主动查询envelope状态），确认售方（routingOrder=1）签署完成后，再调用接口传入付款方的recipientId生成第二个签署URL，引导付款方完成签署。
4. 重复上述逻辑，等付款方签署完成后，再生成经销商对应的第三个签署URL，引导经销商完成最终签署。
5. 所有签署人完成签署后，DocuSign会自动按照配置规则给所有签署人发送已签署完成的合同邮件，不需要额外开发触发逻辑。

不要尝试通过前端篡改会话、共用URL的方式绕开这个限制，一方面会直接导致签名流程报错、签署记录丢失，另一方面会直接影响电子签名的法律效力，出现合同纠纷时无法作为有效举证材料。

内容的提问来源于stack exchange，提问作者Bal mukund kumar