Dropbox automations

On Zapier, once the monitored folder hits 4,000 items, the New File in Folder trigger returns a hard error and stops firing entirely — there is no graceful degradation or queue. Make's Watch Files module hits the same ceiling but fails silently: it simply stops detecting new files without alerting you, meaning uploads can go unprocessed for days before anyone notices. The only reliable workarounds are to archive old files out of the watched folder regularly or migrate to a platform like n8n or Pipedream that paginates list_folder responses directly.

The 1 billion monthly upload operations cap applies at the team level, not per app or per workflow. If you have multiple Make scenarios, Zapier Zaps, or Pipedream workflows all writing to Dropbox simultaneously — for example, a file conversion pipeline alongside a CRM sync and a backup job — they compete for the same quota pool. When the limit is exhausted, all calls return a 403 with invalid_account_type/feature until the 1st of the next month, with no partial credit or burst allowance. Make users have also reported HTTP 429 too_many_write_operations errors specifically when two or more scenarios run at the same time, even well below the monthly ceiling.

When many files change at once — a bulk import, a zipped folder extraction, a batch export from another tool — Dropbox fires multiple webhook calls in rapid succession, each containing only user IDs. Your automation platform then has 10 seconds per notification to acknowledge and queue follow-up API calls to retrieve the actual changes. Platforms processing these synchronously (certain n8n webhook configurations, Power Automate HTTP triggers without async handling) can miss notifications or hit secondary rate limits on list_folder calls. The result is incomplete automation runs where some files are processed and others are dropped, with no error logged on the Dropbox side.