Skip to main content
The Data API enforces a rate limit of 2,500 requests per hour per API key. All /v1/ endpoints share this one budget: category endpoints, /v1/raw, /v1/catalog and /v1/changes draw from the same counter. Every request with a valid key counts once, including retries, polling calls, 304 Not Modified responses and client errors such as 400, 403, 404 or 422. When you exceed the limit, the API returns a 429 status code and you must wait until the current hour window resets before making additional requests. Each API key has its own budget. A second key of the same customer is not affected when the first one hits the limit.

​
Requests without a valid key

Requests without an X-API-Key header, or with an unknown, disabled or expired key, do not count toward any budget. The API answers them with 401 or 403, never with 429.

​
429 Response Example

When you hit the rate limit, the API responds with an RFC 7807 problem JSON body:

​
Handling Rate Limits

Successful responses (2xx, 304) and 429 responses include three headers so you can throttle proactively instead of waiting for a 429:
  • X-RateLimit-Limit — requests allowed in the window (2500)
  • X-RateLimit-Remaining — requests left in the current window, across all endpoints
  • X-RateLimit-Reset — Unix timestamp in seconds at which the window resets
Other error responses with a valid key (400, 403, 404, 422) do not carry these headers, but still count. The next successful response shows the current state. If you do receive a 429 response, use the Retry-After header instead of guessing a wait time:
  1. Stop sending new requests immediately.
  2. Read the Retry-After header — it gives the exact number of seconds until the current window resets. Wait at least that long before retrying.
  3. Double the wait time on each subsequent retry if the 429 persists.
  4. Resume normal request spacing once requests succeed again.
For long-running sync jobs, spread requests evenly across the hour instead of bursting at the start. For example, a job that issues one request every 2 seconds will stay safely under the 2,500 request limit.
Use the Delta Sync endpoint (GET /v1/changes) to poll for changed tables instead of repeatedly querying every endpoint. This lets you skip endpoints that have not changed since your last sync, reducing your overall request volume.