Request size & limits
To keep the service responsive for everyone, each request has a ceiling on how much data it can ask for. Understanding how request size is calculated helps you avoid rejections and design efficient queries.
The cost model
The "size" of a request is, roughly:
sum over all queries of ( days in period × metrics × brands )
- days — the length of the period, including any extra days pulled in by a moving average.
- metrics — the number of metrics requested, counting each once — except
index, which counts as six (it is a composite of six underlying metrics). - brands — the number of brands the entity resolves to. A single brand is one; a whole sector or an "all brands" expansion resolves to many.
What happens at the ceiling
If a request exceeds the limit it is rejected with HTTP 400 and a message
advising you to reduce the number of brands, the length of the period, the
number of metrics, or the moving average. As a rough guide the ceiling is on the
order of a few hundred thousand of these units, so very broad requests (every
brand in a large sector, six metrics, several years, daily) need to be split
into smaller requests.
Rate and volume limits
Separately from per-request size, requests are throttled over a rolling
60-second window: a client may pull at most 10.0 MiB of response data
or make 200 requests, whichever comes first. Exceeding either returns
HTTP 429, with a message saying which factor was the limit. See
Limits & quotas for how to work within
them.
Staying within limits
- Split a broad query into several narrower ones (e.g. by metric or by time range) and combine the results client-side.
- Prefer resampling to a coarser granularity when you do not need daily data.
- Remember that
indexand "all brands" entities multiply size quickly.