Системы не разговаривают друг с другом? Свяжем их через надёжный обмен данными
Если данные приходится переносить руками между сайтом, 1С, маркетплейсами, CRM и таблицами, обмены периодически «отваливаются», а где произошла ошибка — непонятно, нужна не очередная выгрузка, а устойчивый интеграционный слой.
Я разрабатываю интеграции и API-шлюзы со стороны современного бэкенда: очереди, фоновые обмены, повторные попытки, журналы ошибок и понятную картину того, какая система является источником правды.
В первом сообщении достаточно описать, какие системы нужно связать, где сейчас данные расходятся и как часто нужен обмен.
Как устроена честная совместная работа
Сразу важная оговорка, чтобы не было ложных ожиданий. Это нормальное и частое разделение: каждый отвечает за свою сторону обмена.
Моя зона — бэкенд интеграции
Обмен на Laravel / Go / Node, работа с внешними API, очередями и форматами данных.
Зона 1С-специалиста
На стороне клиента — настройка и доработка самой 1С.
Ваш 1С-специалист отвечает за то, что 1С корректно отдаёт и принимает данные; я отвечаю за то, что эти данные надёжно ходят между системами, не теряются и обрабатываются правильно.
Если 1С-специалиста у вас нет — это нужно решить до старта: либо подключить его, либо ограничить интеграцию форматами, которые 1С уже умеет отдавать (например, регламентные выгрузки файлов).
Когда нужна кастомная интеграция
Интеграция нужна не «чтобы было», а когда ручной перенос данных и нестабильные обмены начинают стоить денег и времени. Типичные ситуации:
Если данные нужно копировать между системами регулярно и одинаково — этот обмен можно и нужно автоматизировать. Если данные в источнике неверны, интеграция не «починит бизнес», а покажет проблему быстрее.
Интеграционный слой, устойчивость обмена и контроль
Три уровня работы: как системы соединяются, как обмен переживает сбои и как вы видите, что происходит.
Интеграционный слой и API-шлюзы
Устойчивость обмена
Видимость и контроль
Типовые направления обмена
Чаще всего связывают именно эти контуры. Направление обмена в каждом случае проектируется отдельно.
Пример схемы обмена на тестовых данных
Реальные интеграции содержат токены, ключи API и данные клиентов, поэтому я не публикую клиентские обмены. Вместо этого — демо: карта систем, журнал условных обменов и источник правды по каждому типу данных.
Журнал обменов
за сегодняИсточник правды
по типу данныхПо каждому типу данных одна система — источник правды. Остальные получают актуальную копию.
Единый клиент под все платформы
Если поверх интеграции нужен интерфейс — дашборд состояния обменов, рабочее место оператора, панель ошибок — его можно собрать на Flutter и получить один код под веб, десктоп и мобильные сразу.
Это удобно, когда панель нужна и в офисе на компьютере, и на складе на планшете.
один код под все платформы
Что вы получаете
Не «связали и забыли», а понятная и управляемая интеграция, которую видно и которой можно доверять.
Я не обещаю «связать что угодно с чем угодно мгновенно». У некоторых систем API ограничен или отсутствует — тогда честно проговариваем, что возможно, а что нет.
Безопасный вход в проект
Разбор систем и данных
Что нужно связать, какие данные ходят, как часто, кто источник правды.
Проверка API
Есть ли у систем нормальный API, какие лимиты и ограничения.
Карта обмена
Схема: что, куда, в какую сторону, что делать при ошибке.
Разработка
Интеграционный слой, очереди, обработка ошибок, журнал.
Тестирование на тестовых данных
Без работы с боевыми токенами в первых итерациях.
Запуск и сопровождение
Мониторинг, реакция на изменения API, доработки.
Бюджетные ориентиры
Не жёсткий прайс, а порядок бюджета до обращения. Формат зависит от количества систем и требований к надёжности обмена.
Финальная оценка зависит от количества систем, доступности их API, объёма данных и требований к надёжности обмена.
FAQ
Вы настраиваете 1С? +
Нет. Я делаю интеграцию со стороны бэкенда и внешних API. За конфигурацию и обмен внутри 1С отвечает ваш 1С-специалист. Если его нет, это нужно решить до старта.
Можно ли обойтись без API, через файлы? +
Иногда да. Если у системы нет API, обмен можно строить на регламентных выгрузках файлов. Это проще, но менее оперативно. Выбор зависит от задачи.
Что будет, если внешний API изменится? +
API маркетплейсов и сервисов меняются. Поэтому важны журнал, мониторинг и сопровождение: при изменении API обмен дорабатывается. Это нормальная часть жизни интеграции, а не «поломка навсегда».
Можно ли связать систему с маркетплейсами? +
Да, со стороны API маркетплейсов. Если задача про операции селлера целиком (склад, сборка, сверки), посмотрите направление SellerOps — это про операционный контур, а не только обмен.
Свяжите системы через надёжный обмен, а не ручной перенос
Опишите, какие системы нужно связать, где сейчас данные расходятся, есть ли у систем API и есть ли 1С-специалист на вашей стороне. Я предложу первый шаг — разбор задачи и карту обмена.
Не присылайте токены, API-ключи и доступы в первом сообщении.