nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

HTTP API v2 files/search: not recursive until select top-level folder?

Dan L.10

I'm using v2 of the API and running into an unexpected situation with the files/search HTTP endpoint. Wondering if this is a configuration issue or expected behavior.

I'm trying to list of a user's files of a certain type. With v1 of the api, you could set path: '' and query: '.xls'.

When I use v2 of the API and hit the files/search endpoint, it seems that the same parameters return nothing. Only when I set the path to be one of the top-level folders (eg returned from files/list_folder) does it seem to return results (and then it does return results recursively, ie any .xls file in any subfolder).

Is there something special about these top-level folders that prevents an overall search from finding all results? Is there any way to get around that so I can do a search like "Show me all .xls files in a user's dropbox"?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Hi Dan, I'm not seeing the same behavior when trying this out myself. Can you share your code and output? (Just be sure the redact the access token.) Thanks in advance!

If you'd prefer to share privately, you can open an API ticket here:

https://www.dropbox.com/developers/contact

Dan L.10

Just using the straight HTTP files/search endpoint. I get results like {matches: [], more: false, start: 0} with a path of '', and I get matches when I search in one of the folders.

One possible complication: I use a dropbox business account, and the top-level folders have a different icon (red) than the sub-folders that do work recursively (green):

$> Not familiar enough with admin side to know what that different icon indicates (a group folder?), but it seems like the search doesn't go down into those. If I start the search inside those it works fine. The /files/list_folder endpoint doesn't seem to have any special identification for those -- they come back as {'.tag': 'folder', name: ...} just like any other folder, so if it is behavior specific to those types of folders, is there any way of identifying them? Does that help? If not, I'll open up a private API ticket.$

Greg-DB

Thanks! That's helpful, and I can reproduce this now. This seems to only occur for shared folders (which is what that icon signifies). We're looking into it.

Greg-DB

This should be working properly now.