Парсинг даних з маркетплейсів (Ozon, Wildberries) для 1С-Бітрікс

Парсинг даних з маркетплейсів (Ozon, Wildberries) для 1С-Bitrix

Завдання «отримувати дані з Ozon/WB» на практиці ділиться на два принципово різні сценарії. Перший — ви продаєте через ці маркетплейси і хочете тягнути дані свого кабінету (замовлення, залишки, аналітику) через офіційний API. Другий — ви хочете збирати публічні дані конкурентів або моніторити ціни. Це різні завдання з різними ризиками і різною архітектурою.

Сценарій 1: Офіційне API — отримання даних вашого магазину

Ozon та Wildberries надають повноцінні REST API для продавців. Це законний шлях, і тут «парсинг» — неправильне слово. Йдеться про інтеграцію через API.

Ozon Seller API (https://api-seller.ozon.ru):

Основні групи методів, корисні для інтеграції з Bitrix:

Авторизація: заголовки Client-Id та Api-Key. Rate limit: залежить від методу, зазвичай 1–10 RPS. При перевищенні — 429, тіло відповіді містить retry-after.

Wildberries API (https://statistics-api.wildberries.ru, https://suppliers-api.wildberries.ru):

WB поділив API на кілька базових URL залежно від типу даних:

• https://statistics-api.wildberries.ru — статистика продаж, залишки, замовлення
• https://suppliers-api.wildberries.ru — управління товарами, цінами, складами
• https://content-api.wildberries.ru — контент карток

Авторизація: заголовок Authorization: Bearer {token}. Токени створюються у особистому кабінету WB, мають різні права (статистика окремо від управління контентом).

Інтеграція в 1С-Bitrix: архітектура модуля отримання даних

Дані з API маркетплейсів потрібно отримувати регулярно, структурувати та зберігати у Bitrix. Стандартна архітектура:

Агенти Bitrix (CAgent::AddAgent()) запускають завдання за розкладом:

• Кожні 15 хвилин — залишки та статуси замовлень
• Кожну годину — нові замовлення, оновлення цін
• Раз на добу — аналітичні звіти, фінансові транзакції

Отримані дані зберігаються у кількох місцях залежно від типу:

• Замовлення → b_sale_order, b_sale_basket через CSaleOrder::Add() або напряму в БД для масового імпорту
• Аналітика → HighLoad-інфоблок або окремі таблиці з партиціюванням по датам
• Товарні дані → b_iblock_element, b_catalog_price, b_catalog_product через API інфоблоків

Для зберігання сирих відповідей API (потрібно для отладки та повторної обробки) створіть окрему таблицю:

CREATE TABLE mp_api_raw_log (
    id          SERIAL PRIMARY KEY,
    marketplace VARCHAR(30) NOT NULL,
    method      VARCHAR(100) NOT NULL,
    params      JSONB,
    response    JSONB,
    status_code SMALLINT,
    created_at  TIMESTAMP DEFAULT NOW()
);
CREATE INDEX ON mp_api_raw_log (marketplace, created_at);

У Bitrix це створюється в методі DoInstall() модуля через $DB->Query().

Сценарій 2: Парсинг публічних даних — ціни та позиції конкурентів

Тут йдеться про збір даних з публічних сторінок маркетплейса (позиції у виданні, ціни конкурентів, рейтинги). Офіційного API для цього немає.

Технічні підходи:

Прямі HTTP-запити працюють для частини даних WB — деякі endpoint'и (https://card.wb.ru/cards/v2/detail?nm=..., https://catalog.wb.ru/...) повертають JSON без авторизації. Це не офіційний API, структура може змінитися без попередження.

Для Ozon публічні дані доступні через https://www.ozon.ru/api/composer-api.bx/page/json/v2?url=/product/{slug} — внутрішній API фронтенду, також без документації та гарантій стабільності.

Headless-браузер (Puppeteer, Playwright) потрібен для сторінок з JS-рендерингом та антибот-захистом. WB та Ozon активно використовують fingerprinting та поведінковий аналіз. Для production-парсингу потрібні:

• Ротація residential proxy
• Рандомізація User-Agent, viewport, timing
• Обхід Cloudflare/PerimeterX (вони стоять на обох маркетплейсах)

Правові ризики. Парсинг публічних даних маркетплейсів юридично неоднозначен. Ozon та WB у користувацьких угодах забороняють автоматичний збір даних. Блокування IP — стандартна практика. Рахунок продавця можуть заблокувати, якщо парсинг буде пов'язаний з ним.

Обробка та зберігання спарсених даних у Bitrix

Дані про конкурентів зручно зберігати в HighLoad-інфоблоці — це позбавляє від прямої роботи з SQL та дає готовий API для виборок. Структура HL-інфоблока для моніторингу цін:

Реєструється через CUserTypeEntity та Bitrix\Highloadblock\HighloadBlockTable::add().

Автоматичне реагування: правила по даних

Сенс збору даних — не просто дивитися, а реагувати. Агент раз на годину перевіряє: якщо ціна конкурента на аналогічний товар нижча за нашу на X%, змінюємо ціну через CCatalogProduct::Update() або CPrice::Update(). Ліміти змін (не знижувати нижче собівартості) задаються в настройках модуля.

Терміни реалізації