POST 收件人视图:使用 clientUserId + userId
POST Recipient View: Using clientUserId + userId
我正在使用嵌入式签名。为了获得签约仪式URL,我调用了POST Recipient View方法。该方法采用一些信息组合来匹配该信封中的签名者以生成 URL。在 email 和 userName 字段中,文档指出:
You can use either email and userName or userId to identify the
recipient.
在 userId 字段中,文档指出:
You can use with userId or email and userName to identify the
recipient. If userId is used and a clientUserId is provided, the
userId must match a recipientId (which can be retrieved with a GET
recipients call) for the envelope. If userId is used and a
clientUserId is not provided, the userId match the userId of the
authenticating user.
我认为第二段中有一个拼写错误,它应该说 "clientUserId" 而不是 "userId." 无论哪种方式,要点似乎是如果我想使用 userId 并且可以匹配它直到信封上的收件人 GUID,我应该能够做到这一点,而不是 email/username。
但是,当我尝试这样做时,它不起作用。我收到此错误:
{
"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?
我想这样做而不是使用 email/username 的主要原因是我们发现当人们在 "Adopt Your Signature" 提示符下更改他们的名字时(例如:添加中间名首字母),它在幕后更改了 "signatureName" 字段。那个 signatureName 字段显然是实际用来与 "username." 进行比较的字段,这意味着如果我总是为 "username" 发送一件东西(这是我自己系统中的名称),但 DocuSign 有将他们的签名名称保存为不同的名称(该名称带有中间首字母),它们永远不会匹配,这意味着 DocuSign 将始终将其视为新用户,并且他们将被迫为每个文档重新采用该签名,这在我们必须连续签署多个文档的用例中,这会带来非常糟糕的体验。
我能想到的唯一解决方法是在信封上执行 GET 以检索 signatureName,但由于多种原因,这很笨拙,尤其是目前 API 库中没有内置它我正在使用的版本。
我已经看到了与此相关的各种其他问题,但到目前为止,我还没有看到任何人成功地做到了这一点。似乎大多数人都恢复到只使用 email/username 组合。
有没有人能够成功地让这个电话与这个组合一起工作?
编辑:这是该信封的 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"
}
我创建了一个带有嵌入式签名者的信封,并使用了 envelopes/{envelopeID}/recipients/ 的 GET 请求,它返回了我的收件人的 userId,我的 POST 收件人视图的正文是
{
"clientUserId":"1",
"authenticationMethod": "email",
"returnUrl":"http://google.com",
"userId":"{userId guid from GET} ,
}
并正确取回 URL。
我用一个新的信封重新开始让它工作。我认为我的问题最初是没有意识到 userId 对于每个信封都是唯一的。这个事实并没有解决我最初的问题,我需要一种方法来重复识别他们名字之外的签名者,如果他们在提示时改变默认签名,这显然会改变。无论您如何划分,如果他们更改了默认签名,新名称将成为与修改后的签名相关联的名称,如果您希望他们能够使用相同的签名,那么这就是您需要为将来的文档发送的名称无需重新采用它。
考虑到这一点,我有另一个解决方案。当此人修改默认签名名称并签署他们的第一个文档时,我将在之后查询该信封并检查该名称是否与我在我们系统中的名称不同。如果不同,我会存储他们使用的那个,这样我就可以将其发送给他们签署的任何未来文档,以便他们可以重复使用它。
我正在使用嵌入式签名。为了获得签约仪式URL,我调用了POST Recipient View方法。该方法采用一些信息组合来匹配该信封中的签名者以生成 URL。在 email 和 userName 字段中,文档指出:
You can use either email and userName or userId to identify the recipient.
在 userId 字段中,文档指出:
You can use with userId or email and userName to identify the recipient. If userId is used and a clientUserId is provided, the userId must match a recipientId (which can be retrieved with a GET recipients call) for the envelope. If userId is used and a clientUserId is not provided, the userId match the userId of the authenticating user.
我认为第二段中有一个拼写错误,它应该说 "clientUserId" 而不是 "userId." 无论哪种方式,要点似乎是如果我想使用 userId 并且可以匹配它直到信封上的收件人 GUID,我应该能够做到这一点,而不是 email/username。
但是,当我尝试这样做时,它不起作用。我收到此错误:
{
"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?
我想这样做而不是使用 email/username 的主要原因是我们发现当人们在 "Adopt Your Signature" 提示符下更改他们的名字时(例如:添加中间名首字母),它在幕后更改了 "signatureName" 字段。那个 signatureName 字段显然是实际用来与 "username." 进行比较的字段,这意味着如果我总是为 "username" 发送一件东西(这是我自己系统中的名称),但 DocuSign 有将他们的签名名称保存为不同的名称(该名称带有中间首字母),它们永远不会匹配,这意味着 DocuSign 将始终将其视为新用户,并且他们将被迫为每个文档重新采用该签名,这在我们必须连续签署多个文档的用例中,这会带来非常糟糕的体验。
我能想到的唯一解决方法是在信封上执行 GET 以检索 signatureName,但由于多种原因,这很笨拙,尤其是目前 API 库中没有内置它我正在使用的版本。
我已经看到了与此相关的各种其他问题,但到目前为止,我还没有看到任何人成功地做到了这一点。似乎大多数人都恢复到只使用 email/username 组合。
有没有人能够成功地让这个电话与这个组合一起工作?
编辑:这是该信封的 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"
}
我创建了一个带有嵌入式签名者的信封,并使用了 envelopes/{envelopeID}/recipients/ 的 GET 请求,它返回了我的收件人的 userId,我的 POST 收件人视图的正文是
{
"clientUserId":"1",
"authenticationMethod": "email",
"returnUrl":"http://google.com",
"userId":"{userId guid from GET} ,
}
并正确取回 URL。
我用一个新的信封重新开始让它工作。我认为我的问题最初是没有意识到 userId 对于每个信封都是唯一的。这个事实并没有解决我最初的问题,我需要一种方法来重复识别他们名字之外的签名者,如果他们在提示时改变默认签名,这显然会改变。无论您如何划分,如果他们更改了默认签名,新名称将成为与修改后的签名相关联的名称,如果您希望他们能够使用相同的签名,那么这就是您需要为将来的文档发送的名称无需重新采用它。
考虑到这一点,我有另一个解决方案。当此人修改默认签名名称并签署他们的第一个文档时,我将在之后查询该信封并检查该名称是否与我在我们系统中的名称不同。如果不同,我会存储他们使用的那个,这样我就可以将其发送给他们签署的任何未来文档,以便他们可以重复使用它。