Самописный сайт даёт полную свободу, но лишён готового обмена с 1С. Всю интеграцию — каталог, цены, остатки, заказы — приходится проектировать с нуля через API. Разберём, как выстроить надёжный обмен с учётной системой, какие форматы выбрать и что учесть, если в перспективе переезд на 1С-Битрикс.
С чего начинается интеграция самописа
У коробочных CMS есть готовые механизмы обмена с 1С. У самописного сайта их нет — есть только ваш код и БД. Это одновременно свобода и ответственность: вы сами определяете контракт обмена, форматы и правила согласования данных.
Перед разработкой фиксируют четыре вещи:
- Направления — что и куда течёт (каталог из 1С, заказы в 1С);
- Ключи — по какому полю сопоставляются товары и заказы;
- Транспорт — REST API, CommerceML или комбинация;
- Гарантии — идемпотентность, повторы, журналирование.
Выбор транспорта: REST или CommerceML
Два рабочих варианта связи самописа с 1С:
| Критерий | REST API (свой) | CommerceML |
|---|---|---|
| Каталог из 1С | Гибко, свой формат JSON | Стандарт, готовые выгрузки 1С |
| Заказы в 1С | POST по своему контракту | Штатный протокол 1С |
| Порог входа | Пишем обе стороны | Сторона 1С почти готова |
| Совместимость с Битрикс | Своя | Родная для Битрикса |
Если 1С уже умеет выгружать по CommerceML, часто дешевле принять этот протокол на самописе, чем изобретать свой формат. Если же нужна тонкая логика (частичные обновления, события, интеграция с несколькими системами), делают собственное REST API с продуманным контрактом.
Синхронизация каталога, цен и остатков
Каталог всегда течёт из первоисточника — 1С — на сайт. Правильная организация:
- 1С отдаёт номенклатуру с внешними кодами, свойствами, категориями;
- цены передаются по типам (розница, опт, дилер) с привязкой к группам;
- остатки — по складам, приводятся к нужной сайту модели наличия;
- первичная загрузка полная, дальше — инкрементальная (только изменения).
Пример минимального контракта на приём остатков:
POST /api/v1/stock { external_id, warehouse, qty, updated_at }
external_id из 1С. Привязка по названию или внутреннему ID сайта рано или поздно даст дубли и потерю остатков. Договоритесь о ключе до первой строки кода.Передача заказов и идемпотентность
Заказ с самописа уходит в 1С и CRM. Ключевое требование — идемпотентность: повтор запроса не должен создавать второй документ.
- каждому заказу присваивается стабильный
idempotency_key; - 1С/прослойка проверяет ключ и при повторе возвращает уже созданный заказ;
- заказы буферизуются в очередь, если 1С недоступна;
- при сбое включаются ретраи с экспоненциальной задержкой;
- обратно возвращаются статусы оплаты, отгрузки и трек-номер.
Без идемпотентности и очереди самопис — главный поставщик дублей и «потерянных» заказов, потому что здесь нет готовых защит, как в коробке. Эти гарантии закладывают в контракт сразу.
Безопасность и надёжность обмена
Собственное API открывает доступ к каталогу, ценам и заказам, поэтому его защищают наравне с боевой системой:
- Аутентификация — токены/ключи, ротация, HTTPS обязательно;
- Права — минимально необходимые (отдельный ключ на чтение каталога и на приём заказов);
- Валидация — строгая проверка входящих данных и версий контракта;
- Журнал — сырые запросы и ответы для расследований;
- Мониторинг — алерты на ошибки и расхождения при сверке.
/api/v1/). Учётная система и сайт эволюционируют независимо, и без версий любое изменение контракта рискует одномоментно сломать обмен.Переход на 1С-Битрикс
Нередко самопис перерастает себя: растёт стоимость поддержки, не хватает готовых модулей оплаты, доставки, маркетплейсов, а каждую интеграцию приходится писать вручную. Тогда рассматривают переход на 1С-Битрикс, где обмен с 1С и множество интеграций уже есть.
Преимущество продуманного API-обмена в том, что данные уже структурированы:
- Каталог — из 1С в Битрикс по CommerceML, минуя самопис;
- Заказы и клиенты — выгружаются через ваше же API;
- Внешние коды — переносятся как ключи в инфоблоки Битрикса;
- URL — карта 301-редиректов со старой структуры сайта.
Если обмен изначально строился на стабильных external_id, миграция превращается в аккуратный перенос, а не в разбор legacy-хаоса.
Итог
Интеграция самописного сайта с 1С — это проектирование контракта обмена с нуля: выбор транспорта (REST или CommerceML), единый external_id, инкрементальная синхронизация каталога, идемпотентность и очередь для заказов, безопасность и версионирование API. Дисциплина здесь важнее инструментов — именно она отличает надёжный обмен от источника дублей.
Мы проектируем и разрабатываем API-обмен самописных сайтов с 1С и CRM, а когда поддержка самописа становится дороже готового решения — переносим проект на 1С-Битрикс с сохранением каталога, заказов и SEO. Если ваш сайт уникален, а обмен со складом нужно сделать надёжным — поможем спроектировать контракт и реализовать интеграцию.
Частые вопросы
Через что интегрировать самописный сайт с 1С?
Через API: либо принять на сайте стандартный протокол CommerceML, если 1С уже умеет по нему выгружать, либо спроектировать собственное REST API с чётким контрактом для каталога и заказов.
Что выбрать — свой REST или CommerceML?
Если 1С готова выгружать по CommerceML, часто дешевле принять этот протокол. Если нужна тонкая логика — частичные обновления, события, несколько систем — делают собственное REST API.
Что такое идемпотентность и зачем она нужна?
Это гарантия, что повтор запроса не создаст дубль. Каждому заказу присваивают ключ идемпотентности, и при повторной отправке система возвращает уже созданный заказ, а не новый.
По какому полю сопоставлять товары?
По стабильному external_id из 1С. Привязка по названию или внутреннему ID сайта со временем даёт дубли и потерю остатков. Ключ согласовывают до начала разработки.
Как защитить собственное API обмена?
Токенами и ключами с минимальными правами, обязательным HTTPS, строгой валидацией входа, журналированием сырых запросов и мониторингом ошибок и расхождений при сверке.
Зачем версионировать API?
Сайт и учётная система развиваются независимо. Версия в адресе, например /api/v1/, позволяет менять контракт без одномоментной поломки обмена на обеих сторонах.
Легко ли перенести самопис на 1С-Битрикс?
Если обмен строился на стабильных external_id, миграция управляема: каталог берётся из 1С по CommerceML, заказы и клиенты выгружаются через ваше API, старые URL закрываются 301-редиректами.
Поможем с настройкой и поддержкой Интеграции и связки систем
Поможем с настройкой, доработкой и поддержкой Интеграции и связки систем.