Box Consent Management

Hello,

Recently my Box application was impacted, and more specifically the user of the Box application was impacted because I was not monitoring the consent status of the user for a specific Terms of Service.

As I started development, I found that their either appears to be a misalignment with the Box API or its use of the JSON structure and I am curious if anyone else has come across this, or has been more curious about a users consent history associated with Terms of Service conditions that have been provided and changed.

Below is the chain of API commands needed in order to determine if a user has consented to a Terms of Service that applies to them.

1. List TOS [https://developer.box.com/reference/get-terms-of-services/]
2. Get TOS Status [https://developer.box.com/reference/get-terms-of-service-user-statuses/]
3. Update TOS Status [https://developer.box.com/reference/put-terms-of-service-user-statuses-id/]

I have two questions on the APIs in use here.

1. The TOS is presented as an "entries" array, but it only ever contains a single value. I would expect for the TOS history for a user to contain multiple values, one corresponding for each time the TOS changed in order to see the full consent history of a user. This would show me when the user started consenting (yes we can get this through the existing data) along with all of the times a policy has changed while being a user.
2. Due to the TOS only ever having a single unique ID per user, and because the array does not ever contain more than a single value, I am curious if anyone else struggles with why the TOS Status ID is different than the TOS ID when right now there is no need to have unique values since only one is being presented. Has this thrown anyone else off?

Looking forward to any thoughts or feedback that anyone else on the community has on managing TOS and Consent via the API! I was certainly confused going through this the first time and felt that it might be an unfinished implementation that is being updated in a future API release or that it might be a logic issue on the backend since the documentation itself shows "2" entires when technically there is only one presented.

Thanks in advance for your thoughts!