We're having some performance and stability issues with the Box Search API currently. 3 problems that we currently have are
1. Box Search API seems too slow, especially when the number of records being retrieved is large. We tried to test it by uploading hundreds of copies of the same file to our Enterprise account and by having a couple of hundred records of the same file on the server downgraded search API performance a lot.
2. Rate limits. In addition to previous point, as mentioned in the GitHub code (https://github.com/box/box-windows-sdk-v2/blob/main/Box.V2/Managers/BoxSearchManager.cs) the limit property has a maximum value of 200. So we ended up with getting records in batches of 200 which causes us to send more requests to Box Search API to find the file we need. As mentioned in Box's rate limits article (https://developer.box.com/guides/api-calls/permissions-and-errors/rate-limits/) the limitation now is 60 search requests per minute per user, which in this scenario we just can't keep and we think we are getting throttled (each request sometimes completes in 5-10 seconds).
3. Delay. Newly uploaded files are not being retrieved by Search API for 5-10 minutes which makes it totally useless for our migration scenarios. We ended up using brute search mechanism in this case (when we start from the root level and loading each subfolder until we get the file). This is probably not the best way and is quite slow.
Additionally, in the discussion done in Giters.com (https://giters.com/box/box-windows-sdk-v2/issues/369) we see that Box had some plans to release "Get By Path API" few years ago, but it was not stable by then.
Any idea when it will get released? We really would like to have a simple API where you could pass the full path and get the file/folder back (e.g. /folder1/folder2/folder3/file).