Лимиты запросов

Лимит запросов защищает API в расчёте на ключ: запросы считаются по каждому API-ключу в фиксированном минутном окне. У запросов на чтение и на запись отдельные лимиты (независимые счётчики):

Операция	Метод	Лимит по умолчанию
Чтение	GET	120 / минуту
Запись	POST, PATCH, DELETE	60 / минуту

Два счётчика независимы — интенсивное чтение никогда не расходует бюджет записи, и наоборот. Заголовки RateLimit-* в каждом ответе отражают счётчик для метода этого запроса.

Заголовки RateLimit

Каждый ответ несёт текущее состояние лимита, поэтому вы можете упреждающе притормаживать, не дожидаясь 429:

RateLimit-Limit: 120
RateLimit-Remaining: 117
RateLimit-Reset: 1751380920

• RateLimit-Limit — потолок для текущего окна.
• RateLimit-Remaining — сколько запросов осталось в текущем окне.
• RateLimit-Reset — Unix-время (epoch-секунды), когда окно сбрасывается и Remaining пополняется.

Считайте эти заголовки источником истины — точное значение лимита со временем может меняться, поэтому читайте его из RateLimit-Limit, а не зашивайте 120 жёстко.

Когда вы превышаете лимит

Как только Remaining достигает 0, дальнейшие запросы в этом окне получают 429 Too Many Requests (rate_limit_error / too_many_requests) с заголовком Retry-After:

HTTP/1.1 429 Too Many Requests
Retry-After: 2
RateLimit-Reset: 1751380920

• Соблюдайте Retry-After — подождите указанное число секунд, затем повторите запрос.
• Используйте экспоненциальную выдержку с джиттером при повторяющемся троттлинге.
• Ещё лучше: следите за RateLimit-Remaining и снижайте темп до того, как достигнете 0.

Ограничения на диапазон

Эндпоинты списка событий требуют диапазона from/to не длиннее 366 дней. Более широкий диапазон отклоняется с 422 validation_error (invalid_request).