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

Wildberries не принимает готовый YML-фид, как Яндекс.Маркет: обмен идёт только через API кабинета продавца. Разберём, как из каталога 1С-Битрикс создавать карточки, передавать цены и держать остатки в актуальном состоянии.

Как устроена интеграция с Wildberries

Главное отличие Wildberries от Яндекс.Маркета или Google Merchant в том, что маркетплейс не забирает файл-фид по ссылке. Вся работа ведётся через набор REST-методов API кабинета продавца, а Битрикс выступает источником данных: наименований, характеристик, цен и остатков.

API разбит на несколько независимых сервисов, у каждого своя зона ответственности:

• Контент (content-api.wildberries.ru) — создание и обновление карточек товаров, категории, характеристики, медиа;
• Цены и скидки (discounts-prices-api.wildberries.ru) — установка цен и плановых скидок;
• Маркетплейс (marketplace-api.wildberries.ru) — остатки и сборочные задания по модели FBS;
• Статистика — заказы, продажи и остатки на складах WB.

На стороне Битрикс типичная интеграция — это агент или крон-задача, которая читает элементы инфоблока каталога, приводит их к формату WB и отправляет запросы в нужный сервис.

Подготовка: токены и доступ к API

Перед разработкой заведите доступы. В кабинете продавца откройте раздел Настройки → Доступ к API и сгенерируйте токены. Токен — это JWT-строка, привязанная к конкретным категориям методов, поэтому обычно нужно несколько ключей: отдельно на «Контент», отдельно на «Цены и скидки» и на «Маркетплейс».

Токены храните вне репозитория. В Битрикс их удобно положить в настройки модуля через Option::set() или в защищённый файл конфигурации, а не в код компонента. Каждый токен передаётся в заголовке Authorization при каждом запросе.

Сопоставление каталога с моделью WB

Wildberries строго типизирует товары: у каждого — предмет (категория) со своим набором обязательных и дополнительных характеристик. Одно из ключевых полей — vendorCode, артикул продавца, по которому карточка связывается с товаром в Битрикс.

Как правило, роли распределяются так:

Если магазин продаёт одежду или обувь, размеры логично хранить как торговые предложения каталога — тогда одна карточка WB собирает все размеры одного товара. Заранее составьте таблицу соответствия свойств Битрикс и характеристик предмета WB: их состав можно получить методами справочников Контент-API.

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

Карточки создаются пакетно методом POST /content/v2/cards/upload. В теле запроса передаётся массив объектов: для каждого — subjectID (предмет), vendorCode, набор характеристик и массив sizes со штрихкодами.

1. Получите список предметов и их характеристики через справочники Контент-API;
2. Соберите объект карточки из полей элемента инфоблока Битрикс;
3. Отправьте пакет (до 100 карточек за запрос);
4. Через некоторое время запросите статус методом получения карточек и заберите присвоенные nmID.

Обратите внимание: создание карточки асинхронное. WB принимает пакет, ставит его в очередь на модерацию и присваивает nmID позже. Эти идентификаторы обязательно сохраняйте обратно в свойства элемента Битрикс — они понадобятся для обновления цен и остатков.

Модели FBW и FBS: чем отличаются

От выбранной схемы логистики зависит, как передавать остатки. Wildberries работает по двум основным моделям:

• FBW — товар физически лежит на складе Wildberries. Остатками управляет сам маркетплейс, из Битрикс их передавать не нужно; ваша задача — только карточки и цены.
• FBS — товар на вашем складе, WB присылает сборочные задания. Остатки нужно регулярно отдавать методом PUT /api/v3/stocks/{warehouseId} Маркетплейс-API, привязывая их к складу продавца.

На практике магазины часто совмещают обе модели. В Битрикс это удобно решать флагом на уровне товара или склада: остатки для FBS-позиций считаются по конкретному складу модуля catalog, а FBW-позиции из выгрузки остатков исключаются.

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

Цены и остатки — самая «живая» часть интеграции: их нужно обновлять по расписанию, а не разово. Разнесите две задачи по разным агентам Битрикс.

Цены. Устанавливаются методом POST /api/v2/upload/task сервиса «Цены и скидки». Передаётся nmID, цена и размер скидки. Источником обычно служит базовый тип цены каталога, а скидку либо берут из акций Битрикс, либо задают отдельным правилом.

Остатки (только FBS). Отдаются методом Маркетплейс-API по штрихкодам и складу. Частоту выбирайте по обороту: для активных магазинов — раз в 5–15 минут по агенту или крону.

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

Типичные ошибки и как их избежать

Большинство проблем при выгрузке на Wildberries сводится к нескольким повторяющимся сценариям:

• Незаполненные обязательные характеристики предмета — карточка уходит в брак на модерации. Проверяйте состав характеристик до отправки;
• Дубли по vendorCode — если один артикул попал в две карточки, WB вернёт ошибку. Держите артикул уникальным на уровне инфоблока;
• Потеря nmID — без сохранённого идентификатора невозможно обновить цену и остаток. Записывайте его сразу после модерации;
• Игнор лимитов — пакетная заливка без пауз приводит к 429 и частичной потере данных;
• Расхождение остатков FBS — из-за резервов и параллельных продаж на сайте. Учитывайте резервы модуля sale в расчёте доступного количества.

Отдельно заложите повторную отправку (retry) для сетевых сбоев и понятное логирование: по логу должно быть видно, какая позиция, каким методом и с какой ошибкой не выгрузилась.

Итог

Выгрузка на Wildberries из 1С-Битрикс — это не генерация фида, а полноценная интеграция по API: токены для «Контента», «Цен» и «Маркетплейса», аккуратное сопоставление свойств каталога с характеристиками предметов, асинхронное создание карточек и регулярная синхронизация цен и остатков с учётом моделей FBW и FBS. Главные риски — потерянные nmID, лимиты частоты и расхождение остатков; всё это лечится хранением идентификаторов, отправкой только изменений и подробным логированием.

Мы в B2Bsite проектируем такие интеграции под конкретный каталог: связываем свойства инфоблоков с характеристиками WB, настраиваем агенты синхронизации и мониторинг ошибок, чтобы карточки, цены и остатки оставались в актуальном состоянии без ручной работы.