2025 sparked some incredible conversations across our community 👩💻. Discover the highlights and see what’s ahead in 2026.
Forum Discussion
/files/search deprecation and how it relates to the JavaScript SDK
Hey there, With regard to the deprecation of the /files/search endpoint, I'm curious how it relates to the JavaScript SDK. We're using an older verison of that SDK for our integration, and I'm wo...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorCan you elaborate on what you mean when you say you "are seeing calls to that endpoint that are coming from places other than the filesSearch method"? Can you share what you're seeing specifically in that regard? None of the other methods in the SDK should be calling that endpoint.
For instance, filesListFolder just calls /2/files/list_folder, and filesListFolderContinue just calls /2/files/list_folder/continue.
Also, for reference, you can find information about the changes between the versions in the release history and upgrading.md.
> Can you elaborate...
Right, well, in our logs I'm seeing calls to the files/search endpoint, but I can't trace how it gets there. We only call `filesSearch` in a single place; but the function from which I'm seeing the calls to the files/search endpoint do not call `filesSearch`. We're way back on version 2.5.12. This may not be a question you can answer, and that's fine, but it's very suspicious.
I do want to follow up on this bit, though:
> you should replace any usage of filesSearch in your app with filesSearchV2 and filesSearchContinueV2.
It seemed like `filesSearch` handled calling `files/search/` and `files/search/continue`. But now it seems like with moving to V2 we need to manage the continue call manually ourselves? In other words, we used to be able to call `filesSearch` and it did any continuing necessary under the hood but now we have to manage that ourselves?
Finally, one more question. I've noticed that the files/search and files/search_v2 endpoints return different results for the exact same query. Do you have documentation on what changes were made there?
Thanks!
- Greg-DB
I can't think of any reason you'd be seeing more calls to /2/files/search without actually calling filesSearch. For reference, here's a link to the code from v2.5.12 of the SDK, and the only reference to files/search is in the filesSearch definition. Could you perhaps share the relevant code you mention here: "the function from which I'm seeing the calls to the files/search endpoint do not call `filesSearch`" so we can take a look?
Also, filesSearch did not actually automatically handle the pagination for you. And there actually wasn't an equivalent /2/files/search/continue endpoint. The pagination for /2/files/search (and so for filesSearch) was handled by calling /2/files/search (filesSearch) itself again. With the SDK, when calling filesSearch you are supposed to check the returned FilesSearchResult.more to see if there are more results to retrieve, and then call filesSearch again, supplying the FilesSearchResult.start as FilesSearchArg.start, if so.
In the new version, using filesSearchV2 and filesSearchContinueV2, the pagination is built somewhat differently and uses the two separate endpoints, so you would instead check FilesSearchV2Result.has_more and use FilesSearchV2Result.cursor instead of a "start" value.
Finally, yes, the two search systems work a bit differently. You can find more information in this blog post.
Thanks again, so much!
That's a great blog post, and I have a follow-up.
Is there a set of parameters I can send to search_v2 so that it will return the same results as search? I imagine we'll want to take advantage of the greater set of results, but just in case we run into cases it would be nice to have this in our back pocket.
Thanks!
- Greg-DB
No, the two work a bit differently so their options and functionality don't map exactly to one another, so there isn't really a way to make them behave exactly the same way.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
