Лимиты запросов
Ограничения частоты запросов и заголовки ответов.
API ограничивает частоту запросов фиксированным окном: счётчик ведётся отдельно для каждой команды и клиента (OAuth-приложения, пользователя или IP-адреса), начинается с первого запроса и сбрасывается по истечении окна. Лимит по умолчанию — 1000 запросов в минуту на раздел API. Отдельные операции — вход и восстановление доступа, выдача OAuth-токенов, публичное подписание, отправка форм — защищены собственными, более строгими политиками.
Каждый ответ содержит заголовки лимитов без префикса X- в формате черновика IETF RateLimit header fields for HTTP. Это ещё не утверждённый стандарт, поэтому формат может уточняться вместе с черновиком:
| Заголовок | Пример | Значение |
|---|---|---|
RateLimit-Policy | "default";q=1000;w=60 | политика: имя, квота q запросов за окно w секунд |
RateLimit | "default";r=997;t=42 | состояние политики: осталось r запросов, окно сбросится через t секунд |
RateLimit-Limit | 1000 | квота за окно |
RateLimit-Remaining | 997 | осталось запросов в текущем окне |
RateLimit-Reset | 42 | секунд до сброса окна |
Если к запросу применено несколько политик — например, общая default и строгая submit для отправки формы, — в RateLimit-Policy и RateLimit перечисляются все через запятую. Отдельные заголовки RateLimit-Limit, RateLimit-Remaining и RateLimit-Reset описывают политику, ближайшую к исчерпанию, — они сохранены для совместимости с клиентами ранних версий черновика.
При превышении лимита сервер возвращает 429 Too Many Requests в формате Problem Details с кодом RATE_LIMITED (операции входа и восстановления доступа — с кодом TOO_MANY_REQUESTS) и заголовком Retry-After — количеством секунд до следующей попытки.
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json; charset=utf-8
Content-Language: ru
Retry-After: 120
RateLimit-Policy: "default";q=1000;w=60, "submit";q=10;w=300
RateLimit: "default";r=958;t=31, "submit";r=0;t=120
RateLimit-Limit: 10
RateLimit-Remaining: 0
RateLimit-Reset: 120Рекомендация: при получении 429 повторяйте запрос не раньше, чем через указанное в Retry-After число секунд, а при повторных отказах увеличивайте паузу экспоненциально со случайным разбросом, чтобы клиенты не повторяли запросы одновременно.