@James_T Yes, /2/sharing/create_shared_link_with_settings requires one call per item, so if there's a significant number to process, that would take a significant amount of time. That being the case, you could also consider only creating the shared link on demand, when the user clicks on a specific file. That is, the listed on your file on your page would link to a route on your server, which when accessed, would make the Dropbox API call and then redirect the user to the returned link. (Likewise, /2/files/get_temporary_link would also work here, if you just need a temporary direct download link instead of a shared link.)
Alternatively, if you want to have the user's browser download the file directly, you could use /2/files/download on your server when the user clicks on a particular file. That would require passing the file data through your server each time though.
And yes, your understanding of the Embedder is correct. It would take a single shared link for the parent folder, and would then list everything in that linked parent folder.
If you take care every file you want to show to be associated in advance with a shared link, listing process is just a single API call. 😉 Even more, you can filter the results "on fly" and filter any unwanted entry with a shared link. Is this so slow? 🤔 Probably it depends on your data structure...
I think I will go for the Embedder route, even though it has some drawbacks in my case. It really is a shame that the Embedder isn't more customizable.
In our company, we create a root folder for all new projects, with a bunch of subfolders we work on from a PC. On our internal website we want our employees to be able to access the content of only certain of those folders.
The problems with the embedder is: 1. The folder needs a share link. Workaround: When creating the project folders, make a share link and save to DB.
2. Sharing the folder gives access to all folders. Workaround: Create a subfolder called "web" and move the folders employees needs access to there, and share that one instead.
The second workaround is the biggest problem for us, since that means an extra click into the "web" folder every time we work on our folders from a PC - which we do a lot (for those who don't know, it's also not very logic why some folders are not in the root, while others are)
All in all, I think the Embedder route is a better option than spending a bunch of time recreating what is basically a custom version of the embedder, which will never be as nice (previews, icons etc).