让我的信封如下:
{
"allowReassign": "false",
"documents": [
{
"documentBase64": "JVBE",
"documentId": "1",
"fileExtension": "PDF",
"name": "DocumentToNotarize"
}
],
"emailSubject": "Notary Test",
"enableWetSign": "false",
"notification": {
"expirations": {
"expireAfter": "4",
"expireEnabled": "True"
}
},
"recipients": {
"inPersonSigners": [
{
"email": "signer@domain.com",
"inPersonSigningType": "notary",
"name": "Signer",
"notaryHost": {
"deliveryMethod": "email",
"email": "notary@domain.com",
"name": "Notary",
"recipientId": "995a0019-f0bc-47bf-94d5-426607388f7b",
"tabs": {
"notarizeTabs": [
{
"documentId": "1",
"pageNumber": "1",
"xPosition": "100",
"yPosition": "100"
}
]
}
},
"recipientId": "3fa6ffaf-f87e-4f27-9129-6d12d987f59b",
"tabs": {
"signHereTabs": [
{
"documentId": "1",
"pageNumber": "1",
"recipientId": "3fa6ffaf-f87e-4f27-9129-6d12d987f59b",
"scaleValue": "0.6",
"xPosition": "45",
"yPosition": "527"
}
]
}
}
]
},
"status": "sent"
}
哪个会触发以下错误:
{
"errorCode": "NOTARY_HOSTED_SIGNER_ID_REQUIRED",
"message": "The host signer Id is required to associate with notary in person signer."
}
令人惊讶的是,我发现如果我仅将签名者的receiverId更改为如下所示的整数,它将起作用! 我想念什么吗?允许使用GUID对吗?
"recipientId": "3",
"tabs": {
"signHereTabs": [
{
"documentId": "2",
"pageNumber": "1",
"recipientId": "3",
"scaleValue": "0.6",
"xPosition": "45",
"yPosition": "527"
}
]
}
}
答案 0 :(得分:1)
令人惊讶地发现,如果我仅将签名者的receiveId更改为如下所示的整数,它就可以工作!我想念什么吗?允许使用GUID对吗?
如果在使用整数时可以使用,那么我建议您使用整数。
如果您想将带有收件人的GUID作为元数据存储,以便以后可以从信封中检索,请使用customFields
对象的signer
属性。
答案 1 :(得分:0)
对于大多数API调用,因为大多数收件人类型并不依赖于另一个收件人,所以为接收者ID设置GUID没问题。
此处的公证人问题是,公证人和签署人收件人是由receiveId关联的,并且API逻辑被设计为将接收方ID解析为Int,这很可能引起了问题。如果使用亲自签名,也会遇到相同的问题,因为这是非常相似的过程,其中主机和亲自签名者是单个收件人。