Skip to main content

Limits & quotas

Concrete limits and how to stay within them. For the underlying concept, see Request size & limits.

Per-request data ceiling​

Each request is sized by, roughly:

sum over all queries of ( days × metrics × brands )
  • days includes the moving-average lead-in.
  • metrics counts each once — except index, which counts as six.
  • brands is how many brands the entity resolves to; "all brands" entities expand to many.

Exceed the ceiling and the request is rejected with 400. As a rough guide the ceiling is on the order of a few hundred thousand of these units.

Rate & volume limits over time​

Independently of per-request size, the API throttles usage over a rolling 60-second window. High usage can degrade the service for other clients, so a single client is limited to whichever of these it hits first:

  • 10.0 MiB of response data (measured on the raw, uncompressed HTTP response body), or
  • 200 requests.

Usage is assessed over the previous 60 seconds each time a new request arrives (so the practical limit is a few bytes / requests either side of the formal figure). Exceeding either returns HTTP 429, and the error message tells you which factor — request count or data size — was the limit.

Staying within the limits​

  • If request count is the limit: break work into multiple calls spaced ~1 minute apart.
  • If data size is the limit: slice each call into smaller sub-calls — e.g. 1,000 brands as two calls of 500, or several years as one year at a time — then stitch the results together client-side.
  • Resample to a coarser granularity when you do not need daily data.
  • Cache stable results; identical requests may already be served from a short-lived cache.
  • Be mindful of index and "all brands" entities, which multiply size quickly.