Лимиты и ошибки
Для разработчиков

Лимиты и ошибки

HTTP-коды

КодЗначение
200Успех
201Объект создан
204Успех, тело ответа пустое
400Невалидный запрос (нет обязательных полей и т.п.)
401API-ключ отсутствует или невалиден
403Нет доступа к ресурсу
404Ресурс не найден
429Превышен лимит запросов
5xxОшибка на стороне сервера — повторите запрос позже

Структура ошибки

HTTP 400
{
  "error_code": "VALIDATION_ERROR",
  "error_message": "contact must include at least one of internal_id, telegram_id, email",
  "detail": null
}

error_code — UPPER_SNAKE_CASE строка стабильная для программного матчинга на вашей стороне. error_message — человекочитаемое описание (на английском, без локализации).detail — опциональный контекст в JSON, специфичный для ошибки (например {"field": "email"} для VALIDATION_ERROR). Полный список кодов и категории — в backend app.core.errors.ErrorCode (несколько сотен значений; стабильны от релиза к релизу — переименование = breaking).

Rate limiting

Default-лимит — 300 запросов в минуту на IP клиента (≈5 req/s sustained, бёрсты до 300 в окне). Применяется ко всем endpoint'ам без своего @limiter.limit. Для критичных flow (auth, password reset) limits жёстче — HTTP 429 вернётся сразу, заголовки Retry-After и X-RateLimit-Resetподскажут когда повторить.

Long-polling endpoint /api/v1/updates не тарифицируется пока соединение «висит» — учитывается только сам момент открытия запроса, не время ожидания событий.

Storage — Redis (стратегия fixed-window). Лимит шарится между процессами / pods. При недоступности Redis limiter не блокирует — это безопасный fallback, чтобы кратковременная проблема инфры не ронияла API.

Была ли страница полезной?