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