Как принимать интеграции: что проверить, чтобы данные не “ехали”

Интеграция считается “готовой” не тогда, когда “запросы ходят”, а когда бизнес-данные сходятся и сбои становятся видимыми и управляемыми.

Ниже — что обязательно проверить на приемке.

1) Полнота и корректность данных

• Все обязательные поля передаются и сохраняются в нужном формате.
• Нет “обрезанных” значений (телефон, email, комментарии, UTM).
• Справочники согласованы (статусы, типы, источники).

Тест: взять 10–20 примеров реальных сущностей и сравнить “до/после” в обеих системах.

2) Идемпотентность: защита от дублей

Если событие придет дважды (а оно придет), система не должна создавать дубликаты заявок/платежей.
Проверка: вручную отправить одно и то же событие повторно и убедиться, что результат один.

3) Статусы и переходы

• статусы в обеих системах взаимно однозначны;
• нет сценариев “оплачено в одном месте, не оплачено в другом”.

Тест: прогнать цепочку статусов по 5–7 сценариям (успех, отмена, возврат, ошибка, повтор).

4) Ошибки и недоступность внешнего сервиса

• что происходит, если внешний сервис “лежит”;
• будут ли повторы и где увидеть “очередь”;
• кто получает уведомление и где смотреть причину.

5) Логи и мониторинг

Минимум должно быть:

• журнал отправок/получений с временем, статусом, ошибкой;
• понятный способ найти конкретный заказ/заявку по ID;
• доступ заказчика к просмотру (или регламент предоставления).

6) Контур и ключи

• тестовые ключи не пересекаются с боевыми;
• тестовый контур не пишет в прод;
• права доступа ограничены.

Если вы принимаете интеграцию по этому чеклисту, шанс “данные поехали” снижается в разы: проблемы ловятся на сценариях и логах, а не в финансовых отчетах через месяц.