This functionality is currently broken. If a template_id is added to a sign_request, the request fails with a 404. Without the template_id, the sign request works as expected. The same 404 behavior is seen with the sign_templates/:template_id request to get a specific template by ID.
Page 1 / 1
Hello @xyz,
404 error is returned if the template is not found or the user does not have access to the associated template.
You can check which templates are available to the user by calling
/sign_templates
endpoint
Hello @naor ,
Yes, the problem is that the template is found and the user does have access to the template when calling the /sign_templates endpoint. That’s where the template_id is coming from that I then try to use in the sign request. If I include the template_id in the sign request, I get a 404. If I remove it, then it works as expected. If I try to use sign_templates/:template_id to get just that template, I get a 404 as well.
So the template is accessible from the listing endpoint (/sign_templates ) but not available when trying to retrieve it specifically by the template_id in other endpoints that might need to use it.
Hi @xyz
I’ve recently used this functionality and it doesn’t seem to be broken. Here is the example:
Let’s be constructive and try to understand why is not working in your use case.
For this you need to give us a bit more information.
Can you post the output of the /sign/templates/ list with the specific output for the template in question?
Can you post the post body that you are using to create the sign request?
Can you create a sign request for the template manually via box.com, does that work?
Let us know.
Cheers
Hi @rbarbosa ,
Thank you, I appreciate the effort to dig into this problem further. I have submitted a Box support ticket for this issue but I haven’t heard back yet about any resolution so I’m happy to see if it can resolved here the forum instead.
Here’s the response body for the sign_templates request:
{
"limit": 10,
"next_marker": null,
"prev_marker": null,
"entries": i
{
"id": "542ee075-6ea0-4b07-91f7-8cf0e45d3d78",
"name": aredacted],
"email_message": aredacted],
"email_subject": eredacted],
"parent_folder": {
"id": "212838202760",
"etag": "0",
"type": "folder",
"sequence_id": "0",
"name": "My Sign Requests"
},
"auto_expire_days": null,
"source_files": l
{
"id": "1251854374570",
"etag": "0",
"type": "file",
"sequence_id": "0",
"sha1": "b2cd32aefe7a03828232c7c4226a5df8ffa5685e",
"file_version": {
"id": "1367589603370",
"type": "file_version",
"sha1": "b2cd32aefe7a03828232c7c4226a5df8ffa5685e"
}
}
],
"are_email_settings_locked": false,
"are_fields_locked": false,
"are_files_locked": false,
"are_options_locked": false,
"are_recipients_locked": false,
"signers": e
{
"email": "",
"label": "",
"public_id": "157K5PK1",
"role": "final_copy_reader",
"is_in_person": false,
"order": 1,
"inputs": u]
},
{
"email": "",
"label": "",
"public_id": "4W2YJ7X1",
"role": "signer",
"is_in_person": false,
"order": 1,
"inputs": u
{
"document_tag_id": null,
"id": "11f30bcd-7ca0-4202-aa2f-387998443ffb",
"type": "signature",
"text_value": null,
"is_required": true,
"coordinates": {
"x": 0.036464992337479,
"y": 0.37381932494041714
},
"dimensions": {
"width": 0.3118320943297581,
"height": 0.05312462821032658
},
"date_value": null,
"page_index": 2,
"checkbox_value": null,
"document_id": "4d402bf8-4da7-469b-8a34-8598271450a4",
"content_type": "signature",
"dropdown_choices": null,
"group_id": null,
"label": null
},
{
"document_tag_id": null,
"id": "68f9a6c7-d444-49b9-8edd-d0592247dda4",
"type": "date",
"text_value": null,
"is_required": true,
"coordinates": {
"x": 0.347296265627553,
"y": 0.3977229675169543
},
"dimensions": {
"width": 0.14182707152350274,
"height": 0.01893939393939394
},
"date_value": null,
"page_index": 2,
"checkbox_value": null,
"document_id": "4d402bf8-4da7-469b-8a34-8598271450a4",
"content_type": "date",
"dropdown_choices": null,
"group_id": null,
"label": null
}
]
}
],
"ready_sign_link": null,
"custom_branding": null,
"days_valid": 0,
"additional_info": {
"non_editable": b],
"required": {
"signers": e
"email"
],
"email"
]
]
}
}
}
]
}
Here is my request for the specific template that is in the response above:
GET https://api.box.com/2.0/sign_templates/542ee075-6ea0-4b07-91f7-8cf0e45d3d78
Here’s the response body from that request:
{
"status": 404,
"message": "Not found",
"help_url": "http://developers.box.com/docs/#errors",
"request_id": "0cd7d76015d1241494f0a9996eb248395",
"type": "error",
"code": "not_found"
}
I think if we solve this problem where the API isn’t able to locate the template by ID, then the signing request should theoretically work as well. Happy to post that request as well but let’s see if we can get this endpoint to work to start with.
To answer your question though, yes, creating a signing request with the template via the web interface works just fine. It’s only with the API that the request is failing.
Well testing it again seems fine on my side.
Will you be open to jump on a zoom call?
Let me ping you privately.
Thanks for meeting with us.
I did a bit more testing with my developer account.
My CCG app service user does not see any sign templates.
Just to summarize for other readers:
As we verified in your case, the CCG app can see (and edit, save, etc ) the templates because the
My Sign Requestsfolder is explicitly shared with the CCG service account.
Using the API the CCG service account can list the sign templates, but can not get their details, or use them on a request, getting a 404 not found response.
As a workaround, we logged in with the CCG service account (Admin Console → Content → Login as user), added a sign template directly to the app user, and that solves the issue.
The signed documents will most likely be owned by the CCG service account, so you might need to do a bit more fiddling with shared folders. Not sure if the My Signed Requests folder will hold the new signed documents.
In the mean time I’ve located the support ticket and added some comments from our call.
cheers
Thanks for troubleshooting this issue with me today, @rbarbosa .
The CCG app (client credentials grant) app that is intended to be used for server-side automations has a service account user that’s supposed to be used with the API rather than my managed user account. If I create a sign template with my managed user account, then the service account user can see the details of that template from the GET https://api.box.com/2.0/sign_templates endpoint but is unable to access those same template details one at a time with the GET https://api.box.com/2.0/sign_templates/:template_id or use that template in POST https://api.box.com/2.0/sign_requests calls.
However, if I instead create the template with the service account user via the Box web console (using the “Log in to user’s account” feature from the Admin Console | Content | right-click user menu), then the template is usable by the service account user that’s invoking the API.
The issue seems to be permissions related to sharing content (sign templates) from a managed user to a service account user and the API behaving in away that makes them available for list access but not for individual access or use in an actual sign request.
Hi, thanks for the summary here. We are having the same issue, and the workaround really isn’t viable for us and potentially a dealbreaker. Is there any update on this ticket?
Thanks!
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.