Start 2025 on time and up to date! Seamlessly integrate your calendars into Dropbox with these simple steps! 📆
Forum Discussion
Correct way to use "add_file_member" endpoint if I need to share a file with a new email
Hello,
I am looking for a solution to my problem.
I am still in a testing stage, so I am open to different solution.
I need to share a file with only users who subscribe to a form. They subscribe on my website with their email and I add the email to the file requested.
To do that I thought the "add_file_member" endpoint could be the solution.
Actually I have two issues:
1. Access need to be temporary (I thought to flush email at scheduling), so I am not sure if "add_file_member" could suites my needs. Maybe "get_temporary_link" could work better? Does "get_temporary_link" allows download only to authorized emails? How long does the link last?
2. I was testing with the access token, but I did not get it lasts only for 4 hours. Still I do not need users to get OAuth, because I (the file owner) am the only one to give access to the file with the email provided. Does it sounds weird? Because I cannot find a simple solution that does not involve the user in an unnecessary authorization process since I am the one who has to give access and not them to log in.
Could you suggest a way to achieve what I want or point my errors?
Thanks!
- Greg-DB
Dropbox Staff
1. The /2/sharing/add_file_member endpoint allows you to share specific files with specific users. That access does not expire automatically, but you can programmatically revoke it whenever you need using the /2/sharing/remove_folder_member endpoint.
Alternatively, the /2/files/get_temporary_link endpoint returns a temporary direct link to the file data. You can pass that link to users to allow them to access the file data. These links automatically expire after four hours. These do not enforce access to only users with specific email addresses.
2. This is the expected behavior for new access tokens. Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is now issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.Hello @Greg-DB,
thanks for the fast reply.
I mostly get all, but still I do not quite understand OAuth process and why I need it.
Let me get you an idea about my needs and flow:
1. User land on a page and submit a form with his email.
2. I handle the request with an API function, make a call to the Dropbox endpoint and share the file (I am the owner of the file) with the new email.
3. Send an email to the user with the download link.
I do not want the user to login/using their credentials, that's need to be transparent to the final user. Doesn't OAuth implicitly require the user to follow a process with their credentials to be authorized?
Thanks for the answer!
- Greg-DB
The Dropbox OAuth app authorization flow is a way to have the user authorize the app to access their own Dropbox account. If your app is only meant for connecting to your own account, you would only need to process that flow once for your own account. You can store and re-use access tokens/refresh tokens for your own account. You would not need to expose that flow to other users.
Note that you should not expose any access tokens or refresh tokens for your own account to other users, e.g., keep your access tokens/refresh tokens on your server, and never send them to other users on your website front-end.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
