IP Whitelist

IP Whitelist — второй рубеж защиты после API-ключа. Пока он включён, запросы принимаются только с тех адресов, которые вы заранее согласовали. Даже с валидным ключом запрос с чужого адреса будет отклонён.

Что передать

Список точных IPv4-адресов серверов, с которых пойдут запросы к API. Подсети в формате CIDR (203.0.113.0/24) в списке мерчанта не поддерживаются — каждый адрес указывается отдельно.

В список попадают все узлы, с которых реально уходит трафик:

backend-серверы, создающие сделки;
фоновые обработчики и cron-задачи;
прокси или шлюзы, если исходящие запросы идут через них.

Как определяется адрес запроса

Проверяется адрес, с которого запрос пришёл к нам. Если между вашим сервером и платформой стоит ваш собственный прокси, NAT или CDN, мы видим адрес выхода этого узла, а не адрес приложения за ним. В список нужно вносить именно его.

Из этого следуют два практических вывода:

при нескольких точках выхода в список должны попасть все;
при динамическом внешнем адресе whitelist работать не будет — понадобится статический IP.

Как включить

Передайте список адресов персональному менеджеру на этапе интеграции.
Администратор вносит их в панель управления.
Ограничение начинает действовать сразу после сохранения.

Пока список пуст или проверка не включена для вашего кабинета, запросы принимаются с любого адреса — авторизация идёт только по API-ключу.

Что вернётся при несовпадении

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "statusCode": 403,
  "message": "IP_NOT_IN_WHITELIST",
  "error": "Forbidden"
}

Ответ приходит до какой-либо обработки запроса: сделка не создаётся, состояние не меняется, повторять запрос без изменения адреса бесполезно.

Что запомнить

Whitelist ограничивает только ваши исходящие запросы к API. На доставку webhook-уведомлений он не влияет — там за подлинность отвечает подпись.
Адреса указываются точные, без масок.
Обо всех изменениях сообщайте менеджеру заранее.