Ефективна інтеграція Ozon та Wildberries з 1С-Бітрікс

Практичний посібник: інтеграція Ozon та Wildberries з 1С-Бітрікс

Інтеграція через API працює до 15 разів швидше, ніж ручне завантаження даних. Синхронізація залишків Ozon та Wildberries з 1С-Бітрікс вручну — це 5–10 людино-годин на день. Помилки в цінах або статусах замовлень ведуть до штрафів до $90–130 за інцидент. Ми автоматизуємо цей процес через офіційні API та, за необхідності, через headless-парсинг конкурентів. Наш досвід — понад 5 років та 50+ проєктів. Економія часу до 80%, окупається за 3–6 місяців.

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

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

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

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

Авторизація: заголовки Client-Id та Api-Key. Rate limit: залежить від методу, зазвичай 1–10 RPS. Наприклад, для Ozon ліміт становить 10 RPS, для WB — 5 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 — стандартна практика, втрати від блокування акаунта можуть перевищувати $900–1.3k. Ми завжди рекомендуємо починати з офіційного API і переходити до парсингу тільки за відсутності альтернатив.

Як налаштувати агент Бітрікс для періодичної синхронізації?

Ось покрокова інструкція:

1. Створіть клас-провайдер, який реалізує отримання даних з API.
2. Зареєструйте агент через CAgent::AddAgent() з інтервалом 900 секунд (15 хвилин).
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-блоки, сирі логи)
• Моніторинг та автоматичний репрайсинг (підвищує продажі до 30%)
• Документація з експлуатації та навчання
• Технічна підтримка на етапі впровадження

Ми займаємося інтеграціями понад 5 років, реалізували 50+ проєктів. Отримайте консультацію з архітектури — зв'яжіться з нами для оцінки вашого проєкту.

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

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

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