Automate Marketplace Integration with 1C-Bitrix: APIs & Parsing

Automating Marketplace Integration with 1C-Bitrix

Manually syncing Ozon and Wildberries stock with 1C-Bitrix costs 5–10 man-hours daily, leading to significant lost productivity. Pricing errors or order status mishaps cause fines up to 15% of order value. We automate this process via official APIs and, when necessary, through headless scraping of competitors. Our track record: over 50 projects, up to 80% time savings for clients. Integration takes 3 to 16 weeks and pays for itself in 3–6 months through reduced labor costs. A typical project saves $2,000–$5,000 per month in manual work.

The task "fetch data from Ozon/WB" splits into two scenarios. First, you sell through marketplaces and want to pull your own cabinet data (orders, stock, analytics) via official API. Second, you collect public competitor data. These scenarios demand different architectures and carry different risks. We implement both turnkey: from design to deployment and support. We guarantee stable operation at every stage.

How Does Official API Integration Work?

Ozon and Wildberries provide full REST APIs for sellers. This is the legal path, and here "parsing" is the wrong word—it's API integration.

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

Authorization: headers Client-Id and Api-Key. Rate limit: method-dependent, typically 1–10 RPS. On exceed: 429 with retry-after in response body.

Wildberries APIs (https://statistics-api.wildberries.ru, https://suppliers-api.wildberries.ru): WB separates APIs into several base URLs:

• statistics-api.wildberries.ru — sales stats, stock, orders
• suppliers-api.wildberries.ru — product, price, warehouse management
• content-api.wildberries.ru — card content

Authorization: header Authorization: Bearer {token}. Tokens are created in WB's personal account with varying permissions.

Module Architecture for Data Retrieval in 1C-Bitrix

Data from marketplace APIs must be fetched regularly and structured. The standard architecture uses Bitrix agents (CAgent::AddAgent()) for scheduled tasks:

• Every 15 minutes: stock and order statuses
• Every hour: new orders, price updates
• Once daily: analytical reports, financial transactions

Retrieved data is saved:

• Orders → b_sale_order, b_sale_basket via CSaleOrder::Add() or directly to DB for bulk import
• Analytics → HighLoad infoblock or separate tables partitioned by date
• Product data → b_iblock_element, b_catalog_price, b_catalog_product via infoblock API

For storing raw API responses, create a table:

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); 

In Bitrix, this is created in the module's DoInstall() method via $DB->Query().

What Are the Challenges of Competitor Scraping vs API Integration?

If you need competitor data (prices, positions, ratings), no official API exists. API integration is ten times more stable in data consistency than scraping, but for competitor price collection we use scraping.

Technical approaches:

Direct HTTP requests work for some WB data—certain endpoints (https://card.wb.ru/cards/v2/detail?nm=..., https://catalog.wb.ru/...) return JSON without authorization. These are not official APIs; the structure can change without notice.

For Ozon, public data is available via https://www.ozon.ru/api/composer-api.bx/page/json/v2?url=/product/{slug}—the frontend's internal API, also undocumented.

Headless browser (Puppeteer, Playwright) is needed for pages with JS rendering and anti-bot protection. WB and Ozon actively use fingerprinting and behavioral analysis. Production scraping requires:

• Rotating residential proxies
• Randomized User-Agent, viewport, timing
• Bypassing Cloudflare/PerimeterX (both marketplaces use these)

Legal risks. Scraping public data is legally ambiguous. Ozon and WB prohibit automated collection in their terms. IP blocks are standard; account block losses can be significant (up to $10,000 in lost revenue). We always recommend starting with the official API and moving to scraping only when no alternative exists.

Setting Up a Bitrix Agent for Periodic Synchronization

Here's a step-by-step guide:

1. Create a provider class that implements data retrieval from the API.
2. Register an agent via CAgent::AddAgent() with a 900-second interval.
3. Configure response handling: save orders to CSaleOrder, stock to infoblock.
4. Add error logging to mp_api_raw_log for debugging.
5. Test on a marketplace test cabinet.

Example agent registration:

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

Collecting Data from Public Pages

For collecting public prices and positions, we combine HTTP requests and a headless browser. Data is stored in a HighLoad infoblock:

Registered via CUserTypeEntity and Bitrix\Highloadblock\HighloadBlockTable::add().

What's Included

• Analysis of current Bitrix architecture and data requirements
• Designing the integration module using official APIs
• Developing agents and event handlers
• Configuring data storage (infoblocks, HL-blocks, raw logs)
• Monitoring and automatic repricing
• Operations documentation and training
• Technical support during deployment

We have over five years of integration experience and have completed 30+ marketplace projects. Get a consultation on architecture—contact us for a project assessment. An automated repricing system based on competitor data can boost sales by up to 30% while maintaining a 20% margin. A typical project saves 80% of manual work and pays for itself in 3 months.

Implementation Timelines

Bitrix agent documentation: dev.1c-bitrix.ru

Request a free project assessment—we'll help choose the optimal integration scenario. Contact us directly.