Child Item

Api now returning path not found

I am using the API: https://api.dropboxapi.com/2/files/get_metadata

With a body of

{"path":"FILENAME","include_media_info":false,"include_deleted":false,"include_has_explicit_shared_members":false}

I am getting a 409 response that looks like this:

{ "error_summary": "path/not_found/..", "error": { ".tag": "path", "path": { ".tag": "not_found" } } }

This was working perfectly fine for years until yesterday including using the exact same requests that I am using today. I have made no changes on my side that could have caused this.

Does anyone have any ideas?

Thanks!

Find more posts tagged with

API

Abuse

Comments

Здравко

@Cust, Are you certain the "FILENAME" is still there (the file is on the place you're expecting) and not renamed/deleted/moved etc. (might be unintentionally)?

Greg-DB

@Cust A "path/not_found" Dropbox API error indicates that the API call failed because there was nothing currently found at the specified path in the connected account under the relevant root. For example, this can happen if there's a mistake or typo in the path value the app supplies, if the file/folder has been renamed, moved, or deleted from that path like Здравко said, if the app is not connected to the correct account for that particular path, etc.

When specifying the path, make sure you provide the full and accurate path for the desired file under the relevant root. For example, if you have a file named "example.csv" inside a folder named "folder", the path would be "/folder/example.csv". You can find more information on path formats here.

Here are several things you can check in particular to debug this:

Make sure you're using a currently accurate path value: You can use /2/files/list_folder and /2/files/list_folder/continue to list the contents of a folder so you can check what the correct path values would be for items in those folder(s). To list the root, set path to the empty string "" when calling /2/files/list_folder. You can use the path_lower or id values returned for the files/folders in that folder to interact with those files/folders.

Make sure you're connected to the correct account for the path value you're using: You can use /2/users/get_current_account to check which account the app is connected to.

Make sure you're using app folder-relative paths, if your app is registered for the "app folder" access type: Apps with the "app folder" access type can only access the contents of the special app folder that gets automatically created for it. If your app has the "app folder" access type, then it will only be able to access files in the app folder, and the root for any path value supplied by that app will automatically be the app folder root. You can find more information on app permissions here. For example, If your app has the app folder access type and you're trying to access something you can see on the Dropbox web site at "/Apps/<app folder name>/folder/example.csv", you should only send the path value as "/folder/example.csv".

Make sure you're accessing the relevant root: When using an app with the "full Dropbox" access type, API calls default to the member folder, but if you're trying to access the "team space" (only applicable to members of a team with the "team space" configuration), you'll need to configure that as the root explicitly, as covered in the Team Files Guide.

coadyg

Hi there,

I am having the exact same issue. I have raised a ticket with Dropbox for this. I think the responses already received here are not fully taking into consideration your comment that nothing has changed, code or directory paths. For me, nothing has changed and I am receiving the same errors. I suspect this may have something to do with the introduction of the new 'personal' and 'team' paths, where the folder root has been essentially split in two (a rough description I know). Earlier in the week I had to fix a number of Zapier integrations with DropBox that started to error at the same time as my HTTP API integrations. In Zapier I had to redefine the 'from path' for each with a definition of the root being 'personal' or 'team'. This was new as of last week.

Furthermore, I have done some testing with the DROPBOX API Explorer and I have noticed that a lot of my team directories are no longer visible when using it to hit the 'list folder' API. For the folders that are visible, my HTTP API calls work, for those that are not I receive an error similar to yours.

I will let you know if I receive anything useful back from Dropbox support.

Здравко

@coadyg, Do you understand that you contradict to yourself? From one side "nothing changed", but in the same time "new 'personal' and 'team' paths"! This is definitely a big change and you have to reflect it in your code (in the path at least and may be not only).

@coadyg wrote:
...
Furthermore, I have done some testing with the DROPBOX API Explorer and I have noticed that a lot of my team directories are no longer visible when using it to hit the 'list folder' API. ...

Of course, there are no "team folders" anymore. They are reformatted as team spaces! Consider change your root space of API calls to get access to there.

Hope this gives direction.

Greg-DB

@coadyg From your description, it sounds like you're referring to your team using the "team space". You'd need to set the "Dropbox-API-Path-Root" header to your 'root_namespace_id' as described in the Team Files Guide to be able to access the contents of the team space.

coadyg

Firstly, thanks for your feedback and energy here and I will investigate your suggestion. I am actually not contradicting myself, I am using the 'passive voice' in that sentence which implies that someone/or something has changed it without specifying a subject... pesky grammar

coadyg

Hello Greg,

Thank you for the document. Educating myself on the topic of root namespace, their ids and the related HTTP headers did the trick. We use the Team Space configuration so adding the header worked for my API calls.

One comment that I'd like to add is that before October this wasn't a requirement, i.e. The same calls were working before adding these headers. So something in the mix has changed (moved from optional to mandatory, or some default behaviour has changed).

Thanks again