Skip to main content

Previously, the Get Box Sign request by ID endpoint at https://api.box.com/2.0/sign_requests/**:sign_request_id** would return a filled in document_tag_id if one existed, as shown at https://developer.box.com/reference/get-sign-requests-id/


e.g.



  "inputs": [

{

"document_tag_id": "1234",

"text_value": "text",

"checkbox_value": true,

"date_value": "2021-04-26",

"type": "text",

"content_type": "signature",

"page_index": 4,

"read_only": true

}



However, now document_tag_id is always null for all inputs on sign requests made June 13th and after. Prior to that (June 12th and before) those requests seem to be functioning correctly still and returning document_tag_id as expected.



My assumption would be this is just a bug that was introduced in the API endpoint?



Expected behavior: document_tag_id is not null


Actual: document_tag_id is null

Noting simple steps to reproduce this. I’ve filed a support ticket as well back on Friday but no response yet.



#1. Create a PDF document to use as the Box Sign Template, it will contain only the following HTML:



    <div style="width:200px; display:inline-block;">Name: </div>

<div style="width:150px; display:inline-block; text-decoration: underline; border-bottom:1px solid black; text-decoration-color: black; color: white; font-size:14px;">t;t|0|id:personname ]]

</div>

</div>

<br><br>

<div style="min-width:250px; display:inline-block;">

Signature <span style="color: white; text-decoration-color: black; text-decoration: underline; font-size: 16px;">t;s|0 ]]</span>

</div>



Upload that template file into Box.



#2. Create a sign request using that PDF template, this can be done either via an API call to https://developer.box.com/reference/post-sign-requests/ or directly in the User Interface on Box.com using “Request Signature”



#3. Send the request to the signer and have signer complete the request.



#4. Make a call to Box Sign API to get the completed Sign Request via https://developer.box.com/reference/get-sign-requests-id/


/sign_requests/{sign_request_id}



#5 See that document_tag_id is empty on the two fields, even though “id” was explicitly set in the template as seen in the HTML above. document_tag_id should be depositbwrname but instead is NULL



This worked perfectly fine prior to sometime on June 12th or June 13th when document_tag_id started coming back as null for newly created sign requests that use Box Sign Template tags.


Just noting, creating the template manually via the UI and setting an external id results in the subsequent sign request having the document_tag_id, it seems to only be broken for sign requests that were created from template files which were hand-created and uploaded. All this worked fine though prior to June 13th or so.


I have the same issue. Any news about the fix?


Reply