We're making changes to the Community, so you may have received some notifications - thanks for your patience and welcome back. Learn more here.
Forum Discussion
Short lived access tokens only?
I'm building an internal tool to create file requests via the API. I had it working, but I believe the App Console is only giving me short-lived access tokens when I click "Generate" - each token starts with "sl".
Is these a way to get longer-lived tokens for my app? I'm in the "development" stage, which I thought was correct for an internal app, but does that affect the longevity of my 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. Refresh tokens do not expire automatically and can be used repeatedly. 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.The status of the app does not affect this. This works the same way for both development status and production status apps.
- Greg-DB
Dropbox Staff
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. Refresh tokens do not expire automatically and can be used repeatedly. 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.The status of the app does not affect this. This works the same way for both development status and production status apps.
Greg, thanks for the quick answer. I haven't used a system like this before and I'm slowly getting my mind around it. I'm trying to do all of this via Zapier, fyi.
I've successfully gotten an authorization code, but I'm having trouble getting an access token and refresh token. I'm getting this error: "The request parameters do not match any of the supported authorization flows. Please refer to the API documentation for the correct parameters. (HTTP Status Code: 400)"
This is how I have it set up (with key details blurred):
Is there some other way I should be getting an access token and refresh token?
- Greg-DB
Typically, if you're the end-user of an app, you shouldn't have to manage the implementation details of the authorization flow like this yourself; that would be built into the app itself. You may want to refer to the support resources for Zapier to see if there is built-in support for this.
That said, looking at your screenshot, I see you're passing the 'code', 'grant_type', 'client_id', and 'client_secret' as headers, but those should actually be sent as application/x-www-form-urlencoded POST parameters.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
