Безопасные production-настройки

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

Рекомендуемая схема

Настройка	Рекомендация
Отдельный ключ для production	Да
Отдельный ключ для staging	Да
HMAC для write-запросов	Обязательно
Idempotency-Key для создания заявки	Обязательно
IP allow-list	Желательно для server-to-server
Webhooks для статусов	Желательно
Polling статуса	Только как fallback
Минимальные scopes	Обязательно

Production и staging

Не используйте один ключ для всех окружений.

Правильно:

production-crm
staging-crm
production-telegram
staging-telegram

Так проще отключить тестовый доступ, не ломая production.

HMAC

В production HMAC должен быть включен минимум для:

• создания заявки;
• подтверждения оплаты;
• отмены заявки;
• загрузки файлов;
• создания и изменения webhooks.

Если интеграция крупная, включите HMAC для всех приватных запросов.

IP allow-list

Если API вызывается с backend-сервера клиента, добавьте публичные IP этого сервера в allow-list.

Проверьте:

• production IP;
• staging IP;
• NAT gateway;
• load balancer;
• fallback server, если он есть.

Лимиты

API может ограничивать частоту и общий объем запросов.

Лимит	Что значит
Rate limit	Сколько запросов можно делать за короткое время.
Daily quota	Сколько запросов можно сделать за день.
Monthly quota	Сколько запросов можно сделать за месяц.

Если интеграция получает 429, она должна ждать Retry-After, а не повторять запрос бесконечно.

Webhooks вместо частого polling

Не проверяйте статус заявки каждую секунду. Лучше:

1. Подключить webhook order.status_changed.
2. Сохранять события у себя.
3. Использовать status endpoint только когда пользователь открыл страницу заявки или webhook временно недоступен.