Інтеграція 1С-Бітрікс з Wildberries: ціни, залишки, API

Уявіть: ваш відділ закупівель вручну оновлює 5000 товарів на Wildberries щотижня. Помилки в цінах, дублі карток, прострочені залишки — це не винятки, а норма. Ручна робота віднімає до 20 годин на тиждень, а клієнти скаржаться на недоступні позиції. Ми автоматизуємо обмін даними між 1С-Бітрікс та Wildberries через Wildberries API, виключаючи людський фактор і прискорюючи операції в 3 рази.

На відміну від Ozon та Яндекс.Маркету, Wildberries використовує кілька незалежних сервісів — Content, Marketplace, Prices, Statistics, Analytics. У кожного своя авторизація, ліміти та формати. Ми закриваємо всі ці точки входу єдиним модулем, що синхронізує картки, залишки, ціни та замовлення. Інтеграція працює на агентах Бітрікс з тегованим кешуванням та чергами, щоб не перевищувати ліміти API.

Чому стандартні модулі не підходять?

Готові рішення з Маркетплейсу часто не враховують FBS — вони працюють тільки з DBS. Багато модулів не підтримують розмірну сітку, що призводить до дублів карток. Ми не використовуємо сторонні бібліотеки — пишемо код під ваш стек: PHP 8.1+, інфоблоки v2.0, ORM. Це дає гнучкість і контроль над кожним запитом.

Структура API Wildberries

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

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

Як завантажити картки товарів без дублів?

Створення картки — 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 окремо) 

Чому виникають дублі карток?

WB може об'єднувати картки з однаковим штрихкодом або артикулом. Якщо при інтеграції штрихкоди некоректні — замість оновлення існуючої картки створюється нова. Щоб цього уникнути, ми перевіряємо унікальність vendorCode та skus[] на стороні Бітрікс, а також використовуємо GET /content/v2/cards/search для пошуку існуючих карток перед створенням. У нашому рішенні ми додали перевірку на збіг артикула: якщо картка вже є, викликається PATCH /content/v2/cards/update, а не upload.

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

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 не передає дані покупця (ім'я, адресу, телефон) постачальнику. Замовлення в Бітрікс створюється з мінімальним набором даних — по суті, тільки список товарів і сума.

Як уникнути rate limiting?

Content API — до 100 запитів на хвилину. При масовому завантаженні каталогу потрібна черга із затримкою. У Бітрікс ми реалізуємо агенти з покроковою обробкою: кожен агент обробляє не більше 50 елементів, потім ставить наступний агент через 10 секунд. Це гарантує, що ліміт не перевищено, і інтеграція стабільна.

Що входить в роботу по інтеграції

• Аудит поточного сайту та каталогу.
• Налаштування API-ключів Wildberries.
• Розробка модуля обміну (картки, ціни, залишки, замовлення).
• Налаштування агентів синхронізації та черг.
• Тестування на бойових даних.
• Навчання співробітників роботі з інтеграцією.
• Передача документації та вихідного коду.
• Гарантійна підтримка 12 місяців.

Середній термін виконання — від 5 днів до 2 тижнів залежно від обсягу. Ми виконали понад 50 інтеграцій з Wildberries для клієнтів з СНД. Кожна зміна API обробляється в рамках гарантійної підтримки — ви не ризикуєте, навіть якщо Wildberries оновить протокол. Інтеграція окупається в середньому за 3 місяці за рахунок зниження ручної праці.

Хочете оцінити проєкт? Зв'яжіться з нами — безкоштовно проаналізуємо ваш каталог і підготуємо комерційну пропозицію. Замовте інтеграцію зараз і отримайте знижку на перший місяць підтримки.