API export limits
Programmatic exports through the GA4 Data API are bounded: a single response returns up to a fixed number of rows, and each query is limited in how many dimensions and metrics it may combine. Pulls that ignore these limits truncate without obviously failing, producing partial datasets that look complete. This page explains the row and field caps and the pagination that avoids silent truncation.
The limits that bite exports
The GA4 Data API enforces structural limits per request. A runReport response returns at most a capped number of rows (the limit parameter has a documented maximum), and a single query may combine only up to a fixed number of dimensions and a fixed number of metrics. Exceeding the field caps returns an error; exceeding the row cap simply returns the first page.
Paginating instead of truncating
Because the row cap returns a page rather than an error, an export that does not paginate looks successful while quietly dropping everything past the first page. Correct exports loop with the limit and offset parameters (and check rowCount) until all rows are retrieved.
Field caps require a different fix: split a too-wide report into multiple queries and join the results, rather than trying to request every dimension at once. Combined with sampling and thresholding on the source side, these limits explain many 'the export doesn't match the UI' reports.
- Per-request row cap returns a page, not an error
- Caps on dimensions and metrics per query (errors if exceeded)
- Paginate with limit/offset and compare against rowCount
- Split wide reports into multiple queries and join
How it appears in analytics and logs
An API export that stops at a round number of rows is hitting the per-request limit; the rest exists but requires pagination via offset/limit.
Diagnostic use case
Explain why an automated GA4 Data API export returned fewer rows than the UI, or why a wide report rejected extra dimensions.
What WebmasterID can help detect
WebmasterID exposes its first-party data with documented export semantics, so you can pull complete datasets without reconstructing a vendor's pagination quirks.
Common mistakes
- Assuming one API call returns the entire dataset.
- Not checking rowCount before treating an export as complete.
- Requesting more dimensions/metrics than a single query allows.
Privacy and accuracy notes
API exports can carry granular data; govern credentials and scope. This page is educational, not legal advice on data handling.
Related pages
- Quota and throttling
GA4's Data API meters usage with token buckets per property, charging more tokens for larger and more complex queries. Concurrent requests are also capped. Pipelines that fan out too many or too-expensive queries exhaust the quota and get throttled with quota errors, so an export can fail partway and leave a gap. This page explains the quota model and how to stay under it.
- Partial data and freshness
Data freshness is how recently the data behind a report was processed. The current day and the most recent hours are partial: not every event has arrived or been processed, so totals are understated and shapes incomplete. GA4 exposes freshness expectations and shows real-time data separately. This page explains partial-data pitfalls and how to read freshness.
- BigQuery vs UI discrepancies
When GA4's BigQuery export and the reporting interface show different totals, it is usually not a bug. The UI applies sampling, data thresholds, (other) aggregation, and behavioral/conversion modeling on top of the raw event stream; BigQuery exports the unmodeled, unsampled events. Knowing which transformations the UI adds explains most gaps.
- MCP analytics
Programmatic access with documented export semantics.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.