InSales + CRM/склад

InSales — зрелая SaaS-платформа с REST API и штатным обменом с 1С по CommerceML. Это упрощает связку с учётной системой и CRM, но у облачной модели есть нюансы: доступ только через API, лимиты запросов и зависимость от расписания обмена. Разберём, как выстроить надёжный обмен и когда пора переезжать на 1С-Битрикс.

Что даёт InSales для интеграции

InSales — облачная (SaaS) e-commerce-платформа. В отличие от коробочных CMS, доступа к файлам и базе данных у вас нет — вся работа идёт через REST API и вебхуки. Зато InSales изначально ориентирован на связку с 1С: в нём есть штатный обмен по протоколу CommerceML 2, тот же, что использует 1С-Битрикс.

Что реально нужно интегрировать:

• Каталог — товары, цены, остатки, свойства из 1С;
• Заказы — из InSales в CRM и 1С;
• Статусы — оплата, отгрузка, трек-номер обратно;
• Клиенты и контрагенты — дедупликация и B2B-цены.

REST API и вебхуки

API InSales построено по REST-принципам. Ресурсы доступны по адресам вида /admin/products.json, /admin/orders.json, /admin/collections.json. Авторизация — HTTP Basic парой «идентификатор ключа + пароль», выданной в разделе приложений:

GET https://KEY:PASSWORD@shop.myinsales.ru/admin/orders.json

Основные операции CRUD доступны стандартными методами GET/POST/PUT/DELETE. Для событий (новый заказ, смена статуса) настраиваются вебхуки — InSales шлёт POST на ваш URL, что избавляет от постоянного опроса API.

Обмен каталогом по CommerceML

Каталог, цены и остатки удобнее гонять не через REST, а штатным обменом CommerceML. Схема стандартная для связки «1С ↔ интернет-магазин»:

1. 1С (УТ/УНФ) выгружает import.xml с номенклатурой и offers.xml с ценами и остатками;
2. InSales принимает пакет и раскладывает по товарам и вариантам;
3. заказы забираются обратно в 1С этим же протоколом.

Ключ сопоставления — внешний код товара из 1С. Он должен быть стабильным: если в 1С меняют артикул или пересоздают номенклатуру, в InSales появляются дубли. Для B2B полезно, что CommerceML передаёт несколько типов цен — их можно раскладывать по группам клиентов.

Синхронизация заказов и статусов

Заказ в InSales живёт как объект order с позициями, покупателем, доставкой и оплатой. Для сквозного процесса нужны оба направления:

Если основная CRM — не встроенная в InSales, а Битрикс24, amoCRM или retailCRM, заказы заводятся через её API. Тогда прослойка держит соответствие статусов между тремя системами и следит, чтобы смена статуса в одной корректно отражалась в остальных.

Надёжность обмена

SaaS-специфика InSales диктует требования к обмену:

• Идемпотентность — по номеру заказа InSales, чтобы вебхук-повтор не создавал дубль;
• Очередь — заказы буферизуются, если 1С или CRM недоступны;
• Учёт лимитов — троттлинг запросов к API, постраничная выгрузка;
• Журнал и алерты — фиксировать каждый пакет CommerceML и каждый вебхук;
• Сверка — периодическое сравнение остатков и цен InSales ↔ 1С.

Миграция с InSales на 1С-Битрикс

InSales удобен на старте, но упирается в потолок: ограниченная кастомизация, тарифные лимиты, невозможность глубоко доработать B2B-логику и разместить решение на своих серверах. Тогда переходят на коробочный 1С-Битрикс.

Плюс миграции в том, что данные уже структурированы:

• Каталог — выгружается из 1С в Битрикс тем же CommerceML;
• Товары/варианты — доступны через REST API InSales для сверки;
• Заказы и клиенты — экспортируются через API постранично;
• URL — карта 301-редиректов со старых адресов InSales.

Итог

InSales выгодно отличается штатным CommerceML: обмен каталогом с 1С настраивается почти как в Битриксе, а REST API и вебхуки закрывают заказы и интеграцию со сторонней CRM. Главное — держать стабильный внешний код товара, соблюдать лимиты API и вести журнал обмена, потому что в облаке других логов у вас нет.

Мы настраиваем связки InSales с 1С и CRM, а когда платформа становится тесной — переносим магазин на 1С-Битрикс с сохранением каталога, заказов и SEO. Если вы упёрлись в лимиты InSales или хотите двусторонний обмен со складом — поможем спроектировать и запустить обмен.