How to prevent silent data loss in Google Apps Script with retry and rate-limit layers

A developer discovered that a nightly data-enrichment job silently dropped around 300 rows after an upstream API returned a 429 rate-limit error, causing the script loop to die mid-run with no alert. The root cause was that UrlFetchApp.fetch throws an exception before any retry logic can inspect the HTTP status code, unless muteHttpExceptions is set to true. The proposed fix involves four layered safeguards: exponential backoff with jitter for retries, batched requests via fetchAll to respect concurrency limits, a per-minute rate counter using CacheService to stay within API thresholds, and a dead-letter queue that logs failed calls to a spreadsheet for later replay. UrlFetchApp carries hard daily quotas of 20,000 calls on consumer accounts and 100,000 on Workspace, making quota-aware design essential for high-volume jobs. Together, these patterns ensure transient failures do not silently discard data and can be audited and retried after the fact.