Is anyone else experiencing issues with the Files API search endpoint today? Starting this morning, the /files/v3/files/search endpoint returns empty results ({“results”:[]}) for ALL queries, despite files existing in the account. What’s broken:
-
GET /files/v3/files/search?parentFolderId={id} → Returns 0 results
-
GET /files/v3/files/search?limit=10 (no filters) → Returns 0 results
-
GET /files/v3/folders/search?parentFolderId={id} → Returns 0 results
What still works:
Steps to reproduce:
-
Have files in a folder (confirmed visible in HubSpot UI)
-
Call /files/v3/files/search with parentFolderId parameter
-
API returns {“results”:[]} despite files existing
What I’ve tried:
-
Rotated API token - issue persists
-
Confirmed files scope is enabled
-
Tested multiple folders - all return empty
-
Tested different filter parameters (type, access, archived) - all return empty
Workaround found: Direct file access via /files/v3/files/stat/{path} still works if you know the exact file path. Has anyone else noticed this? Is there a known issue with the Files search API?
I followed your steps to reproduce and the 3 different endpoints you mentioned, I tried testing images and PDF’s both inside and outside of folders. I also tried changing the visibility (Public, Public - No Index, and Private) of both the files and folders and mixing/matching the two:
-
GET /files/v3/files/search?parentFolderId={id}
- Returned files as expected
- I was only able to get 0 results by moving all the files in this parent folder into a sub-folder (in which case you’d need to call the API with the sub-folder ID as the parent)
-
GET /files/v3/files/search?limit=10 (no filters)
- Returned files as expected
-
GET /files/v3/folders/search?parentFolderId={id}
- Returned the sub-folder as expected
Sorry I’m not sure what else to suggest but just thought I would let you know it doesn’t appear to be an issue across the board. If you have anything else you want me to test (different folder/permission structures, etc.) let me know, I’d be happy to help!
So it seems to be an issue with the search index for me. I an running tests at the moment but seemingly nothing has changed in code, file structure or permissions in the last few days but now files are not being returned. I can correctly retrieve the files via searching the file id or the file path, however when i try GET /files/v3/files/search?parentFolderId={id} I get no results, even though the folder of this id exists and has files within it? The visibilty hasn’t changed and there is still full access. Is there a way to re-index the portal’s file search index?
I have run a test and direct access of files and folders work but listing/searching is failing. Bear in mind I havent touched my code configuration in the last coupld of weeks and it went from returning fine to failing, is there a way the search index could be corupted??
> V2 File Manager API:
- GET /filemanager/api/v2/files → {“total_count”:0}
- GET /filemanager/api/v2/folders → {“total_count”:0}
V3 Files API:
- GET /files/v3/files/search → {“results”:[]}
- GET /files/v3/folders/search → {“results”:[]}
Working (direct access):
- GET /files/v3/files/{id} → Returns file 
- GET /files/v3/folders/{id} → Returns folder
- GET /files/v3/files/stat/{path} → Returns file
Yeah that’s very strange! Have any files been added since the last time the code worked? I wonder if some corrupted file or a special character that wasn’t stripped from a filename is causing a silent failure? It’s unlikely but it also wouldn’t surprise me haha
You could try creating a brand new folder at the root of your files (so not inside of an existing folder) and just upload a known good file, like a simple image, and test using the GET /files/v3/files/search?parentFolderId={id} endpoint.
I guess one more thing to do while you’re at it is to change parentFolderId to parentFolderIds as that’s how it’s listed in the documentation - parentFolderId seems to work no problem, but it can’t hurt to match the docs.
Yes lots of files have been added recently, would a single file with a corupter name be enough to break the whole search index? Any suggestions on How i could try find this file if so?
Even trying to list files at the root returns empty for me right now!
The corrupted file/filename was just a guess, not something I’ve run into before, I’d just look for any recently added files with unusual characters or an ‘unknown’ file type.
I’m just trying to think of reasons why this issue would pop-up without warning and only affect one account. Could it be a problem of scale - how many files do you have in your account? I wonder if the search is silently timing out.
I’m not sure if it’s feasible (depends on the number of files we are talking about) but you could try removing all the files added since the last time the code worked (Download them all first obviously!) and then test it again, if it works then you know that either one of those files caused the issue or it’s a matter of size.
Edit to add: Tagging @JCarey5 because I just noticed I replied to myself by accident haha
Experiencing the exact same issues as you since yesterday. The behavior is inconsistent from what I can tell (certain portals experiencing it, others not). Will keep you posted if I find out anything.