Ограничения частоты, размер тела, версионирование контракта

Лимиты и версионирование

Ограничение частоты

Точка публикации /api/v1/scoring использует общий бакет неаутентифицированных запросов шлюза: порядка 20 запросов в секунду с одного IP-адреса.

Превышение выражается не HTTP 429: запрос либо ожидает свободный слот (растёт латентность), либо домен отвечает семантикой отказа (WAIT + waitSeconds в вердикте).
Планируйте частоту от сценария: score — один раз на чекаут, verdict — перед выдачей реквизита и после каждого WAIT.
При массовых загрузках (батч-миграции истории) согласуйте окно с владельцем платформы.

Лимит	Где проявляется	Как выглядит
Cooldown-лестница выдачи	verdict	`WAIT` + `waitSeconds` (растёт с уровнем)
Сессии раскрытия реквизитов	checkout (вне scoring scope)	`allowed: false` + reason
Копирования на заказ	checkout (вне scoring scope)	`allowed: false` + `copy_limit`

Параметр	Значение	Примечание
Тело запроса	≤ 16 KiB	большее тело — `400`
Таймаут сервера	15 с	проектируйте клиентский таймаут меньше
Схема транспорта	HTTPS	plain-HTTP перенаправляется (`308`)

Контракт версионируется по правилам, а не по путям: ручки живут на стабильных путях /v1/..., изменения поведения несут ruleVersion в ответах (сейчас p2.v10).
Добавление полей в ответы — не ломающее изменение; удалять/переименовывать поля платформа не будет без мажорной версии пути.
reason в вердикте — человекочитаемое поле и может менять формулировки; ветвьтесь на verdict/waitSeconds, не на текст.
При мажорных изменениях платформа опубликует новую спеку (openapi.yaml — источник истины) и зафиксирует изменение в Changelog.

При разборе инцидентов указывайте ruleVersion и orderRef — по ним платформа находит решение в журнале правил.