我使用嵌入式签名。要获得签名仪式URL,我调用POST Recipient View方法。该方法采用一些信息组合来匹配该信封中的签名者以生成URL。在电子邮件和 userName 字段中,文档说明:
您可以使用email和userName或userId来识别 收件人。
在 userId 字段中,文档说明:
您可以使用userId或email和userName来识别 接受者。如果使用userId并提供了clientUserId,则 userId必须与recipientId匹配(可以使用GET检索 收件人致电)信封。如果使用userId和a 没有提供clientUserId,userId匹配userId 验证用户。
我认为在第二段中有一个拼写错误,它应该说" clientUserId"而不是" userId。"无论哪种方式,要点似乎是如果我想使用userId并且可以将其匹配到信封上的收件人GUID,我应该能够做到而不是电子邮件/用户名。
然而,当我尝试这个时,它不起作用。我收到这个错误:
{
"errorCode": "INVALID_REQUEST_PARAMETER",
"message": "The request contained at least one invalid parameter. A value was not found for parameter 'userName'."
}
一旦我开始传递userId,就会出现此错误,无论我是否实际在主体中传递userName,或者我只是将其作为空字符串传递,它都会被抛出。这是我的要求机构:
{
"authenticationMethod": "email",
"returnUrl": "<my URL>",
"clientUserId": "<my client userId>",
"userId" : "<xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>"
}
我已经验证userId确实与收件人的Guid匹配(如果没有,我会收到不同的错误)。我尝试过以各种不同的方式向身体添加电子邮件和用户名,没有任何区别。我如何通过userId和clientUserId获取URL?
我想要这样做而不是使用电子邮件/用户名的主要原因是我们发现当人们在&#34;采用您的签名&#34;提示(例如:添加中间的首字母),它会更改&#34; signatureName&#34;在幕后的领域。而且,signatureName字段显然实际上用于与&#34;用户名进行比较。&#34;这意味着如果我总是为&#34;用户名&#34;发送一件事。 (这是我在他自己的系统中为他们提供的名称)但是DocuSign已将他们的签名名称保存为不同的名称(该名称带有中间名称),他们永远不会匹配,这意味着DocuSign将始终将其视为新用户,他们将被迫为每个文档重新采用该签名,这在我们必须连续签署多个文档的用例中造成了非常糟糕的体验。
我能想到的唯一解决方法是在信封上执行GET以检索signatureName,但由于多种原因这很笨拙,尤其是它目前没有内置到API库版本I& #39; m using。
我已经看到了其他各种问题,但到目前为止我还没有看到有人成功地做过这件事。似乎大多数人都只是使用电子邮件/用户名组合。
有没有人能够成功接到此电话使用此组合?
编辑:这是GET请求对该信封的看法。请注意,我尝试在userID POST调用中同时使用recipientID和userId,但都不起作用。
{
"signers": [
{
"signatureInfo": {
"signatureName": "John A. Smith",
"signatureInitials": "JAS",
"fontStyle": "docusign7"
},
"isBulkRecipient": "false",
"name": "John Smith",
"email": "noreply@somewhere.com",
"recipientId": "1",
"recipientIdGuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxb4f4",
"requireIdLookup": "false",
"userId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx8dc3",
"clientUserId": "JSMITH",
"routingOrder": "1",
"note": "",
"roleName": "Employee",
"status": "delivered",
"deliveredDateTime": "2016-03-13T16:08:58.9100000Z"
}
],
"agents": [],
"editors": [],
"intermediaries": [],
"carbonCopies": [],
"certifiedDeliveries": [],
"inPersonSigners": [],
"recipientCount": "1",
"currentRoutingOrder": "1"
}
答案 0 :(得分:3)
我创建了一个带有嵌入式签名者的信封,并使用了信封/ {envelopeID} / recipients /的GET请求,它返回了我的收件人的userId,我的POST收件人视图的正文是
{
"clientUserId":"1",
"authenticationMethod": "email",
"returnUrl":"http://google.com",
"userId":"{userId guid from GET} ,
}
并正确地恢复了网址。
答案 1 :(得分:0)
我通过一个新的信封重新开始工作。我认为我的问题最初没有意识到userId对每个信封都是唯一的。而这个事实并没有解决我原来的问题,这个问题需要一种方法来重复识别他们名字之外的签名者,如果他们在提示时改变了默认签名,这显然会发生变化。无论您如何分割,如果他们更改了默认签名,那么新名称将成为与该修改后的签名相关联的名称,如果您需要,那么您需要为未来的文档发送该名称能够使用相同的签名而不必重新采用它。
所以考虑到这一点,我有另一个解决方案。当此人修改默认签名名称并签署他们的第一个文档时,我将在之后查询该信封,并检查该名称是否与我在系统中的名称有所不同。如果它不同,我会存储他们使用的那个,这样我就可以将它们发送给他们签署的任何未来的文档,以便他们可以重复使用它。