Лимиты скорости

Платформа применяет per-IP лимиты к каждому входящему HTTP-запросу, чтобы шумный или скомпрометированный клиент не деградировал сервис для остальных. Лимиты жёсткие на auth + анонимных эндпоинтах и мягкие на трафике вебхуков провайдера.

Когда клиент превышает корзину, ответ:

HTTP/1.1 429 Too Many Requests
Retry-After: 17

Значение Retry-After — это число секунд до сброса текущего минутного окна. Подождите столько, потом повторите — повторный бёрст немедленно просто продлит cooldown без полезной работы.

Таблица лимитов

Семейство эндпоинтов	Лимит	Scope	Заметки
Auth	20 / минуту	per source IP	Login, 2FA verify, password reset, accept invitation, refresh-token. Достаточно медленно, чтобы остановить credential-stuffing, не мешая настоящему оператору.
Access-request форма	5 / минуту	per source IP	Форма "запросить доступ" на странице логина оператора. Жёстко, потому что анонимная и подвержена спаму / harvesting'у адресов.
Входящий вебхук провайдера	200 / минуту	per source IP	Используется для callback-эндпоинта upstream provider'а. Допускает реалистичный бёрст из одного региона, не открывая дверь шумному соседу.
Остальные эндпоинты	нет per-endpoint лимита	per (productId, environment) — enforce через валидацию API-ключа	Проверка product-credential имеет собственную anti-abuse позицию (allowlist по client IP, ротация ключей, подписанный nonce на чувствительных потоках).

Best-practice поведение клиента

• Кешируйте идемпотентные чтения (level config, applicant list) и избегайте re-fetch на каждом render — данные меняются только когда оператор кликает Save.
• Используйте exponential backoff на 429. Разумный старт — значение Retry-After, затем 2×, 4×, потолок 30 с.
• На bulk-импортах сами себя ограничивайте в источнике, а не в цикле. Два запроса в секунду на IP держат вас глубоко внутри всех корзин.
• Используйте разные API credentials на разные workload-ы, чтобы sync-job, получивший rate-limit, не блокировал интерактивный трафик operator-портала.

Исходящие webhook доставки (информационно)

Исходящие webhook доставки от нас → к вашему endpoint используют Hangfire очередь с exponential backoff per delivery — они не подчиняются входящим лимитам выше. Ваш endpoint может рассчитывать на:

• Не более одной in-flight доставки per outbox entry в любой момент времени (с учётом same-id re-delivery семантики, описанной в разделе idempotency гайда Webhook Integration).
• Расписание retry: 10s · 30s · 1m · 5m · 15m до 5 попыток до dead-letter.
• X-Webhook-Delivery-Id header per attempt — дедуплицируйте по нему.

Если вы видите устойчивый бёрст от нас, это результат event backlog'а (например, вы были offline и мы догоняем). Очередь сама себя темпит в рамках сконфигурированной worker concurrency, и ваш endpoint всегда увидит ровно одну доставку за раз per outbox entry.