cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: GetMetadata for Team folders - different response based on parameter

GetMetadata for Team folders - different response based on parameter

BIMcollab
Helpful | Level 5

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?

5 Replies 5

Greg-DB
Dropbox Staff

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
Helpful | Level 5

Hey Greg,

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

 

Capture2.JPG

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

 

Greg-DB
Dropbox Staff

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
Helpful | Level 5

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
Dropbox Staff

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.

Need more support?