You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
API Error "path/not_found" when creating shared_link
When interacting with the API, I get a path/not_found error. This happens when I upload a file to dropbox using the path /2/files/upload. After that, I create a link to the file using the path /2/sharing/create_shared_link and specify the path_display received after uploading the file. The error occurs very rarely, but it does not allow you to get a link. What could be the problem?
filesGetTemporaryUploadLink - 404
Hi! I'm user of dropbox basic and I'm generating upload link but the link following to 404 page. I have one folder /home/products and one app /Apps/xxx with folder /products I did try every combination to get proper link but its impossible for me. here is list of paths witch I did provide - /products - /products/somefilename.txt - /Apps/xxx/ - /Apps/xxx/products - /Apps/xxx/products/somefiname.txt what is proper path in my case ? please help const dbx = new Dropbox({ accessToken: token }); return dbx.filesGetTemporaryUploadLink({duration: 14000, commit_info: {path: '/Apps/xxx/products/text.txt', "autorename": true, "mode": "add", "mute": false, "strict_conflict": false }})
list_shared_links API inconsistency with team folders: Only showing edit OR view link, not both
I'm encountering an unexpected behavior with the list_shared_links API (https://api.dropboxapi.com/2/sharing/list_shared_links) when working with team folders. I hope someone can provide clarification. Issue: When listing shared links for a team folder that has both edit and view links: 1. If both edit and view links exist, only the edit link is returned in the API response. 2. If I remove the edit link manually, then only the view link is returned. But, if I pass the specific path it return both links Details: - I'm using a team access token. - I'm passing the 'Dropbox-API-Path-Root' header to list all team space shared links. Expected behavior: Based on the API documentation, I expected to see all shared links returned. The docs state: "If no path is given, returns a list of all shared links for the current user. For members of business teams using team space and member folders, returns all shared links in the team member's home folder unless the team space ID is specified in the request header." Steps to reproduce: 1. Create both an edit and a view link for a team folder in Dropbox. 2. Use the list_shared_links API with a team access token and the 'Dropbox-API-Path-Root' header, without specifying a path in the body. 3. Observe that only the edit link is returned. 4. Manually remove the edit link for the folder via the Dropbox dashboard. 5. Use the list_shared_links API again with the same parameters. 6. Observe that now only the view link is returned. Questions: 1. Is this the intended behavior of the API for team folders? 2. If so, is there a way to retrieve both edit and view links for team folders in a single API call withoutspecifying the path? 3. If not, is this a known issue specific to team folders, and is there a workaround or fix planned? 4. Does this behavior differ between team folders and personal folders? Any clarification on this would be greatly appreciated, especially regarding how the API is supposed to handle multiple link types for team folders. Thank you!
Updates Coming to the Folder Link Sharing Experience
Dropbox is moving to an updated shared link architecture where links are based on the content being shared rather than on the user doing the sharing. This new content-based link architecture is already in place for edit access links to folders and newly created links to files, and can be identified by the presence of an ‘rlkey’ parameter in the URL. Over the next few months, we’ll round out the shared link portfolio by bringing this new architecture to newly created view-only access folder links, or view folder links for short. With this transition we’re maintaining all the core functionality our users love about sharing with links, while making it even easier for content owners, collaborators, and team admins to manage their shared content easily and with confidence. Updates to Link Sharing Only Two Centralized Links per Item Securing your content and managing your shared links is now easier and simpler than ever. Basing links on the content being shared means there will never be more than one single edit and one single view link for each file or folder. Changing the settings on these links will universally apply to everyone with link access to that content. Because all collaborators on a piece of content share the same link, a change is that only content members with edit access are able to modify shared link settings or delete a shared link. URL Format Change Part of the new link architecture is the addition of an rlkey parameter. Query parameters are anything following “?” in a URL. It is this rlkey parameter which grants access to the content, and removing it will require visitors to sign in and request access. Visit this forum to read more about the new format, or this Help Center Article for details on forced downloads. Third Party Application Dependencies Due to the change in URL format you may notice some third party applications, websites, and custom programs that rely on pasting in a Dropbox link no longer function as expected. We have limited insight or influence on these third party use cases, but if you do experience issues, please contact Dropbox support or visit this community forum thread on this subject. Enhancing the Link Sharing Experience Quick, simple, stress-free file sharing is core to the Dropbox experience. Content-based links makes it even easier to share files securely and effortlessly in real-time, and we are excited to bring these benefits to all users across our full portfolio of shared links. If you have more questions, or find yourself needing support during this transition, please visit our Community Forums, reference our Help Center, or contact Dropbox Support.
Shared filename names
Is there a way to at least know a consistent filename to be used with a group of shared files. I have 1000 jpg files and other files (mp4's) that I want to be able to share. I wrote a program to associate those 1000+ files with a map location and the map location has a URL associated with it that allows the file to display. This all works as planned. The problem I have is that the URL for all 1000+ files do not have a consistent naming convention because of how the sharing names are created. As an example, Here are two files names generated from sharing the files: https://www.dropbox.com/scl/fi/1y390q1tmftcz5tjlcng4/Foobar.xls?rlkey=pkw1q2jp8rwkg&st=yn17rf6v&dl=0 https://www.dropbox.com/scl/fi/ht4a542xdxjikzqi707hm/Foobar2.jpg?rlkey=a7mpjc0kj3o5&st=9wiqu6wz&dl=0 These are fictitious filenames but the generated security information around it is real. With no consistency, Is there a way to know what the security information around the shared filenames so I can automate these?
Clicking files in embedded Dropbox leads to registration screen instead of direct download
We have embedded Dropbox onto our website in an iframe:[Removed as per Community Guidelines] We produce a Dropbox read only share link to include in the embed code. For some folders we get a share link containing /scl/fo/ which leads to a registration splash screen whenever a website visitor clicks a file in the embedder. However we want to start a download instead of a registration... The strange thing is that other folders for which we produce a read only share link contain /sh/ . When you click on a file in the embedder with this link in the code, the download starts without a registration splash screen. Now, I've read that a linkcontaining /scl/fo/ is an edit link.Why do some folders produce a link containing /scl/fo/ and others /sh/ while we explicitly ask for a read only share link? We run a Dropbox Advanced plan.The raw=1 parameter for shared links is not working again for my mp3 player. Can you help?
using raw=1 is no longer working with my dropbox mp3 links. it used to work but not anymore with my mp3 player. im frustrated because this seems to happen to me often. please tell me how i can get my mp3 dropbox link to work again with a mp3 player. i hate when this happens. thank you kindly, Hahmed44
