Інтеграція 1С-Бітрікс з Wildberries

Інтеграція 1С-Бітрікс з Wildberries

Wildberries — закрита екосистема з нестандартним API. На відміну від Ozon та Яндекс.Маркета, тут нема єдиного Seller API з зрозумілою документацією. API розбитий на кілька незалежних сервісів (Content API, Marketplace API, Statistics API, Prices API), кожен зі своєю авторизацією, ліміти та форматами даних. Інтеграція з 1С-Бітрікс вимагає роботи з кожним із цих сервісів окремо.

Структура API Wildberries

Авторизація — через токени, генеровані в кабінеті постачальника: Налаштування → Доступ до API. Для кожного сервісу можна створити окремий токен з обмеженими правами.

Всі запити — REST, JSON. Авторизація через заголовок Authorization: Bearer <token>.

Завантаження карточок товарів: Content API

Створення карточки — POST /content/v2/cards/upload. Структура карточки WB принципово відрізняється від інфоблоку Бітрікс:

Номенклатура (nmID) — верхній рівень, що об'єднує варіанти товару. Всередині — масив sizes, де кожен розмір має свій skus[] (список штрихкодів). WB ідентифікує конкретний товар за штрихкодом, а не за артикулом.

Обов'язкові поля при створенні карточки:

• vendorCode — артикул постачальника. У Бітрікс — властивість ARTICLE або ARTNUMBER.
• brand — бренд. Повинен збігатися із зареєстрованим у WB.
• title — назва. WB генерує автоматично з категорії + бренду + характеристик. Ручна назва може бути відхилена.
• description — до 5000 символів.
• subjectID — ID категорії WB. Отримується через GET /content/v2/object/all.
• characteristics — масив характеристик, залежно від категорії.
• sizes[].skus[] — штрихкоди для кожного розміру.

Характеристики (characteristics). У кожної категорії WB — свій набір обов'язкових характеристик. Отримати список: GET /content/v2/object/charcs?subjectID={id}. Характеристики бувають текстовими та довідниковими. Для довідникових — значення повинне точно збігатися з варіантом з довідника WB.

Зіставлення на інфоблок Бітрікс:

Елемент інфоблоку → nmID (після створення WB повертає nmID)
  ├── NAME → title (але WB може переопредиліти)
  ├── PROPERTY_ARTICLE → vendorCode
  ├── PROPERTY_BRAND → brand
  ├── DETAIL_TEXT → description
  ├── PROPERTY_COLOR → characteristics[{id: N}]
  └── DETAIL_PICTURE + PROPERTY_PHOTOS → mediaFiles[]

Торгові пропозиції → sizes[]
  ├── PROPERTY_SIZE → techSize
  ├── PROPERTY_BARCODE → skus[]
  └── Ціна → (через Prices API окремо)

Завантаження фотографій

Фотографії завантажуються окремим запитом: POST /content/v2/cards/upload/add для прив'язки медіафайлів до карточки. WB приймає фото за URL — вказуєте масив посилань на зображення з вашого сервера. Вимоги: мінімум 900×1200 px, формат JPG/PNG, білий фон для більшості категорій.

У Бітрікс зображення зберігаються в /upload/iblock/. URL формується як https://ваш-домен.ru/upload/iblock/xxx/photo.jpg. Переконайтеся, що файли доступні за прямим URL без авторизації.

Управління цінами

Prices API працює окремо від Content API. Метод POST /api/v2/upload/task встановлює ціну та знижку:

• price — ціна до знижки (роздрібна).
• discount — відсоток знижки. Остаточна ціна = price * (1 - discount/100).

WB нав'язує SPP (знижку постійного покупця) поверх вашої знижки. Остаточна ціна для покупця = ваша ціна - ваша знижка - SPP. Це значить, що при установці ціни з Бітрікс потрібно враховувати SPP — інакше маржинальність буде нижче очікуваної.

Синхронізація: cron-агент у Бітрікс кожні 15–30 хвилин перевіряє товари зі змінена ціною в b_catalog_price і відправляє пакетний запит. Ліміт — 1000 товарів за запит.

Залишки та замовлення (FBS)

Залишки FBS. Метод PUT /api/v3/stocks/{warehouseId} оновлює залишки на складі постачальника. warehouseId — ID вашого складу у WB (створюється в кабінеті). Кожен товар ідентифікується за штрихкодом (sku), а не за артикулом. Зіставлення штрихкод → елемент інфоблоку повинно бути однозначним.

Замовлення FBS. Отримання нових замовлень: GET /api/v3/orders/new. Кожне замовлення містить skus[] — штрихкоди замовлених товарів. Обробник Бітрікс:

1. За штрихкодом знаходить елемент інфоблоку / торговою пропозицію.
2. Створює замовлення в sale з зіставленням товарів.
3. При збиранні — викликає PUT /api/v3/orders/{orderId}/confirm і формує наклейку для упаковки через POST /api/v3/orders/stickers.

Важливо: WB не передає дані покупця (ім'я, адреса, телефон) постачальнику. Замовлення в Бітрікс створюється з мінімальним набором даних — по суті, тільки список товарів і сума.

Типові проблеми

Карточка не створюється. Причина — неправильний subjectID або відсутність обов'язкової характеристики. API повертає помилку з описом, але іноді неінформативне. Перевіряйте набір характеристик для категорії через /content/v2/object/charcs.

Дублі карточок. WB може об'єднувати карточки з однаковим штрихкодом або артикулом. Якщо при інтеграції штрихкоди некоректні — замість оновлення існуючої карточки створюється нова.

Rate limiting. Content API — до 100 запитів на хвилину. При масовому завантаженні каталогу потрібна черга з затримкою. У Бітрікс реалізується через агенти з пошаговою обробкою.