Same error from a different destination (HubSpot CRM API),
destination logs confirm calls never arrived
Adding a corroborating data point from a separate Apps Script project that
hit the identical error today (Apr 28 2026, ~13:31 UTC). Different account,
different destination domain, different use case — same error format and
same “appeared out of nowhere” pattern.
Environment
- Google Workspace account (paid, well-established)
- Standalone Apps Script project (not Ads Scripts)
- Single user, ~3-5 time-driven triggers per day
- Destination: api.hubapi.com (HubSpot CRM v3 search endpoints)
- Daily call volume: ~85-200 calls/day average over the past 30 days
(well under the documented 100K/day Workspace ceiling)
Error received
Exception: Bandwidth quota exceeded:
https://api.hubapi.com/crm/v3/objects/emails/search.
Try reducing the rate of data transfer.
Thrown by: UrlFetchApp.fetch()
Caller chain: runDiagnostics → getEngagementCount → hubspotPost (UrlFetchApp.fetch)
Key data point: destination confirms the call never arrived
Pulled HubSpot’s API call audit log for the integration’s private app token.
For Apr 28, only THREE successful calls are recorded (all 200 OK,
/calls/search), all in a 1-second window immediately preceding the failed
call. The /emails/search call that threw the error in Apps Script has no
corresponding entry on the destination side — confirming the throttle is
applied at Apps Script’s egress layer, not by the destination API.
7-day call breakdown on the destination (for context — well under any
documented limit):
Apr 22: 72 Apr 25: 30
Apr 23: 193 Apr 27: 119
Apr 24: 186 Apr 28: 3 (then throttled)
Zero non-200 responses across 4,623 logged calls in the past 30 days.
Why this is informative
This rules out the destination API as the source of the error. The same
bandwidth quota error is appearing across:
- Google Ads Scripts → ads endpoints (original post)
- Standalone Apps Script → HubSpot CRM API (this report)
Suggesting the throttle is internal to UrlFetchApp itself, scoped at the
Apps Script execution layer rather than tied to any specific destination
domain. If it were domain-scoped, we wouldn’t expect to see it from such
different destinations under different accounts hitting different APIs.
Adding the same questions to the original — particularly:
- What quota does this map to in the Apps Script internals?
- Is enforcement per-user, per-domain, or per-execution?
- Any chance of getting this added to the official quotas page so it’s
measurable / debuggable?
Will update if a workaround surfaces. Currently testing exponential
backoff retry on the catch block as a mitigation.