---
title: "Rate limits — requests, points, and how they are counted | Data Tactical Group"
route: "/docs/api/rate-limits"
updated: "2026-10-23"
---

# Two rate ceilings and one meter

120 requests a minute per key, 300 a minute per organization, at most 400,000 cells per request, and a monthly points allowance by plan.

## Requests

Requests are limited by two token buckets that must both pass: 120 a minute per key and 300 a minute per organization, across all its members and keys, the same on every plan. The buckets refill continuously rather than resetting on the minute. Over either, the answer is a 429 with the code `rate_limited` and a `Retry-After` in seconds; wait that long, then resume.

Responses to a key carry `X-RateLimit-Limit` (the key’s ceiling), `X-RateLimit-Remaining` and `X-RateLimit-Reset`, the seconds until the bucket is full again. A request refused before the key is known, such as a 401, carries none of them.

## Cells: the size of one request

A single request may cover at most 400,000 cells, the same for every key. A cell is one series at one period, so a request’s size is its number of series times its number of periods, counted before the query runs. Over it, the answer is a 400 with the code `cell_cap`, naming the request’s `cells` and the `cap`. A request may also return at most a fixed number of series, and over that the code is `series_cap`. Narrow the areas, the codes or the period range, or [page](/docs/api/paging) the result: the ceiling measures one page, not the whole result. Two states at every industry level over the whole quarterly axis is over it:

Request

```
curl "https://api.datatactical.group/v2/industry/series?areas=22,48&naics_level=all&granularity=quarterly&from=2004q1&to=2036q4" \
  -H "Authorization: Bearer $DTG_API_KEY"
```

Response · replayed 2026-10-05 against vintage 20260913.

```
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json; charset=utf-8
​
{ "type": "https://api.datatactical.group/problems/cell_cap",
    "title": "Bad Request", "status": 400,
    "detail": "Request resolves to 4318 series x 132 periods = 569976 cells; the caps are 10000 series and 400000 cells per request. A cell is one series at one period. Narrow the areas, codes or period range, or page with cursor and limit.",
    "code": "cell_cap", "cells": 569976, "cap": 400000 }
```

## Points: the monthly meter

Data leaving through the API, and every CSV or spreadsheet export, is metered in points against a monthly allowance per organization. A point is one data value a response carries, and a value that is zero, null, or rounds to zero at its display precision costs nothing. Only data values are metered: each non-zero value of a measure costs one point, and the labels that come with it (disclosure, reliability and the other flags) cost nothing. A cell is not a point: one cell of an industry series carries several values, so the same request is larger counted in points than in cells.

With the API add-on the allowance is 2,000,000 on Local, 20,000,000 on Regional and 100,000,000 on National; without it, for file export, 2,000,000, 5,000,000 and 10,000,000. The allowance runs per calendar month in UTC and unused points never carry over. When it is spent, API requests and file exports answer 429 with the code `points_exhausted`, and the `Retry-After` runs to the start of the next UTC month. Browsing in the app is not metered. Sandbox use is counted on its own and never spends the live allowance. Usage to date is at `GET /v2/account/usage` and on the account page.

The API is for integration, not for retrieving the corpus. Usage is recorded by county and period, and a person reviews an organization’s usage when it looks like extraction rather than use. No threshold is published.

## Capacity

When the whole service is at capacity a data request is refused with 429 `server_busy` (in the sandbox, `sandbox_busy`) and a `Retry-After`. It is not counted against your rate or your points; retry after the interval.

## As the API document states them

The limits as the API's OpenAPI document states them, generated from it when this site is built. Where this section and the prose above differ, this section is the API's own statement.

- Request size: at most 400,000 cells per request, the same for every credential, an API key and a session alike. A cell is one series at one period. Over it: 400 [`cell_cap`](/docs/api/errors#code-cell-cap) `{cells, cap}`. The guard is a load bound checked before the query; it never meters anything.
- Request rate: 120 requests a minute for every credential, API key and session alike, and 300 a minute per organization across all its members, keys and sessions. Over either: 429 [`rate_limited`](/docs/api/errors#code-rate-limited) with `Retry-After`; every answer carries `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset`. The sandbox's ceilings are its own and lower (60 a key, 120 an organization).
- Points: the one monthly allowance. A point is one data value a metered response carries: API-key requests and every CSV or workbook export count; the app's own screens do not. Only data values are metered: each non-zero value of a measure costs one point, and the labels that come with it (disclosure, reliability and the other flags) cost nothing. The allowance is per organization and plan (`GET /v2/plans`, `GET /v2/account/usage`), counted per UTC calendar month and per credential mode. Over it: 429 [`points_exhausted`](/docs/api/errors#code-points-exhausted) with `Retry-After` to the end of the month. The monthly request quota is retired as a published limit.
- Capacity: the data routes share one admission cap. Past it: 429 [`server_busy`](/docs/api/errors#code-server-busy) (or [`sandbox_busy`](/docs/api/errors#code-sandbox-busy) on the sandbox) with `Retry-After`; not metered and not a limit on the caller.
