Интеграция по API выглядит простой задачей: одна система отправляет запрос, другая отвечает. На демо всё работает с первого раза. Сложности начинаются потом — когда внешний сервис отвечает с задержкой, заказ приходит дважды, а данные в CRM и на складе перестают совпадать.
Подключение одной системы — платёжного сервиса, службы доставки или CRM — обычно занимает 1–3 недели и стоит от 200 тыс. ₽. Связка нескольких систем с синхронизацией данных — 1,5–3 месяца и от 1,3 млн ₽. Разница между этими цифрами — как раз в рисках, о которых ниже.
С чего начать
Первый шаг — не выбор технологии, а описание обмена. До разработки нужно ответить на несколько вопросов.
Какая система главная для каждого вида данных? Цены живут в учётной системе, клиенты — в CRM, статусы доставки — у службы доставки. Если для одного вида данных главных систем две, расхождения неизбежны.
Какие данные передаются и в каком направлении? Заказы с сайта в CRM, остатки со склада на сайт, оплаты в учётную систему. Каждое направление — отдельный поток со своими правилами.
Как быстро данные должны доходить? Оплата должна поменять статус заказа сразу. Остатки могут обновляться раз в несколько минут. Отчёты — раз в сутки. От этого зависит способ обмена.
Что делать, если что-то пошло не так? Кто узнаёт о сбое, что происходит с данными, которые не дошли, и как их отправить повторно.
Ответы складываются в схему обмена. Это короткий документ, но он экономит недели: разработчики не угадывают логику, а заказчик заранее видит, что будет происходить с его данными.
Риск 1: документация
Качество чужой документации — первое, что определяет срок интеграции. Хорошая документация описывает методы, форматы, ошибки, лимиты запросов и даёт тестовую среду. С ней подключение идёт по плану.
Бывает иначе:
- документация устарела и не совпадает с тем, как API работает на самом деле;
- тестовой среды нет, и проверять приходится на рабочих данных;
- коды ошибок не описаны, а поддержка поставщика отвечает днями.
Что помогает: запросить документацию и тестовый доступ до оценки, а не после подписания договора. Если их нет, закладывать время на исследование API и честно говорить об этом в смете.
Риск 2: ошибки и повторы
Внешняя система рано или поздно будет недоступна — на минуту, на час, на время обновления. Вопрос не в том, случится ли это, а в том, что тогда произойдёт с вашими данными.
Надёжная интеграция предусматривает:
- повторные попытки — если сервис не ответил, запрос отправляется снова через некоторое время;
- защиту от дублей — повторная отправка не создаёт второй заказ или второй платёж;
- журнал обмена — видно, какие данные, когда и с каким результатом переданы;
- мониторинг — о сбое команда узнаёт раньше, чем клиенты.
Без этого интеграция работает до первого серьёзного сбоя, а потом менеджеры неделю вручную сверяют заказы.
Риск 3: синхронизация данных
Когда системы обмениваются данными в обе стороны, появляется самый коварный риск — расхождения. Клиента изменили в CRM, пока его же правили на сайте. Остаток списали на складе, но сайт об этом ещё не знает. Заказ отменили, а оплата уже прошла.
Снизить риск помогают простые правила:
- у каждого вида данных одна главная система, остальные только получают изменения;
- у каждой записи общий идентификатор во всех системах;
- конфликты разрешаются по заранее описанному правилу, а не «как получится»;
- раз в какое-то время данные сверяются автоматически, и расхождения попадают в отчёт.
Если данных много и они меняются часто, иногда разумнее поставить между системами промежуточный сервис, который принимает, проверяет и раздаёт изменения. Это дороже на старте, но проще в поддержке.
Риск 4: жизнь после запуска
Интеграция — не разовая работа. Чужие системы обновляются: меняются версии API, поля, правила авторизации, лимиты запросов. Поставщики обычно предупреждают заранее, но кто-то должен это предупреждение прочитать и обновить интеграцию.
Что стоит предусмотреть:
- изоляцию — обращения к каждой внешней системе собраны в отдельном модуле, и изменения её API не затрагивают остальное;
- мониторинг продолжает работать после запуска, а не только в первые дни;
- ответственного за интеграции — у вас или у подрядчика по договору поддержки.
На нашу работу действует гарантия 6 месяцев: ошибки в сделанной интеграции исправляем за свой счёт. Обновления под изменения чужих систем — это уже сопровождение, о нём лучше договориться заранее.
Как выбрать способ интеграции
Способ зависит от того, как быстро нужны данные и что умеют сами системы:
| Способ | Когда подходит |
|---|---|
| Прямые запросы по API | нужен ответ сразу: оплата, проверка наличия, расчёт доставки |
| Уведомления от внешней системы | система сама сообщает о событии: оплата прошла, статус изменился |
| Регулярная выгрузка | данных много, задержка в минуты или часы допустима |
| Промежуточный сервис | систем несколько, данные идут в разные стороны |
Часто в одном проекте используются сразу несколько способов. Важно не смешивать их для одного и того же потока данных.
Короткий чек-лист перед стартом
- Для каждого вида данных определена главная система.
- Есть документация и тестовый доступ к внешним API.
- Описано, что происходит при ошибке и кто о ней узнаёт.
- Понятно, как быстро данные должны доходить.
- Договорились, кто поддерживает интеграцию после запуска.
Подробнее о том, как мы проектируем и делаем интеграции, — на странице интеграции с API.
Хорошую интеграцию почти не замечают. Заказы просто доходят, остатки просто совпадают. Вся работа — в том, чтобы так было и в тот день, когда что-то пошло не так.
