Middleware · API

Интеграционный сервис между CRM и остальным ИТ-контуром

Когда прямой связки недостаточно, создаём отдельный сервис обмена: он принимает события, сопоставляет данные, удерживает очередь, повторяет операции и показывает состояние интеграции. Такой слой помогает не прятать сложную бизнес-логику внутри одного виджета.

Обсудить задачу Посмотреть состав работ

amoCRM · официальный партнёр
Битрикс24 · бизнес-партнёр
Код и доступы передаваем

Сначала выбор пути

Разработка — третий вариант, а не первый

Проверяем задачу по возрастающей сложности. Это снижает стоимость владения и число компонентов, которые придётся поддерживать.

01 / Штатно

Настройка платформы

Поля, права, роботы, бизнес-процесс или стандартный webhook закрывают сценарий без нового продукта.

02 / Готово

Партнёрское решение

Сравниваем поддержку нужных объектов, ограничения, обновления, журнал и полную стоимость лицензии.

03 / На заказ

Собственная разработка

Нужна, если процесс, интерфейс, объём, безопасность или контроль ошибок не укладываются в готовые варианты.

Типовые запросы

Когда нужен отдельный сервис

Прямой запрос CRM → API удобен до первого сложного повтора, нескольких направлений обмена или недоступности одной из систем.

Несколько систем

CRM, 1С, сайт, склад, доставка и платежи участвуют в одном заказе и не должны зависеть друг от друга синхронно.

Большой поток

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

Сложный маппинг

Разные справочники, единицы, статусы, валюты, идентификаторы и правила конфликта требуют отдельной модели.

Повтор и восстановление

Операцию можно безопасно повторить, увидеть причину отказа и восстановить диапазон событий без дублей.

Несколько клиентов

Тиражный продукт изолирует настройки, токены, лимиты и журналы каждого аккаунта.

Требования к контролю

Нужны панель состояния, метрики, журнал аудита, роли и подтверждение ручного вмешательства.

Проектные решения

Состояние операции важнее числа API-запросов

Детали ниже определяют эксплуатацию выбранного формата и проверяются до оценки реализации.

Каждая бизнес-операция проходит явные состояния: получена, проверена, ожидает зависимости, выполняется, завершена или требует разбора. Такой автомат состояний показывает, где находится заказ, и не позволяет повторному worker начать создание заново без проверки предыдущего результата.

Контракт сообщения отделяем от конкретного API. Внутреннее событие хранит смысл операции и версию схемы, а адаптеры переводят его в поля amoCRM, Битрикс24 или 1С. Это помогает менять одну платформу без переписывания всей цепочки и проводить контрактные тесты на сохранённых примерах.

Постоянная ошибка не должна бесконечно возвращаться в основную очередь. После ограниченного числа попыток операция попадает в отдельный список с причиной и контекстом. Специалист исправляет данные или конфигурацию, затем запускает именно эту операцию и подтверждает результат.

Даже идеальный журнал не доказывает полноту. Плановая сверка сравнивает источники и получателей по периоду: все ли оплаченные заказы получили нужный статус, нет ли объектов без внешней связи. Расхождение становится отдельной задачей восстановления, а не скрытой ручной таблицей.

Версию контракта записываем рядом с сообщением, а не определяем по текущему коду обработчика. Новый потребитель сначала понимает старый формат, затем отправители переключаются на обновлённый. Это позволяет развивать поток без одновременной остановки всех систем.

Административная панель не должна открывать произвольный повтор без проверки. Оператор видит исходный запрос, последний ответ, число попыток и ожидаемый побочный эффект. Опасное действие требует подтверждения и остаётся в журнале аудита.

Архитектура

Данные проходят через контролируемый маршрут

У каждой операции есть внешний идентификатор, состояние и способ проверить итог. Синхронный вызов используем только там, где он действительно безопасен.

Источник

События систем

Событие, пользовательское действие или плановая выборка.

Контроль

Очередь и оркестрация

Проверка, маппинг, очередь, защита от дублей, журнал и повтор.

Результат

Получатели и сверка

Подтверждение операции, сохранённая связь объектов и сверяемый итог.

Если получатель временно недоступен, операция не должна исчезать или бесконечно создавать новые сущности. Она получает состояние, понятную причину ошибки и управляемый повтор.

Результат проекта

Передаём не только код, но и управляемую систему

Состав зависит от масштаба, но критичные решения, доступы и сценарии восстановления не остаются в переписке разработчика.

Контракты данных

Версии схем, обязательные поля, преобразования, справочники и обратная совместимость.

Очередь операций

Статусы, приоритет, дедупликация, отложенный повтор и отдельная очередь неразобранных ошибок.

Хранилище состояния

Связь идентификаторов, контрольная сумма, история попыток и результат последней сверки.

Наблюдаемость

Структурированные логи, метрики, трассировка, алерты и панель для поддержки.

Безопасность

Минимальные права, секреты вне кода, ротация, аудит доступа и защита входящих вебхуков.

Runbook

Как диагностировать, остановить поток, повторить события, восстановить бэкап и подтвердить целостность.

Специфика задачи

Признаки промышленной интеграции

Не каждый проект требует сложной платформы, но критичные свойства нужно выбирать осознанно.

Свойство	Как выглядит на практике	Что предотвращает
Идемпотентность	Повтор одной операции возвращает тот же бизнес-результат	Дубли сделок, платежей и документов
Повтор с паузой	Временная ошибка повторяется по правилам, постоянная уходит на разбор	Шторм запросов и скрытую потерю события
Наблюдаемость	По ID операции виден путь через все компоненты	Разбор инцидента «по памяти»
Сверка	Периодически сравниваются источники и получатели	Накопление тихих расхождений

Источники и границы. Возможности платформ сверены 2 октября 2026 года: Рекомендации API amoCRM · REST API Битрикс24. Конкретные методы, тарифы, редакции и требования публикации повторно проверяем перед проектом.

Надёжность

Проверяем отказ до того, как он станет инцидентом

Демонстрация успешной операции — только начало приёмки. Интеграция должна предсказуемо вести себя при повторе, задержке и недоступности.

Duplicate

Повтор события

Тот же ID не создаёт вторую сделку, заказ, документ или платёж.

Timeout

Нет ответа

Операция остаётся в контролируемом состоянии и повторяется по правилам.

Partial

Частичный результат

Виден выполненный шаг, точка отказа и безопасное продолжение процесса.

Recovery

Восстановление

После сбоя можно сверить период и повторить только пропущенные операции.

Порядок работы

От контрольного примера до сопровождения

Для локальной задачи этапы компактные. Для критичной интеграции каждый этап имеет отдельный результат и принимающего сотрудника.

Обследование

Текущий процесс, системы, данные, ограничения и цена ошибки.

Проектирование

Вариант решения, карта данных, события, права и критерии приёмки.

Разработка

Контуры, код, конфигурация, журнал и тестовые данные.

Пилот

Обычный путь, исключения, роли, нагрузка и соседние процессы.

Эксплуатация

Передача, мониторинг, поддержка, обновления и план развития.

Форматы работы

Сначала регулярная ответственность, затем проект и разовые задачи

Интеграции живут вместе с процессом и API платформ. Поэтому приоритетный формат после запуска — сопровождение, а не ожидание следующего аварийного обращения.

Ежемесячное сопровождение

Для работающих интеграций, где важны контроль, контекст и плановое развитие.

от 30 000 ₽ / мес

мониторинг и разбор инцидентов
плановые проверки и сверка
небольшие изменения в согласованном объёме
отчёт и следующий приоритет

Обсудить сопровождение

Проектная разработка

Для подтверждённого типового запроса или нового интеграционного продукта с приёмкой.

оценка после обследования

требования и архитектура
итерации и демонстрации
тестирование отказов
передача кода и документации

Оценить проект

Пакет часов

Дополнительный формат для ограниченного списка разовых работ без новой архитектуры.

от 15 000 ₽

диагностика одного сбоя
локальный webhook или поле
проверка готового модуля
небольшая правка документации

Проверить границы задачи

Короткие ответы

Вопросы до старта

Точная оценка появляется после проверки систем и одного реального сценария. Ниже — границы, которые полезно знать заранее.

Чем интеграционный сервис отличается от коннектора?

Коннектор обычно закрывает заранее определённую связку. Сервис обмена хранит состояние, реализует правила нескольких систем, наблюдаемость и восстановление; его можно развивать как отдельный продукт.

Нужна ли очередь для небольшого проекта?

Не всегда. Но даже без отдельного брокера нужны понятные состояния операции, безопасный повтор и журнал. Архитектуру выбираем по нагрузке и цене отказа.

Можно развернуть сервис на нашем сервере?

Да. До старта согласуем окружение, доступы, CI/CD, резервное копирование, мониторинг и ответственность за обновления ОС и зависимостей.

Поддерживаете существующий middleware?

Да, после технической приёмки: схема, исходники, инфраструктура, секреты, логи, тесты, лицензии зависимостей и процедура восстановления.

Связанные направления

Выберите компонент, который соответствует задаче

Страницы кластера разделены по поисковому и проектному намерению, но в реальной архитектуре компоненты часто работают вместе.

Следующий шаг

Покажите одну операцию, которая сейчас выполняется вручную или теряется

Разберём путь данных, проверим готовые решения и предложим минимальный устойчивый вариант. Для оценки полезны пример сущности, используемые системы, частота операций и ожидаемый результат.

Не просим готовое техническое задание для первого разговора
Отдельно обозначаем неизвестные и внешние зависимости
Не продаём разработку, если задача решается надёжнее без неё

Описать задачу

Проект с проверяемой приёмкойСпроектируем «Интеграционный сервис между CRM и остальным ИТ-контуром» с тестами и передачей результата

Зафиксируем операцию, данные, ошибки и критерии готовности до оценки разработки. Реализацию оформим проектом, а мониторинг и развитие — ежемесячным сопровождением.

Отправка формы ни к чему не обязывает. Сначала уточним границы задачи.