如何在DocuSign中实现多轮场景下的签署人委托追踪

在不要求客户开放公网端口接收webhook的前提下，可通过组合官方API原生能力+本地链路映射的方式，实现2次及以上委托场景下的关系精准追踪，完全规避已测试方案的局限性：

• 调用信封接收人查询接口时，必须携带include_extended_recipient_details=true请求参数
  该参数返回的扩展字段中，会为每个接收人生成独立的delegatedBy关联记录：每发生一轮委托就对应一条明确的关联关系，不会因二次及以上委托丢失链路节点，也不会因多个原始签署人委托给同一受托人出现关系混淆。该字段的关联维度是接收人实例而非邮箱账号，从根源上解决同个受托人对应多个委托人的匹配冲突问题。
• 本地维护委托有向图，不使用单字段做跨环节匹配
  基于现有API轮询逻辑拉取全量接收人数据时，放弃用recipientId作为唯一匹配键的思路（委托生成新接收人时该字段会重新分配，不具备跨实例一致性），改用envelopeId + routingOrder + 身份标识作为每个接收人实例的唯一键：嵌入式签署场景用clientUserId做身份标识，远程签署场景用name + email做身份标识。
  每次拉取到新的委托记录时，按delegatedBy字段标记的上下级关系在本地图结构中建边，从最终实际签署人节点反向递归即可遍历完整委托链路，直达最原始的签署人。该存储逻辑不对委托参与方做任何去重处理，可直接规避Carbon Copies接口返回去重列表导致的匹配误差。
• 用审计事件字段做链路校验兜底
  拉取信封审计日志时，不要仅读取事件摘要，需解析每个事件携带的eventData完整上下文：每一次委托动作触发时，上下文内会同时留存委托发起方、受托方的接收人实例标识，可直接和本地维护的链路图做交叉校验，避免轮询时机差导致的链路节点遗漏。

注意：签署顺序、自定义recipientId两个字段在委托生成新接收人时，会分别触发按新接收人邮箱重排、ID重新分配的逻辑，本身不具备跨委托环节的一致性，不适合作为链路追踪的匹配依据。

内容的提问来源于stack exchange，提问作者Christoph Siebert