Google Docs automations

Google Drive's write rate limit of 3 insert/create requests per second per account is a hard ceiling that cannot be raised via quota request. When a Make scenario or n8n workflow tries to create 50+ Google Docs in a loop without throttling, you'll start receiving HTTP 429 errors mid-run — and depending on how the platform handles retries, some documents will be created and others silently skipped with no deduplication safety net. Always build in a delay node between creation steps and implement idempotency checks using document title or metadata before trusting a bulk run completed successfully.

The Google Drive changes.watch() method used by most platforms for Docs change triggers is notoriously unreliable at volume — real-world reports describe watch channels that receive an initial sync notification then go completely silent, with no errors returned and polling working fine in the same setup. Separately, bulk file operations can cause the Drive API to flood your endpoint with hundreds of near-duplicate push notifications in rapid succession, which will exhaust execution limits on cloud plans for Zapier, Make, and Pipedream faster than you'd expect. Until platform support for the newer Workspace Events API (Pub/Sub-based) is widespread, budget for polling fallbacks and external throttling on any production workflow that depends on Docs change detection.

If your n8n, Make, or Pipedream automations authenticate via a service account rather than individual user OAuth, all API calls are attributed to a single user — meaning the 100 requests per 100 seconds per user quota is shared across every workflow running simultaneously. A team that individually stays well under quota can collectively breach it with concurrent runs, resulting in 429 errors that are hard to diagnose because no single workflow looks like the culprit. This is especially painful in n8n self-hosted environments where multiple workflows can trigger simultaneously with no built-in global rate-limit coordinator.