API 1С: что это и как использовать для интеграции

API 1С — это набор программных интерфейсов, через которые другие системы обмениваются данными с базой 1С: создают документы, читают справочники, получают остатки и цены. Без API сайт не узнает актуальные остатки склада, а CRM — выставленные счета. Интеграция через API заменяет ручной перенос данных и файловый обмен, который ломается при изменении структуры каталогов.

В платформе 1С:Предприятие нет единого «API» в привычном понимании REST-разработчиков. Вместо этого есть несколько механизмов: автоматический интерфейс OData, HTTP-сервисы, веб-сервисы (SOAP), механизм XDTO-пакетов и EnterpriseData для обмена между конфигурациями. Выбор зависит от задачи: одно дело — отдать каталог товаров на сайт, другое — принимать заказы от мобильного приложения.

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

Что скрывается за термином «API 1С»

Когда говорят «API 1С», обычно имеют в виду один из четырёх вариантов. Первый — автоматический REST-интерфейс OData, который платформа генерирует сама на основе структуры конфигурации. Второй — HTTP-сервисы, которые разработчик создаёт в конфигураторе и описывает произвольную логику. Третий — веб-сервисы SOAP, исторически первый механизм интеграции. Четвёртый — внешние API самих сервисов 1С, например «1С:ДиректБанк» или облачные сервисы фирмы «1С».

Принципиальное отличие платформы 1С от типичных веб-приложений: доступ идёт не к таблицам базы данных, а к объектам конфигурации — документам, справочникам, регистрам. Это значит, что при чтении и записи отрабатывают права доступа, подписки на события и часть прикладной логики, что защищает целостность данных, но влияет на производительность.

Какие интерфейсы интеграции есть в платформе

У каждого механизма своя область применения. OData подходит для чтения данных и простых операций записи без дополнительной разработки. HTTP-сервисы — для произвольной логики: приём заказов, вебхуки, интеграция с мобильными приложениями. SOAP-веб-сервисы чаще встречаются в унаследованных проектах и интеграциях с корпоративными шинами. Планы обмена и EnterpriseData используют для регулярной синхронизации между базами 1С и совместимыми системами.

Как включить и опубликовать OData

Автоматический REST-интерфейс включается при публикации базы на веб-сервере (IIS или Apache). В диалоге публикации есть отдельный флажок «Публиковать доступ для клиентских приложений» и настройка OData. После публикации данные становятся доступны по адресу вида http://сервер/база/odata/standard.odata/Catalog_Номенклатура. Состав публикуемых объектов можно ограничить: в конфигураторе у каждого объекта есть свойство доступности через OData.

Аутентификация выполняется средствами веб-сервера и платформы: чаще всего используют базовую аутентификацию с пользователем информационной базы. Права этого пользователя определяют, какие объекты видны через API. Создавать для интеграции отдельного пользователя с минимально необходимыми правами — обязательная практика, а не рекомендация.

Проверить работу можно прямо из браузера: откройте URL сервиса, введите учётные данные и убедитесь, что возвращается XML со списком сущностей. Затем запросите конкретный справочник с параметром $format=json, чтобы получить данные в удобном для разработки виде.

1. 1
   Опубликуйте базу на веб-сервере через конфигуратор: Администрирование → Публикация на веб-сервере
2. 2
   Отметьте публикацию OData и при необходимости ограничьте состав объектов
3. 3
   Создайте отдельного пользователя с правами только на нужные объекты
4. 4
   Проверьте доступ: откройте URL standard.odata в браузере и выполните тестовый запрос
5. 5
   Документируйте адрес сервиса и учётную запись для команды интеграции

Когда OData недостаточно: собственные HTTP-сервисы

Автоматический интерфейс записывает объекты «как есть» и не умеет выполнять произвольные проверки: например, отклонить заказ с несуществующим договором или рассчитать скидку по сложным правилам. Для таких сценариев в конфигураторе создают объект «HTTP-сервис», описывают шаблоны URL и пишут обработчики на встроенном языке. Внутри обработчика доступна вся прикладная логика конфигурации.

Типовой сценарий — приём заказов с сайта. Внешняя система отправляет JSON на адрес вида /hs/orders/create, обработчик проверяет контрагента и товары, создаёт документ «Заказ покупателя» и возвращает его номер. Такой подход даёт контроль над форматом, ошибками и транзакционностью, но требует поддержки кода при обновлении конфигурации.

POST /base/hs/orders/create HTTP/1.1
Authorization: Basic ...
Content-Type: application/json

{"contragent": "ИНН7701234567", "items": [{"sku": "ТР-1042", "qty": 5}]}

Безопасность и права доступа

Открытый наружу API — это точка входа в учётную систему, поэтому требования здесь жёстче, чем к обычному пользовательскому доступу. Публикация должна работать только по HTTPS: базовая аутентификация передаёт логин и пароль в закодированном, но легко раскрываемом виде, и по открытому HTTP их перехватит любой, кто видит трафик. Перед выводом сервиса в интернет настройте TLS-сертификат и ограничьте доступ по IP там, где это возможно.

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

Производительность и нагрузка на базу

Каждый запрос к OData или HTTP-сервису выполняется в сеансе 1С и потребляет ресурсы сервера. Тяжёлые выборки — например, чтение всех документов за год без фильтра — способны заметно замедлить работу пользователей. Правильная практика: всегда использовать фильтры ($filter в OData), постраничную выборку ($top, $skip) и запрашивать только нужные поля через $select.

Для массовых выгрузок лучше работает другой паттерн: 1С сама периодически отправляет изменения во внешнюю систему или выгружает их в промежуточный формат, а внешняя система забирает готовые данные. Это снижает число обращений к базе и делает нагрузку предсказуемой. Регламентные задания для такой выгрузки настраивают на часы минимальной активности пользователей.

Проверка результата и типичные ошибки

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

Как выбрать подход под свою задачу

Критерий выбора простой: чем больше прикладной логики нужно выполнить в момент обмена, тем ближе решение к собственному HTTP-сервису. Если задача — «отдать наружу справочники и остатки», начните с OData: это самый быстрый путь. Если нужно принимать и проверять данные — проектируйте HTTP-сервис с явной валидацией. Для обмена между двумя базами 1С сначала смотрите на типовые планы обмена и формат EnterpriseData, прежде чем писать своё.

Частые вопросы об API 1С