Unpublished rate limits and write throttling that stall integrations

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.