Access token

MeShootIn

I use Dropbox API for only /download method. To access it, I've generated an access token by clicking on the "<get access token>" button from the example.

How long does this access key "live"? Are there any restrictions on the number of requests for this method?
If my scheme for working with the API is wrong, which option is better?

Greg-DB

The Dropbox API offers two different types of access tokens: long-lived and short-lived. Both types can be used to make Dropbox API calls. You can find more information on how the authorization system works in the OAuth Guide.

 

• Long-lived access tokens do not expire automatically, though they can be revoked by the user or app on demand. Note that the creation of new long-lived access tokens is now deprecated, but we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without interruption. You are not required to migrate existing long-lived access tokens to short-lived access tokens.
• Short-lived access tokens do expire automatically, four hours after being created. They can also be revoked by the user or app on demand.

Short-lived access tokens can be identified by their "sl." prefix. Long-lived access tokens do not have such a prefix.

 

Currently, when getting an access token via the "Generate" button on the app's page on the App Console, or the "<get access token>" link in the examples, the type of access token returned will be determined by the "Access token expiration" setting for the app at that time.

 

For either kind of access token, the Dropbox API does have a rate limiting system, though we don't have specific rate numbers documented. Also note that not all error responses with a 429 and 503 status code indicate explicit rate limiting, but in any case that you get a 429 or 503 the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not. I recommend referring to the error documentation and Error Handling Guide for more information.