Зачем интегрировать 1С и какие есть подходы
Как правило, 1С не живёт в компании изолированно. Рядом работают сайт с личным кабинетом, CRM, банк-клиент, складская система, маркетплейсы и сервисы автоматизации. Чтобы данные не переносили руками, 1С нужно связать с этими системами: подтягивать заказы с сайта, отдавать остатки, выгружать документы, принимать платежи.
Хорошая новость в том, что платформа 1С:Предприятие поддерживает интеграцию из коробки и через ручную разработку сразу несколькими способами. Плохая — способов много, и выбор неочевиден. Ошибка на старте оборачивается лишней работой: например, команда пишет сложный веб-сервис там, где хватило бы встроенного REST, или закладывается на COM-соединение, а через год сервер переезжает на Linux, где COM просто нет.
Мы выделяем пять основных подходов:
- OData — встроенный автоматический REST-интерфейс, почти без программирования;
- HTTP-сервисы — ручная разработка REST-подобных ресурсов под конкретную задачу;
- Web-сервисы (SOAP) — строгий контракт для надёжного межсистемного обмена;
- COM и внешние соединения — самый быстрый локальный способ, только на Windows;
- Обмен данными — планы обмена, формат EnterpriseData и 1С:Шина для синхронизации баз между собой.
Ниже разбираем каждый подход: что он умеет, когда его брать и какие есть ограничения. Отдельно отметим, что важно при работе с облачной 1С и при переходе на импортозамещённые Linux-серверы.
OData: автоматический REST-интерфейс
OData — это самый быстрый способ получить у 1С полноценный API без написания кода на стороне 1С. Начиная с платформы 1С:Предприятие 8.3.5, у системы есть встроенный автоматический REST-интерфейс на протоколе OData версии 3.0. Он умеет отдавать данные в формате Atom/XML или JSON и поддерживает полный набор операций CRUD: чтение через GET, создание через POST, обновление через PUT и PATCH, удаление через DELETE.
Через OData доступны прикладные объекты конфигурации: справочники, документы, регистры и другие. Обращения идут по единому адресу вида .../odata/standard.odata. Это удобно, когда внешней системе нужно читать и писать данные напрямую, а типовую бизнес-логику 1С менять не требуется.
Как это включается
Чтобы OData заработал, интерфейс нужно опубликовать. Публикация выполняется через Конфигуратор, пункт «Публикация на веб-сервере», и требует установленного веб-сервера — как правило, IIS на Windows или Apache. Здесь есть важный нюанс, о который спотыкаются на старте: из коробки состав публикуемых объектов пустой. Даже после публикации базы вы не получите доступ ни к одному справочнику, пока явно не укажете, что именно разрешено отдавать через OData. Это, кстати, и механизм безопасности: наружу попадает только то, что вы осознанно открыли.
Частая ошибка: администратор публикует базу, дёргает адрес OData и получает пустой список. Причина почти всегда одна — не отмечены объекты состава публикации. Сначала выбираем нужные справочники и документы, потом проверяем API.
Про тонкости фильтрации, постраничного вывода и формата ответов у нас есть отдельный разбор — практический гид по OData REST в 1С. Если внешней системе достаточно стандартных операций с данными, OData почти всегда — правильная точка входа.
HTTP-сервисы и web-сервисы (SOAP): в чём разница
Когда встроенного OData не хватает — например, нужна своя логика, нестандартный формат ответа или отдельная точка входа под конкретного потребителя — в 1С есть два инструмента ручной разработки: HTTP-сервисы и web-сервисы. Их часто путают, хотя предназначены они для разного.
HTTP-сервисы
HTTP-сервисы разрабатываются вручную и ориентированы на ресурсы: вы сами описываете, какой URL что возвращает, и отдаёте данные в JSON или XML. Это гибкий и лёгкий инструмент, близкий по духу к обычному REST API. Он хорошо подходит для интеграции с сайтами, личными кабинетами и мобильными приложениями, а также для асинхронных сценариев, где важна скорость и простота обмена. Если вам нужен аккуратный API под свою задачу и вы готовы описать его сами — это HTTP-сервисы.
Web-сервисы (SOAP)
Web-сервисы работают по протоколу SOAP и описываются контрактом WSDL. В отличие от HTTP-сервисов, они ориентированы не на ресурсы, а на действия: строгий формализованный контракт, предсказуемая структура запросов и ответов, поддержка транзакционности. Это делает их удачным выбором для надёжного межсистемного B2B-обмена, где на другой стороне корпоративная система, которой нужен жёсткий, машиночитаемый договор об интерфейсе.
Коротко разницу можно сформулировать так:
- HTTP-сервис — про ресурсы, гибкость, JSON, интеграции с веб и мобильными;
- Web-сервис (SOAP) — про действия, строгий контракт и транзакции, надёжный обмен между корпоративными системами.
Оба инструмента, как и OData, публикуются на веб-сервере и требуют разработки на стороне конфигурации 1С. Разница в том, что OData вы почти не программируете, а HTTP- и web-сервисы пишете под задачу.
А это может работать само в вашем бизнесе?
Запишитесь на бесплатный разбор процесса (30 минут). Разберём один сценарий и честно скажем, окупается ли автоматизация.
Получить бесплатный аудитCOM и внешние соединения (и почему на Linux их нет)
COM-соединение (внешнее соединение через объект V83.COMConnector) — это, как правило, самый быстрый способ локальной интеграции с 1С. Внешняя программа подключается к базе напрямую как к COM-объекту и вызывает её методы почти без сетевых накладок. Такой подход исторически используют для интеграции с другими приложениями на том же сервере, для служебных обработок и обмена внутри одного контура.
У COM есть одно принципиальное ограничение: он работает только на Windows. Технология COM/OLE — часть экосистемы Windows, и на Linux её просто нет. На Linux-серверах доступны другие механизмы: HTTP-сервисы и OData, то есть обмен через веб-сервер, а не через прямое соединение объекта.
Это ограничение перестало быть теоретическим. При переходе на импортозамещённые Linux-серверы (что сейчас, по состоянию на 2026 год, распространённый сценарий) любая интеграция, завязанная на COM, ломается и требует переделки. Поэтому мы стараемся не закладывать COM в новые проекты, если есть хоть какая-то вероятность, что база переедет на Linux.
Практический вывод: COM хорош для локального обмена на Windows-сервере, но это архитектурный тупик, если впереди возможный переезд на Linux. Там основными интерфейсами становятся HTTP-сервисы и OData.
Если вы строите интеграцию с прицелом на годы вперёд, разумнее сразу опираться на веб-интерфейсы. Они кроссплатформенны и переживут смену серверной ОС без переписывания логики обмена.
Обмен данными: EnterpriseData и 1С:Шина
Отдельная большая тема — синхронизация данных между базами 1С и с внешними системами через механизм обмена данными. Здесь речь не про запрос-ответ в реальном времени, а про регулярную передачу изменений: справочников, документов, остатков.
Планы обмена и EnterpriseData
В основе лежат планы обмена — они определяют, между какими узлами и какими данными идёт синхронизация. Универсальный формат для этого — EnterpriseData: это XML-формат, который позволяет разным конфигурациям 1С понимать друг друга без жёсткой привязки к внутренней структуре каждой из них. Работает он инкрементально: первая синхронизация передаёт все объекты, а дальше уходят только изменения. Это экономит трафик и время и делает регулярный обмен предсказуемым.
1С:Шина
Когда систем становится много и обмен «каждый с каждым» превращается в клубок связей, применяют 1С:Шину — сервисную шину (ESB) для интеграционного ландшафта из многих систем. Вместо десятков попарных обменов системы подключаются к шине, а она берёт на себя маршрутизацию сообщений. Для сложных ландшафтов это заметно упрощает поддержку.
Не стоит забывать и про классику: 1С по-прежнему умеет обмениваться через простые форматы файлов — XML, CSV, DBF. Для несложных выгрузок и загрузок, особенно с внешними системами, которые не умеют ничего сложнее файла, этого часто достаточно.
Для сценариев автоматизации, где 1С нужно связать с сервисами вроде n8n или Make, мы обычно комбинируем эти механизмы: OData или HTTP-сервис для оперативных операций и обмен данными — для фоновой синхронизации больших объёмов.
Как выбрать способ: шпаргалка и ограничения облака
Соберём всё в короткую шпаргалку. Выбор способа зависит от задачи, платформы и того, где размещена база.
- Нужен быстрый API к данным, без своей логики — OData. Минимум разработки, полный CRUD.
- Нужен свой REST-подобный API под сайт, кабинет или мобильное приложение — HTTP-сервисы.
- Нужен надёжный B2B-обмен со строгим контрактом и транзакциями — web-сервисы (SOAP).
- Локальная интеграция на Windows-сервере, важна скорость — COM (но помните про Linux).
- Регулярная синхронизация баз и больших объёмов — обмен данными через EnterpriseData, для сложных ландшафтов — 1С:Шина.
Ограничения облачной 1С:Фреш
Отдельно про облако. В 1С:Фреш OData поддерживается — доступны и чтение, и запись, так что построить интеграцию через встроенный REST можно. Но есть важные ограничения, о которых стоит знать заранее:
- не поддерживается заголовок 1C_OData-DataLoadMode: true — то есть режим загрузки в обход проведения документов в облаке недоступен, и данные проходят штатную бизнес-логику;
- в чистом облаке недоступны COM и внешние компоненты — по той же причине, по которой COM недоступен на Linux: у вас нет доступа к серверу как к машине.
Практически это значит: для облачной 1С основным интеграционным интерфейсом становится OData (и, где предусмотрено конфигурацией, веб-сервисы), а любые сценарии, завязанные на прямой доступ к серверу, отпадают.
Отдельно стоит присмотреться к новому подходу — подключению 1С к ИИ-агентам и внешним инструментам через MCP-сервер. Про это у нас есть разбор: MCP-сервер для 1С. Он не заменяет описанные способы, а надстраивается над ними, давая единую точку входа для автоматизации.