GetMetadata for Team folders - different response based on parameter

[BIMcollab]

Hi,

I've noticed a strange behavior when using the /get_metadata endpoint when using it for Team folders on a Business account:

When I use it for a soft deleted folder with "path": "ns:1701052593/TeamFolder" I receive the .deleted tag. However when I change the path parameter to use the id of the folder like  "path": "id:wyXLk_56qkAAAAAAAAAHwF" I receive the path/not_found exception. In both cases I have set "include_deleted" to true. I encounter this behavior for Team folders exclusively. For other folders I get the .deleted tag in both cases. Is this a API bug or is it like this by design?

[Greg-DB]

I just tried this out myself in a test account for reference, and I don't think I'm seeing the same behavior. For example:

curl -X POST https://api.dropboxapi.com/2/files/get_metadata \
    --header "Authorization: Bearer <ACCESS_TOKEN>" \
    --header "Dropbox-API-Select-User: <MEMBER_ID>" \
    --header "Content-Type: application/json" \
    --header 'Dropbox-API-Path-Root: {".tag": "root", "root": "1990815600"}' \
    --data "{\"path\": \"id:5aUO2rfctSAAAAAAAAAAAQ\", \"include_deleted\": true}"
    
# {
#   ".tag": "deleted",
#   "name": "test_410191",
#   "path_lower": "/test_410191",
#   "path_display": "/test_410191"
# }

Are you using the "Dropbox-API-Path-Root" header though? You would need to use that to set the root of the API call to the team space where the folder existed to get the deleted metadata. Please refer to the Namespace Guide for more information on how this works.

Or, alternatively, are you sure you're using the right file ID? You could get that error if it's not actually the ID of the folder that was deleted. 

[BIMcollab]

Hey Greg,

Unfortunately I am still experiencing the same behavior. Please take a look at the attached scnreenshots of the request:

After this request, I soft deleted the team folder in Dropbox and repeteated the request (I haven't changed any headers or the body)

[Greg-DB]

Thanks, that's helpful. Can you confirm you used the API to create and delete the folder as well? It looks like I was doing something different in my test which resulted in a different behavior. We'll look into the behavior you're seeing.

[BIMcollab]

Hi Greg, 

I can confirm that I used the API to create the folder. However I have only tried deleting it from the Dropbox website (manually) and then restoring it from the website as well. I am not sure what the impact of this is?

[Greg-DB]

Thanks for confirming that! It looks like creating this folder via the API as opposed to the web site is what made the difference here. This is open with the team and I'll follow up here once I have an update on this.