Выгрузка товаров на Wildberries из Битрикс

Выгрузка товаров из 1С-Битрикс на Wildberries — это не разовый экспорт файла, а постоянно работающий обмен: карточки создаются через Content API, характеристики берутся из свойств инфоблока, а цены и остатки поддерживаются в актуальном состоянии по расписанию. Разберём, как выстроить этот процесс технически грамотно.

Как устроен обмен: какие API участвуют

Wildberries не принимает единый «фид» как Яндекс Маркет. Работа с ассортиментом разбита на несколько независимых API, и выгрузка из Битрикс должна обращаться к каждому по своему сценарию:

• Content API (content-api.wildberries.ru) — создание и редактирование карточек, номенклатуры, характеристик, медиа;
• Prices & Discounts API (discounts-prices-api.wildberries.ru) — цены и скидки по nmID;
• Marketplace API (marketplace-api.wildberries.ru) — остатки на складах продавца по схеме FBS;
• Statistics API — контроль остатков FBO и сверка.

Авторизация везде одинаковая — токен в заголовке Authorization. Токен генерируется в личном кабинете поставщика по категориям: для этой задачи нужны минимум «Контент» и «Цены и скидки». Хранить его в коде нельзя — только в защищённых настройках модуля или в .settings.php.

Подготовка каталога в Битрикс

До первой выгрузки каталог в Битрикс нужно привести к структуре, которую поймёт WB. Ключевая сущность на стороне маркетплейса — предмет (категория), у каждого предмета свой набор обязательных характеристик. Поэтому в инфоблоке каталога заранее заводят:

• свойство WB_SUBJECT_ID — идентификатор предмета WB для элемента или раздела;
• штрихкод (баркод) товарного предложения — часто это свойство торгового предложения BARCODE;
• артикул продавца (vendorCode) — обычно это XML_ID или артикул из 1С;
• бренд, цвет, размер, состав — как свойства или привязки к справочникам (Highload-блокам).

Если сайт наполняется из 1С, эти поля логично формировать на стороне учётной системы и передавать в Битрикс через CommerceML, чтобы маркетплейс и сайт торговали одними и теми же данными. Торговые предложения (SKU) в Битрикс соответствуют размерам/цветам в карточке WB — это соответствие нужно продумать до выгрузки.

Создание карточек через Content API

Карточка на WB — это imt (объединяющая сущность бренда/модели), внутри которой находятся номенклатуры (nmID) с размерами. Создание идёт методом POST /content/v2/cards/upload: в теле передаётся массив вариантов с предметом, брендом, характеристиками, размерами и баркодами.

Из Битрикс запрос удобно собирать в D7-обработчике, а отправлять через штатный Bitrix\Main\Web\HttpClient:

$http = new \Bitrix\Main\Web\HttpClient(); $http->setHeader('Authorization', $token); $http->setHeader('Content-Type', 'application/json'); $res = $http->post('https://content-api.wildberries.ru/content/v2/cards/upload', \Bitrix\Main\Web\Json::encode($cards));

Ответ приходит асинхронно: WB принимает задание и обрабатывает его в фоне. Реальный статус карточки и присвоенный nmID нужно получать отдельным методом POST /content/v2/get/cards/list с фильтром по vendorCode. Именно на этом шаге собирают ошибки модерации: незаполненные обязательные характеристики, недопустимый предмет, дубли баркодов.

Полученный nmID обязательно сохраняют обратно в свойство товара в Битрикс — это ключ для всех последующих операций (цены, остатки, заказы).

Маппинг характеристик и справочников

Самая трудоёмкая часть — сопоставление свойств Битрикс с характеристиками предмета WB. Их состав WB отдаёт справочниками, которые надо кэшировать локально:

Маппинг оформляют как таблицу соответствий «свойство инфоблока → характеристика WB», чтобы контент-менеджер мог править её без разработчика. Для значений-справочников (цвет, страна) нужно приводить строку из Битрикс к точному значению из справочника WB — иначе карточка не пройдёт валидацию.

• единицы измерения и обязательность характеристик проверяйте по ответу charcs;
• значения, которых нет в справочнике WB, помечайте как ошибку заранее, а не после отклонения;
• размерную сетку ведите в торговых предложениях, а не в тексте.

Цены, скидки и остатки

После создания карточек цены и остатки живут своей жизнью и обновляются чаще всего. Цена задаётся методом POST /api/v2/upload/task Prices API — передаётся nmID, цена и скидка. WB работает с ценой до скидки продавца, поэтому в Битрикс держите базовую цену и процент скидки отдельно, чтобы не пересчитывать в уме.

Остатки для FBS отправляются в Marketplace API методом PUT /api/v3/stocks/{warehouseId} по баркодам. Здесь важен идентификатор склада продавца — его получают методом GET /api/v3/warehouses и сохраняют в настройках.

• цены выгружайте по изменению (сравнивая с последним отправленным значением), а не весь каталог целиком;
• остатки — по расписанию раз в 5–15 минут, чтобы не продать то, чего нет;
• ведите лог: что, когда и с каким ответом ушло — это спасает при разборе спорных заказов.

Автоматизация и расписание в Битрикс

Ручной запуск выгрузки не масштабируется. Обмен оформляют как набор агентов или задач на cron, каждый со своей периодичностью:

1. агент создания/обновления карточек — по событию изменения товара или раз в час;
2. агент цен — каждые 15–30 минут по изменённым позициям;
3. агент остатков — каждые 5–15 минут;
4. агент сверки статусов карточек — раз в час, ловит ошибки модерации.

Агенты Битрикс лучше запускать не на хитах, а через cron (константа define('BX_CRON', true) и вызов /bitrix/modules/main/tools/cron_events.php), иначе длительные HTTP-запросы к WB будут тормозить посетителей сайта. Логику обмена выносят в отдельный модуль с настройками токенов, маппинга и логом — это удобнее правки в init.php.

Типичные ошибки и как их ловить

На боевой выгрузке чаще всего встречаются одни и те же проблемы. Их проще предупредить валидацией на стороне Битрикс, чем разбирать отклонения:

Отдельная головная боль — рассинхрон, когда товар в Битрикс изменили, а на WB не доехало. Помогает поле «дата последней успешной выгрузки» на товаре и отчёт по расхождениям, который можно вывести в админке.

Итог

Выгрузка товаров из Битрикс на Wildberries — это связка из нескольких API (Content, Prices, Marketplace, Statistics), корректного маппинга характеристик и дисциплины по расписанию и лимитам. Ключевые опоры: уникальные баркоды, сохранённые nmID, раздельные потоки для карточек, цен и остатков, а также идемпотентность при повторных запусках.

Мы в B2Bsite проектируем такой обмен как отдельный модуль на 1С-Битрикс: с настройками токенов, гибким маппингом свойств, очередью, логом и мониторингом ошибок. Если каталог наполняется из 1С, подключаем маркетплейс к тому же источнику данных, чтобы сайт и WB торговали одним ассортиментом без ручной работы.