Интеграция Ozon и Wildberries с 1С-Битрикс: API и парсинг данных

Интеграция Ozon и Wildberries с 1С-Битрикс: парсинг и API

Синхронизация остатков Ozon и Wildberries с 1С-Битрикс вручную — это 5–10 человеко-часов в день. Ошибки в ценах или статусах заказов ведут к штрафам до 10 000 ₽ за инцидент. Мы автоматизируем этот процесс через официальные API и, при необходимости, через headless-парсинг конкурентов. Наш опыт — более 50 проектов, экономия времени до 80% для заказчиков. Интеграция занимает от 3 до 16 недель и окупается за 3–6 месяцев за счёт снижения трудозатрат.

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

Как подключиться к API Ozon и Wildberries?

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:

• statistics-api.wildberries.ru — статистика продаж, остатки, заказы
• suppliers-api.wildberries.ru — управление товарами, ценами, складами
• 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().

Почему парсинг конкурентов сложнее интеграции с API?

Если нужны данные конкурентов (цены, позиции, рейтинги), официального API нет. API-интеграция надёжнее парсинга в 10 раз по стабильности данных, но для сбора конкурентных цен используем парсинг.

Технические подходы:

Прямые 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 — стандартная практика, потери от блокировки аккаунта могут превышать 100 000 ₽. Мы всегда рекомендуем начинать с официального API и переходить к парсингу только при отсутствии альтернатив.

Как настроить агент Битрикс для периодической синхронизации?

Вот пошаговая инструкция:

1. Создайте класс-провайдер, реализующий получение данных из API.
2. Зарегистрируйте агент через CAgent::AddAgent() с интервалом 900 секунд.
3. Настройте обработку ответов: сохраняйте заказы в CSaleOrder, остатки — в инфоблок.
4. Добавьте логирование ошибок в mp_api_raw_log для отладки.
5. Протестируйте на тестовом кабинете маркетплейса.

Пример регистрации агента:

CAgent::AddAgent( "\\YourModule\\SyncAgent::run();", "your.module", "N", 900, "", "Y", date("d.m.Y H:i:s"), 30 ); 

Что делать, если нужны данные с публичных страниц?

Для сбора публичных цен и позиций используем сочетание HTTP-запросов и headless-браузера. Данные храним в HighLoad-инфоблоке:

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

Что входит в работу

• Анализ текущей архитектуры Битрикс и требований к данным
• Проектирование модуля интеграции с использованием официального API
• Разработка агентов и обработчиков событий
• Настройка хранения данных (инфоблоки, HL-блоки, сырые логи)
• Мониторинг и автоматический репрайсинг
• Документация по эксплуатации и обучение
• Техническая поддержка на этапе внедрения

Мы занимаемся интеграциями более 5 лет, реализовали 30+ проектов с маркетплейсами. Получите консультацию по архитектуре — свяжитесь с нами для оценки вашего проекта.

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

Документация по агентам Битрикс: dev.1c-bitrix.ru

Закажите бесплатную оценку вашего проекта — мы поможем выбрать оптимальный сценарий интеграции. Свяжитесь с нами прямо сейчас.