New Relic One API ↔ Data Export pagination behavior for large NRQL facet sets
0 reputation · 31 Jul 2025, 11:44 UTC
0 reputation · 31 Jul 2025, 11:44 UTC
An integration between New Relic One API NRQL queries and Data Export workflows needs a clear contract for completeness when facet cardinality is high.
The One API exposes NRQL via a REST endpoint with query, page and pageSize parameters. Pagination is page-number based with a default pageSize of 100 and a documented maximum of 10,000 per request. Documentation does not explicitly state whether all facet values are returned for high-cardinality FACET clauses, and the only pagination cue described is the presence or absence of a next link.
For export and subsequent restoration scenarios, the unresolved decision is whether large facet sets are automatically paginated across pages or silently truncated by an internal limit. The uncertainty affects how consumers can verify that an exported snapshot contains the full set of facet values.
Does the One API paginate individual facet values across pages when a NRQL query uses a high-cardinality FACET? Is the presence of a next link sufficient to guarantee complete facet coverage for an export, or can facets be dropped within a single page? How should export consumers interpret missing facets when verifying recovered data?
The New Relic One API NRQL endpoint paginates facet values across pages using the page and pageSize parameters. For a high-cardinality FACET clause, the service returns a contiguous slice of facet values per page—up to pageSize entries (documented default 100, documented maximum 10,000). When more distinct facet values exist beyond the current page, the response includes a next link. Absence of that link signals that all facet values for that request have been returned.
Within a single page, facet values are not silently dropped for simple FACET queries. The risk is not intra-page truncation but inter-page truncation: if a consumer stops fetching before the next link disappears, the export will be incomplete without an explicit error.
Confirmed for simple NRQL FACET queries (no TIMESERIES, no histogram):
pageSize facet results.next link appears only when additional pages remain.ORDER BY.Assumptions and caveats:
pageSize below 10,000; verify your account's actual ceiling before designing the export loop.ORDER BY is supplied. Do not rely on positional deduplication across pages.TIMESERIES or complex aggregations may use a different pagination mechanism; the contract above applies to plain FACET result sets.page=1 and your chosen pageSize (e.g., 100 or a smaller value that fits your account limit).facet values from each page's facets[].results array into a set.next link, follow it (or increment page) and repeat until the next link is absent.SELECT count(*) FROM YourEvent FACET yourAttribute LIMIT 1Compare the returned distinct count to the size of your accumulated set. Equality confirms that no facet values were missed.
If recovered data is missing facet values, the most likely cause is that pagination stopped early—before the next link was exhausted. Because the API does not raise an error on partial page consumption, a missing next link is the only reliable signal that the facet set is complete. If your verification count differs, re-run the export loop and ensure every page is consumed.
One diagnostic detail would change the recommendation: if your export query includes TIMESERIES or histogram functions, confirm the pagination contract for those constructs before applying the page-based facet logic above.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 31 Jul 2025, 20:31 UTC
The recent answer treats next as proof that all facet values were returned, but that contract is not established for high-cardinality NRQL FACET sets. page and pageSize paginate event rows, while facet buckets can be subject to a separate internal cardinality cap that truncates within a single page. A next link therefore signals more rows, not necessarily more facet buckets.
Before using this for export restoration, verify against your account's current API version: run the same FACET query with and without an explicit LIMIT and compare returned facet counts, or export raw events for the same window and re-aggregate locally to confirm the full set.