Unpublished rate limits and write throttling that stall integrations
Ongoing
Dropbox enforces rate limits it does not publish, returning HTTP 429 errors — including a separate too_many_write_operations limit triggered by parallel writes to the same folder — that can throttle backup tools and bulk integrations without warning.
What happened
Dropbox's API enforces rate limiting but does not publish the exact thresholds, telling developers only that the limits 'are not designed to inhibit normal applications.' When an app exceeds them, calls return HTTP 429 with reason too_many_requests and a Retry-After header indicating how long to wait. For developers that means limits can be hit unexpectedly, and the remedy — back off, batch, and optimize call patterns — must be discovered empirically rather than designed against a documented quota.
A second, separate throttle catches write-heavy integrations: writing to a file first acquires a lock on its namespace (folder tree), and enough parallel writes to the same namespace create lock contention, returning HTTP 429 with reason too_many_write_operations. Backup, migration, and sync tools that fan out parallel uploads into one shared folder are exactly the workloads that trip this, and the documented fix (upload sessions, batch endpoints, serialized commits) again requires re-engineering. The opacity of the limits — no published numbers — makes capacity planning for large integrations a matter of trial and error.
Impact
Undisclosed limits and namespace write-contention errors are a persistent friction point for anyone building data-movement tooling on Dropbox. They surface as intermittent failures that are hard to reproduce and force developers to add retry/backoff and batching logic, raising the cost and fragility of integrations — a recurring complaint in Dropbox developer forums.