GA4 Data API quotas, explained by people who hit them

Written by Uptimal, the team that builds and operates Upbuild and runs marketing analytics for multinational clients across the globe. Everything below reflects how the connector actually behaves in production.

Every serious GA4 API user eventually meets a 429. The Data API meters properties with token budgets: each request costs tokens scaled by its complexity (date ranges, dimensions, filters), drawn from per-property pools per hour and per day, with separate concurrent-request caps, and standard properties get materially smaller pools than 360. None of this is secret, all of it is routinely ignored until it bites.

The practical translation

Simple reports cost little; monster queries (long ranges, many dimensions, heavy filters) cost multiples. Ten people hammering one property share one pool. Realtime has its own budget. And exhausting the hourly pool degrades everyone’s afternoon, which is why quota behaviour belongs in vendor evaluation, not post-mortems.

How conversational access stays polite

Three behaviours keep an MCP connection comfortably inside standard-property limits in our production experience. Tight queries: the assistant asks for the dimensions the question needs, not export-everything. Short-lived caching of identical requests: the second person asking Monday’s question should not spend Monday’s tokens twice. Honest errors: when a pool is exhausted, a readable “quota, retry after” message the assistant can relay beats a mystery failure. Upbuild implements all three; the GA4 guide covers the rest of the platform behaviour.

When quotas mean you want a pipeline instead

Massive historical pulls and high-frequency programmatic use are pipeline work against the API directly, budgeted deliberately, possibly on a 360 property. The decision logic lives in MCP vs API; the one-line version: conversations sip, pipelines gulp, size the vessel to the drinking.

Frequently asked questions