Deleted files metadata

[jwpegram]

None of the v2 get_meta endpoints return any metadata regarding deleted files even though the documentation says they do is include_deleted = true.

How does one go about getting the modified time of a file or folder after it's been flagged for deletion?

Thanks

[Stephen C.14]

Thanks for reaching out. Supplying `include_deleted` to a metadata endpoint should return the correct deleted metadata. However, if you just recently deleted the Dropbox object, there can be a small delay (should never be more than a minute) where the deleted metadata is populated.

Have you tried waiting for a small period of time before requerying to check for deleted metadata?

[jwpegram]

I've tried all the documented endpoints:
/list_folder
/alpha/get_metadata
/get_metadata

None of them return anything other than
.tag, name, path_lower and path_display for a deleted file. In order to get the modified date I'm having to make a call to:
https://api.dropboxapi.com/1/metadata/auto/{path_lower}
which does return this information but is an extra call vs just getting it in /lift_folder

This is confirmed by various methods and different tools, the response always looks like:
{
".tag": "deleted",
"name": "bccdcv1.pptx",
"path_lower": "/ventureprise/bccdcv1.pptx",
"path_display": "/ventureprise/bccdcv1.pptx"
},

It might be acceptable if one of the v2 metadata endpoints returned the deleted metadata but since they don't either the only option to get it is the v1 endpoint which is obviously a temporary thing. However, even if the metadata was returned by the metadata endpoints, that's still an unnecessary call back just to get modified date, so it needs to be corrected in the list_folder and list_folder/continue functions.

[Greg-DB]

Thanks for following up, and apologies for any confusion. It sounds like you are getting DeletedMetadata returned, and those are expected fields for a DeletedMetadata object. You can find the documentation for it if you click to expand "DeletedMetadata" in the HTTP documentation, e.g., under /2/files/get_metadata.

Dropbox API v2 doesn't return the modified datetime for deleted entries, but we'll consider it a feature request.

[jwpegram]

Ok, that makes sense. So what happens when the V1 API goes away? At the very least if the list_folder or list_folder/continue functions were to include the modified date I could avoid a second call, but even if they didn't we still need to get that information.

To expand further, what we are trying to do is manage the deleted files in employee boxes. For example, employee incorrectly gets stuff uploaded or has a large archive they choose to delete. Ideally we would like to be able to set via the admin panel the time to recover? (120 days on Business Plan). Since we can't change that to say 30 days, I'm looking at the files that have been deleted by a user and checking their modified date to determine if they are older than 30 days and if so permanently deleting them so they are removed from the users views at that point.

If you are taking feature requests, I'd suggest just allowing the recover time to be arbitrarily set by business accounts (30,60,90,120) to keep it sane.

[Greg-DB]

Thanks for the feedback! Unfortunately I'm afraid I don't have a good non-API v1 solution to offer. I'm sending these requests along to the team.

[jrk]

Why is the v1 API being deprecated if fundamental access to core data is still impossible with the v2 API?

[Greg-DB]

Thanks for the feedback! I can't speak to why any particular feature was or wasn't implemented, but I've sent this along to the team as a feature request.