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

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

Задача «получать данные с Ozon/WB» на практике делится на два принципиально разных сценария. Первый — вы продаёте через эти маркетплейсы и хотите тянуть данные своего кабинета (заказы, остатки, аналитику) через официальный API. Второй — вы хотите собирать публичные данные конкурентов или мониторить цены. Это разные задачи с разными рисками и разной архитектурой.

Сценарий 1: Официальное API — получение данных своего магазина

Ozon и Wildberries предоставляют полноценные REST API для продавцов. Это легальный путь, и здесь «парсинг» — неправильное слово. Речь идёт об интеграции через API.

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

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

Авторизация: заголовки 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С-Битрикс: архитектура модуля получения данных

Данные из API маркетплейсов нужно получать регулярно, структурировать и хранить в Битрикс. Стандартная архитектура:

Агенты Битрикс (CAgent::AddAgent()) запускают задачи по расписанию:

• Каждые 15 минут — остатки и статусы заказов
• Каждый час — новые заказы, обновление цен
• Раз в сутки — аналитические отчёты, финансовые транзакции

Полученные данные сохраняются в нескольких местах в зависимости от типа:

• Заказы → b_sale_order, b_sale_basket через CSaleOrder::Add() или напрямую в БД для bulk-импорта
• Аналитика → 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);

В Битрикс это создаётся в методе 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 — стандартная практика. Аккаунт продавца могут заблокировать, если парсинг будет связан с ним.

Обработка и хранение спарсенных данных в Битрикс

Данные о конкурентах удобно хранить в HighLoad-инфоблоке — это избавляет от прямой работы с SQL и даёт готовый API для выборок. Структура HL-инфоблока для мониторинга цен:

Регистрируется через CUserTypeEntity и Bitrix\Highloadblock\HighloadBlockTable::add().

Автоматическое реагирование: правила по данным

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

Сроки реализации