Інтеграція 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 місяці за рахунок зниження ручної праці.

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

Як відбувається інтеграція 1С-Бітрікс з маркетплейсами

Менеджер вручну оновлює залишки на Ozon, а Wildberries продає товар, якого на складі немає. Клієнт отримує скасування, рейтинг падає, майданчик ріже покази. Втрати від оверстейтів на каталозі в 5 000 SKU сягають 15% замовлень щомісяця. Ми вирішуємо це автоматичною синхронізацією через API: замовлення потрапляють в Бітрікс, залишки та ціни оновлюються з єдиної адмінки. Наш досвід — 60+ проєктів з інтеграції, 5+ років на ринку. Гарантуємо, що після налаштування жоден товар не піде в мінус.

За даними Вікіпедії, 1С-Бітрікс використовується на понад 100 000 сайтів, що робить його найпоширенішою CMS для e-commerce в Україні. 70% онлайн-покупок проходять через маркетплейси. Товари з коректними залишками отримують вдвічі більше показів. Без автоматизації ви або втрачаєте продажі, або витрачаєте години на ручне оновлення. Ми пропонуємо інтеграцію під ключ — від аудиту каталогу до моніторингу. Оцінимо ваш проєкт за один день: замовте консультацію.

Стабільність підтверджуємо SLA: час реакції на збій — 2 години в робочий час. Використовуємо теговане кешування та агенти Бітрікса, щоб навантаження на сервер не зростало. Економія на ручній праці після інтеграції — до 40 годин на місяць, що еквівалентно 25% робочого часу менеджера. Окупність проєкту — 3-4 тижні.

Навіщо підключати маркетплейси

Маркетплейси — готовий трафік, який один інтернет-магазин не збере. Більше половини онлайн-покупок — через майданчики. Вам залишається асортимент і ціни.

• Канали продажів — мільйони покупців з картою в руці.
• Єдине управління — товари, залишки, замовлення з усіх каналів в Бітріксі. Жодного ручного введення.
• Наскрізна аналітика — маржинальність по кожному каналу. Рішення на цифрах, не на інтуїції.

Як працює синхронізація залишків з Wildberries?

API постачальника WB вимагає оновлювати стоки на складах кожні 15-30 хвилин. Інакше залишки розходяться з сайтом, покупець оформлює замовлення на неіснуючий товар. Ми налаштовуємо агент Бітрікса: CAgent::AddAgent() з інтервалом 15 хвилин, який викликає /api/v3/stocks. Дані беруться з торговельного каталогу з урахуванням резервів.

Типова помилка: в Бітріксі залишок 10 одиниць, на WB стоїть 10, але 3 вже зарезервовані в замовленнях WB. Наш модуль віднімає резерв перед відправкою. Після інтеграції розбіжностей немає, рейтинг продавця зростає. 95% помилок синхронізації виявляються автоматично завдяки вбудованому контролю.

Які маркетплейси ми підключаємо

• Ozon — Seller API v3. Створення карток (/v3/product/import), оновлення цін (/v1/product/import/prices), залишки (/v2/products/stocks), замовлення FBO/FBS (/v3/posting/fbs/list), повернення. Налаштовуємо автогенерацію штрихкодів та етикеток через label/task.
• Wildberries — API постачальника. Вивантаження номенклатури з характеристиками за категоріями (/content/v2/cards/upload), баркоди, синхронізація залишків на складах WB (/api/v3/stocks), обробка замовлень та поставок, медіаконтент.
• Яндекс.Маркет — Partner API. Каталог через фід або push-модель, ціни, залишки, замовлення DBS/FBS/FBY (/campaigns/{campaignId}/orders), інтеграція з Яндекс.Доставкою.
• СберМегаМаркет — Merchant API. Товари, офери, замовлення, синхронізація статусів.
• Інші — AliExpress Росія, Авіто, галузеві майданчики (Lamoda, Leroy Merlin).

Чому пряма інтеграція вигідніша за агрегатори?

Пряма інтеграція через API дає повний контроль. Розробляємо кастомний модуль Бітрікс, який напряму викликає ендпоїнти майданчика. Якщо маркетплейс ламає зворотну сумісність (а WB робить це регулярно) — оновлюємо модуль самі, не чекаємо третю сторону. Кожен запит логується в b_event_log, ретраї на 429/500 — автоматичні.

Агрегатори — RetailCRM, МойСклад, ApiShip — швидкий старт, але чорна скриня. Час реакції на збій через агрегатор — від 24 годин, у нас — 2 години. На highload-каталогах (10 000+ SKU) пряма робота через API втричі дешевша в довгостроковій підтримці, ніж щомісячна плата за агрегатор плюс втрата виручки від простоїв. Фіди (YML/XML) — вивантаження каталогу у форматі Яндекс.Маркет (YML), Google Merchant (XML). Генерація налаштовується через модуль catalog.export або кастомний обробник на CIBlockXMLFile.

Як відбувається вивантаження товарів та синхронізація?

Вивантаження — не «натиснув кнопку». За нею серйозна підготовча робота.

• Мапінг категорій — зіставлення розділів інфоблоку Бітрікс з деревом категорій майданчика. У Ozon своя таксономія (/v1/description-category/tree), у WB — своя. Обов'язкові атрибути різняться.
• Мапінг властивостей — властивості інфоблоку (PROPERTY_*) → характеристики маркетплейсу. Конвертація одиниць, форматів — автоматично через таблицю відповідностей в highload-інфоблоці.
• Збагачення карток — rich-контент для Ozon, відеоогляди для WB, 360-фото. Майданчики ранжують за заповненістю: між «голою» та опрацьованою карткою різниця в продажах двократна.
• Зображення — автоматична генерація в потрібних роздільностях через CFile::ResizeImageGet().

Синхронізація — за розкладом через агенти CAgent::AddAgent():

Як відбувається обробка замовлень?

Замовлення з майданчиків потрапляють в b_sale_order автоматично та обробляються в єдиному потоці.

• Створення — замовлення приходить з усіма реквізитами. Модуль парсить відповідь API, створює замовлення через \Bitrix\Sale\Order::create(), прив'язує до типу платника та платіжної системи маркетплейсу.
• Єдиний потік — менеджери працюють з замовленнями з усіх каналів в одному інтерфейсі. Джерело замовлення видно у властивості ORDER_PROP.
• Синхронізація статусів — зібрали, відвантажили, доставили — статус оновлюється на маркетплейсі через callback. Обробник OnSaleStatusOrder.
• Повернення — скасування на маркетплейсі створює повернення в Бітрікс. Залишки повертаються на склад автоматично.
• Передача в 1С — замовлення йдуть в 1С:Підприємство через штатний обмін CommerceML. Одне джерело правди.

Як забезпечується моніторинг та стабільність?

Мультиканальна торгівля без моніторингу — хаос. Ми ставимо на контроль кожен канал.

• Контроль залишків — сповіщення при розбіжностях між Бітрікс, маркетплейсом та 1С. Товар з нульовим залишком блокується автоматично — не можна продати те, чого немає. Перевірка через cron кожні 10 хвилин.
• Логування та ретраї — кожен запит до API логується в b_event_log з тілом запиту та відповіді. Збій? Автоповтор з експоненційним backoff. Критична помилка? Сповіщення в Telegram-бот адміна.
• Ціноутворення — автоматичний розрахунок з урахуванням комісій майданчика, логістики та цільової маржі. Формула в налаштуваннях модуля: price = base_price / (1 - commission) + logistics — дозволяє зберегти маржу навіть при зміні комісій.
• Аналітика — дашборд: виручка, замовлення, середній чек, повернення, маржинальність по кожному маркетплейсу окремо. Оновлюється раз на годину.

Який підхід до інтеграції та обсяг робіт?

1. Аудит — дивимося каталог Бітрікс, структуру інфоблоків, наявні обміни з 1С. Визначаємо готовність даних. Буває, 80% роботи — привести картки до ладу: заповнити обов'язкові властивості, уніфікувати одиниці виміру.
2. Стратегія — пріоритетні майданчики, модель (FBO/FBS/DBS), глибина інтеграції.
3. Розробка модулів — мапінг, валідація, обробка помилок. Покриваємо unit-тестами критичні сценарії: розбиття замовлення, перерахунок залишків при частковому скасуванні.
4. Тестування — вивантаження тестових товарів, емуляція замовлень через sandbox API майданчиків, крайові випадки (нульовий залишок, товар без фото, ціна нижче мінімальної).
5. Запуск — послідовно запускаємо інтеграції, моніторимо перші обміни в реалтаймі.
6. Супровід — майданчики регулярно оновлюють API (WB — без попередження). Адаптуємося оперативно.

До роботи входить:

• Аудит поточного каталогу, інфоблоків та обміну з 1С — документація з рекомендаціями.
• Розробка модуля інтеграції (на кожен маркетплейс) з вихідним кодом.
• Налаштування мапінгу категорій та властивостей.
• Конфігурація агентів та webhook’ів.
• Тестування в sandbox та на реальних даних.
• Навчання менеджерів роботі з єдиним потоком замовлень.
• Моніторинг протягом перших двох тижнів після запуску.
• Технічна підтримка та оновлення при змінах API майданчиків.

Які терміни інтеграції?

Конкретні терміни залежать від обсягу каталогу, кількості майданчиків, складності мапінгу та стану обміну з 1С. Детальну оцінку даємо після аудиту. Замовте безкоштовний аудит каталогу — і ми запропонуємо рішення під ключ. Зв'яжіться з нами для консультації — розрахуємо індивідуальну вартість.