Rate limiting

There are two types of limits — read requests (GET) and write requests (POST, PUT, PATCH, DELETE) — both over a 1-hour sliding window: each request counts against the limit for the next 60 minutes; there is no fixed-time reset.

Type	Limit
Read (GET)	60 requests/hour
Write (POST, PUT, PATCH, DELETE)	1000 requests/hour

If your operation needs a higher limit, talk to support or sales.

Response headers

On every request, the server attaches to the response headers the limits used and when the count frees up:

Header	Example	Description
ratelimit-limit	60	Request limit for the client.
ratelimit-name	throttle_v1_write	Name of the throttle used.
ratelimit-remaining	0	Number of requests still available.
ratelimit-reset	1782648000	Unix time — when the count resets.
retry-after	30	Seconds until the count resets. See Retry-After.

Example of a successful response

Date: Fri, 17 Jul 2026 12:00:00 GMT
Content-Type: application/json; charset=utf-8
ratelimit-limit: 1000
ratelimit-remaining: 486

Example of a blocked response

When the limit is reached, the server returns HTTP 429 Too Many Requests. Wait the number of seconds from the retry-after header before the next request.

HTTP/1.1 429 Too Many Requests
Date: Fri, 17 Jul 2026 12:00:00 GMT
Content-Type: application/json; charset=utf-8
ratelimit-limit: 1000
ratelimit-remaining: 0
ratelimit-reset: 1784293200
ratelimit-name: throttle_v1_write
retry-after: 3600

{ "error": { "code": "rate_limited", "message": "Write request rate limit exceeded for this token." } }

tip

Use limit=100 on listings and the filters to reduce the number of requests — and handle 429 with backoff based on retry-after, never with an immediate retry.

Reference: RateLimit header fields for HTTP