Discuss Dropbox Developer & API
Hi, I am working on getting the shared links of a file or a folder along with it's parent's shared links with API list_shared_links.
However, I got different response from Team Space and Team Folders model.
For Team Space model, neither given true nor false to `direct_only`, there's no parent's shared links in the response.
For Team Folders model, direct_only works as the description.
Just want to make sure is this expected behavior ? Cause there's no description about it.
Thanks!
H @mikechiu, thank you for bringing up this case regarding the shared links inheritance. I can confirm that the engineering team has now fixed this issue!
Hi @iNeil , thanks for your responding. I'll check and update here.
Hi @iNeil it looks like the response from list_shared_links is always 429.
here is my curl command, can you help check?
curl -s -XPOST -H "Authorization: Bearer $dt" -H "Content-Type: application/json" -H "Dropbox-API-Select-User:dbmid:AABoDSTDeZtrGKUDsWr8OP_qv9l6s8itCCk" -d '{"path": "id:sK5VCkFxNtoAAAAAAAAAZA"}' https://api.dropboxapi.com/2/sharing/list_shared_links
@mikechiu, Did you see what's the response body? There should be explanation whether you made too many write operations or too many request of any type and that's why you're limited. Usually you should wait for some time (denoted in retry-after field) and try again your request.
Good luck.
@mikechiu It looks like you're hitting the rate limiting system; as Здравко noted you can check the response body for the error message. Please try again after the delay and let us know if you're still seeing this issue.
@Здравко @Greg-DB It works now and sorry for not paste the result.
The result was too_many_requests.
{
"error_summary": "too_many_requests/..",
"error": {
"reason": {
".tag": "too_many_requests"
},
"retry_after": 10
}
}
And actually I continued getting the 429 retry-after:10 at that moment and just wondering what the exact ratelimit for APIs that are not upload/download related since there's no exact document for this? Thanks!
@mikechiu wrote:... what the exact ratelimit for APIs that are not upload/download related since there's no exact document for this? ...
Most API calls (not necessary upload/download type) deal in some way with account content. To avoid a mess as result of simultaneous access (race condition), all requests are strictly serialized while waiting for every namespace lock gaining. When in lock tail are too many waiting requests some of them get "rate limit", so the "size" of this "tail" be kept in control (as far as possible). That's it.
To minimize probability for rate limiting, try decrease total number of locking calls and whenever possible use batch version of calls that have such variants. Don't try speed up your code using too many different threads calls, since this can lead to excessive load that results in rate limitings! For some other hints take a look here.
Hope it's a bit more clear.
@mikechiu Thanks for following up. I'm glad to hear this is working now.
As for the rate limits, we don't have specific rate numbers to share, but you may see responses like this at any time so make sure your app is always able to catch and handle such responses.
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!