EDIT: This is one of the top google results for "Dropbox API limit", so I'm updating this!
Since my original post, Dropbox has raised the "Data Transport Limit" from 25,000 calls per month to 1,000,000 per month! This is cited on Dropbox's plan comparison page here. The official DropBox API limit docs don't mention it yet. Another recent improvment is that the "/team/features/get_values" API endpoint returns the API limit for that business account. It doesn't tell you how much has already been used though.
Other observations: Free/Plus/Pro Dropbox accounts don't have any API limits at all. It's only when you have a business account shared among team members that this limit comes into play.
Also: The 1,000,000 API call limit seems to only apply to "Data Transport Partners" apps and not "Security Platform" or "Productivity Platform" apps. However it seems to work like a whitelist so by default it'll apply to your app. But if you're a legit Dropbox app that's popular with business users but you're not providing "Data Transport", I think you can contact Dropbox and they'll change it so your app doesn't affect the user's data transport API limit. To do this try joing the "Technology Partner Program". (but only if you're not doing data-transport heavy stuff. Like a doc editor or something).
@Greg-DB Any chance we could get confirmation that non-data transport apps can apply to be exempt from the limit? Is becoming a "Technology Partner" app the right way to do that, or is there another way? If I'm totally wrong I'll delete this.
Thanks!! Good job on Dropbox for having a forum. It's so rare to see that these days but they can be quite helpful.
=====================original post below=====================
We're adding dropbox upload/download to our app....I don't really use dropbox myself so help me figure all of this out.
Reading around the Dropbox website says that apps that connect to free or indivudal users have no API limit, but apps that connect to business users have a 25k limit for file upload calls? It's weird that this limit is only for your customers that already pay you the most.
Also since it's an API limit and not a byte limit, that means when uploading files in hunks I want to use the biggest hunk size possible to reduce the API calls? Is it then good advice to upload all files smaller than 100MB with the one shot uploader, and use the piece by piece uploader for larger files?
smaller hunk sizes are nicer for reliability/efficency, so it bad I have to compromise that for this API limit. Uploading in small hunks is much nicer on phones that have bad connections that come in and out but this pressues us not to use it. Also this makes me think that something like an auto-save feature that saves your files to Dropbox every 60 seconds is a bad idea since that also eats up API calls.
I really think the limit should be a total size limit or # of files updated limit to avoid this weird pressure on people making apps. No reason someone uploading a 1GB file in 1MB hunks should have to cost a company 1000 api calls (4% of their entire total combined API limit for every person...for a team of 50 they only get 500 api upload calls per users). Just count the file updates or bytes uploaded instead.
I'm just worried business users will not want to use our app if we hurt their limit too much or worse than that the owners of the business accounts will ban all individual apps.
Can the fine people of DROPBOX clarify what the situation with all this is and put up guides and best practice advice? I didn't see the 25000k limit anywhere on the developer docs or developer blog post but knew to research it from other people complaining. The data ingress guide says to back off and retry but I've seen reports of people hitting this on twitter and sounds like you have to back until the next month to get past the limit lol. Really weird that none of the technical content mentions this limit anywhere at all, just business stuff.
Maybe all the businesses are still on the old plans for now and so they don't care, but in the future more and more will have this new limit which seems like it'll hurt developers. Once business users start hitting this limit or get close to it then larger teams with ~50+ people will want to prevent their users from linking individual apps like ours. Is it a good idea to start advertising that we're "optimized" to minimize our app's API upload calls? (of course optimized to limit API calls actually means unoptimizing for efficient phone uploads)
Help me understand why app makers shouldn't be worried? Are you confident this won't hurt your API ecosytem?
Solved! Go to Solution.
I know this is a very old thread but just wanted to update it as I came across is when I performed a search.
Dropbox has now increased in API limits to 1 Billion calls on it's business teams.
This should be more than enough to get all your data into Dropbox as fast as possible.
Thanks for writing this up! We appreciate the time and detail.
Yes, while the Dropbox API has a general rate limiting system (meant to prevent abuse), you're correct that (some) Business plans additionally have a 25k per team per month API limit on upload calls. This does not apply to any individual plans. It only applies to certain Business plans, because the quote and pricing works differently for those, and anyone interested in Business plans can talk to sales about the different options in order to find one that fits their needs.
And yes, since this is based on the number of calls, and not chunk/file size, you can optimize this, balanced with efficiency, as you described.
Since this depends on the Business plan, it is documented in the plan comparison here:
There's also information here about the migration for old plans:
We don't have a list of these apps available to see which are affected, but when the team admin or member is prompted to decide whether or not to connect an app to their account, the app authorization page will show a warning if the app would consume the upload API call limit. If it doesn't show the warning, it will not consume it.
If you're interested in a potential partnership, you can contact the business development team here:
Anyway, thanks so much for the detailed feedback! I can't tell you how to market your app of course, nor can I speak on behalf of Dropbox management, but I'll pass this along to the team as requests for more documentation, and a change to how this is implemented.
Is there a way to tell through the DropBox web interface, either from the regular content browser or the admin console, how much of your upload API quota has been consumed? If not, any other way? Reason being we'd like to use Duplicati backup but received the warning you refer to above.
I'm a little irked that once again an "unlimited" offer turns out on closer inspection to have limits lurking beneath the surface, but that's obviously beyond your control.
I have several clients with Synology NAS and Dropbox sync.
Today one of the client received the email regarding the API calls limit has been reached 80%. 30 minutes later, the 100% api call limits has been reached so I understand the Synology will be unable to sync with the Cloud until December 01. OMG.
I check the link https://www.dropbox.com/team/admin/billing/manage and confirmed the 25,000 limit has been reached!
I check the same link for other clients and have no %% about the api calls. The difference is one client (the one who reach the limit) pay on annual basis and the client without the API call limit information pay on monthly basis.
Have the billing period relationship with the API Calls Limit?
I see API call limits now applies to every Business Account (Standard, Business & Enterprise). So, how we can remove this limit? with API call limits, our clients cannot use Dropbox because the main feature we exploit is the ability to Sync Dropbox with a Synoloty NAS.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!