Rate limits and team-wide enforcement risks for file delivery

Dodocuk

Hi,

We run an internal tool for our company’s marketing team. Our creative team uploads assets (JPG/PNG/MP4/MOV, roughly 5–100 MB each) into a team folder in our Dropbox Business team. We operate within a single team and have no external tenants. Our service currently downloads each file via /2/files/download and then re-uploads it to external ad platforms (Meta, TikTok, Snapchat, and AppLovin) to create campaigns.

The problem with this is latency: campaign creation waits for the full download to land on our side before anything reaches the ad platform. We’re therefore evaluating different delivery strategies depending on each platform’s capabilities. For some platforms, we may stream the authenticated /2/files/download response directly into the upload request, with bounded buffering and Range-based retries where necessary. For others that support URL ingestion, we may provide a temporary URL instead.

Before making these changes, we want to understand the rate-limit, bandwidth, and team-wide enforcement implications. Our current understanding, based on the documentation and previous Dropbox staff answers, is:

• All our file operations use User API endpoints via Dropbox-API-Select-User, and rate limits therefore apply per selected member.
• Authenticated /2/files/download traffic does not count toward shared-link bandwidth limits.
• URLs returned by /2/files/get_temporary_link do count toward sharing bandwidth limits.
• /2/files/download supports Range requests.
• Rate-limited requests also count toward the limit, so clients should honor Retry-After.

Please correct us if any of these are no longer accurate.

We’d like to clarify the remaining operational and enforcement questions:

1. Our panel already uses persistent shared links created via /2/sharing/create_shared_link_with_settings with Dropbox-API-Select-User, and we may use temporary links for campaign delivery.

Is bandwidth attributed to the selected member, the file or namespace owner, or the Business team? If we move automation to a dedicated service member, would existing links remain attributed to the original member, requiring us to recreate them? If the allowance is exceeded, is enforcement limited to that member or applied across the entire team, and which sharing functions are interrupted?

More broadly, is serving internal product-UI previews through persistent shared links a pattern you would advise against? If so, what would you recommend for authenticated in-app previews?

2. We understand that Dropbox currently does not expose shared-link bandwidth consumption before enforcement. Can you confirm whether this also applies to Dropbox Business admins, with no team-level dashboard, report, or API available?

3. Can a URL returned by /2/files/get_temporary_link be reliably reused for multiple fetches for the duration of its lifetime (documented as four hours—please confirm), including retries by the same or different consumers?

4. When streaming a download into a slower third-party upload, does Dropbox impose any read-idle or maximum connection-duration limit?

5. We currently limit /2/files/download to six concurrent requests per selected member and have not observed any 429 responses. Is that a reasonable concurrency level, including when connections remain open while streaming to slower destinations?

6. Do RPC and content calls share the same rate-limit budget?

7. If we always honor Retry-After and use exponential backoff with jitter, can repeated API 429 responses ever escalate beyond temporary throttling—for example, to token revocation, app or account restriction, or interruption of the team’s sharing activity?

Given the two traffic sources and usage patterns described above, does anything in our current or proposed usage look abnormal or likely to put the team’s sharing availability at risk?

Thank you so much.

Greg-DB

Thanks for writing in. It sounds like you already have a good handle on much of this, and I'll try to address your remaining questions as best as I can. Please note of course though that Dropbox and its infrastructure are subject to change over time.

1. Our panel already uses persistent shared links created via /2/sharing/create_shared_link_with_settings with Dropbox-API-Select-User, and we may use temporary links for campaign delivery.

Is bandwidth attributed to the selected member, the file or namespace owner, or the Business team? If we move automation to a dedicated service member, would existing links remain attributed to the original member, requiring us to recreate them? If the allowance is exceeded, is enforcement limited to that member or applied across the entire team, and which sharing functions are interrupted?

Dropbox does track bandwidth usage on links, and this is attributed to the user account, such as a team member, that owns the link. If sharing is interrupted, it would apply to that account. You can find more information on this here: https://help.dropbox.com/share/banned-links

More broadly, is serving internal product-UI previews through persistent shared links a pattern you would advise against? If so, what would you recommend for authenticated in-app previews?

I can't to offer this sort of guidance or guarantee, given our limited visibility and context on your operations; I recommend referring to the above documentation to make sure you're operating within the limits, and likewise make sure you're complying with the developer terms.

2. We understand that Dropbox currently does not expose shared-link bandwidth consumption before enforcement. Can you confirm whether this also applies to Dropbox Business admins, with no team-level dashboard, report, or API available?

That's correct, Dropbox does not offer reporting for this.

3. Can a URL returned by /2/files/get_temporary_link be reliably reused for multiple fetches for the duration of its lifetime (documented as four hours—please confirm), including retries by the same or different consumers?

Yes, these links are not single-use, and so can be used multiple times within their life span, which is four hours per the documentation.

4. When streaming a download into a slower third-party upload, does Dropbox impose any read-idle or maximum connection-duration limit?

The Dropbox servers may apply HTTP timeouts and close connections to clean up old/broken connections, however I don't have any official documented limits on this to share.

5. We currently limit /2/files/download to six concurrent requests per selected member and have not observed any 429 responses. Is that a reasonable concurrency level, including when connections remain open while streaming to slower destinations?

I can't offer a specific guarantee; if a particular configuration is working well for you though, I don't see an issue, as long as your clients are able and configured to catch and handle any errors such as 429s and respect any Retry-After headers returned.

6. Do RPC and content calls share the same rate-limit budget?

Yes, the rate limits are shared across call types.

7. If we always honor Retry-After and use exponential backoff with jitter, can repeated API 429 responses ever escalate beyond temporary throttling—for example, to token revocation, app or account restriction, or interruption of the team’s sharing activity?

Dropbox API rate limiting windows are generally relatively short, and do not automatically trigger other escalated actions like that. However Dropbox does reserve the right to perform actions as outlined in the developer terms.