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.

Marketplace Development on 1C-Bitrix: Overcoming Standard Architecture Limitations

The b_sale_order table and related b_sale_basket are not designed for multivendor out of the box. Bitrix has no built-in 'marketplace' module — each time it's custom development on top of the sale module. The standard sale module cannot split orders by different suppliers: if the cart contains items from three sellers, Bitrix creates a single order with one number, status, and total. It's impossible to send each sub-order to a separate dashboard, calculate commissions for each seller, or allow partial shipment. We have to redefine the entire logic: from cart to status model. Additionally, the standard search (Sphinx) and caching are not optimized for a multivendor catalog — with 100,000 items from 500 suppliers, filters by supplier lead to performance degradation (queries with WHERE on IBLOCK_ELEMENT_PROPERTY become 5–10 times slower). We write a separate module that extends the standard cart: adds item-to-supplier binding via order property, splits a single order into sub-orders by seller, and routes each separately.

Why Standard Solutions Are Not Suitable for Multivendor Platforms?

Marketplace Models

Classic marketplace — the operator does not hold inventory. All product logic lies with sellers, the platform handles traffic and payment gateway. Technically, this is a separate supplier infoblock linked via UF_VENDOR_ID in the highload catalog infoblock.

Hybrid model — the operator sells alongside external suppliers. The main pain: ranking in the catalog. If suppliers see that the platform's own listings always rank higher, they leave. We solve this with a separate sorting component where position is determined by rating, shipping speed, and price, without privileges for 'own' items.

Service marketplace — requests, tenders, escrow. Here, instead of b_sale_basket, a custom request entity works with a workflow via Bitrix business processes.

B2B marketplace — contracts, reconciliation statements, credit lines, EDI. Authorization by TIN, multi-price groups via b_catalog_group, shipping limits.

What Technical Problems Does Marketplace Development on 1C-Bitrix Solve?

Monetization Models

What Does the Seller Dashboard Include?

The dashboard is the heart of a marketplace. An inconvenient dashboard = empty platform. No standard solution exists; we build from scratch using Bitrix components.

• Catalog management — CRUD for products via custom component, bulk CSV/XML upload via CIBlockXMLFile. Nobody manually enters 10,000 SKUs, so import is the first thing we do.
• Order processing — sub-orders land in the dashboard via ajax-polling or websocket. Confirmation, invoice printing via CSalePdf, status update with back-sync to the main order.
• Financial analytics — dashboard on highload infoblock of aggregated data. Revenue, commissions, payouts — details by product and period. The seller sees what sells and what just occupies the showcase.
• Delivery settings — seller's own tariffs, binding to sale.delivery.handler.
• Communication — built-in chat without revealing contacts. Implemented via im module or custom message table.
• Promotions — discounts, promo codes via b_sale_discount with filter by vendor_id.

Moderation and Quality Control

One batch of counterfeit goods kills the platform's reputation. Therefore, moderation is mandatory.

• Product moderation — status ACTIVE='N' until verification. Auto-moderation filters obvious violations (banned words, missing photos), manual moderation handles disputes. Handler OnBeforeIBlockElementUpdate prevents bypass.
• Seller verification — TIN check via Federal Tax Service API, document scans upload. Statuses: new → verified → premium. Each level unlocks limits on product count and commissions.
• Rating system — not just stars. The algorithm considers shipping speed (AVG(ship_date - order_date)), return rate, and answer quality.
• Anti-fraud — detect rating manipulation by patterns (same IP, identical texts, abnormal frequency). Duplicate accounts caught by TIN and bank details.
• Typical mistake: storing supplier data in a regular infoblock — with 1000+ sellers, queries become slow. Use highload infoblocks.

How Is the Seller Payout System Structured?

The financial module is why sellers join the platform.

• Commission calculation — handler on order status change. Commission depends on category, seller status, current conditions. Stored in a separate table vendor_transactions.
• Periodic payouts — cron task generates a register: weekly, bi-monthly, or monthly. Minimum payout amount, holding until confirmation.
• Acts and reports — PDF generation via PhpOffice\PhpSpreadsheet, automatic numbering, one-click download.
• Holding — funds held until product received. Reduces disputes and returns.
• Payouts via banking API — YooKassa, CloudPayments, direct banking APIs. Seller receives money without calls or reminders.
• Important: splitting orders at the OnSaleOrderSaved handler leads to status mismatch. Split at the cart stage.
• Manual fiscalization of each sub-order violates 54-FZ. Use a single receipt with 'agent' attribute. On one project, fiscalization automation saved significant monthly costs. On another, search optimization via Elasticsearch reduced catalog loading time by 80% (from 3 seconds to 0.6 seconds).

How We Build Marketplace Architecture

1. Define business model — choose marketplace type and monetization scheme.
2. Database design — highload infoblocks for catalogs over 50,000 SKU, separate tables for sub-orders (orders_split) and transactions.
3. Core development — create module marketplace.vendor, implement product-to-supplier binding, order splitting mechanism, agents for commission calculation.
4. Payment gateway and 54-FZ integration — configure fiscalization via ATOL Online or CloudPayments.
5. Load testing — use k6 or ab to verify 5000 orders per day.

Typical Mistakes in Bitrix Marketplace Development

• Storing suppliers in a regular infoblock — causes slowdowns with >1000 records. Use highload infoblocks.
• Splitting orders after saving — breaks the status model. Split at the cart stage.
• Manual fiscalization of each sub-order — violates 54-FZ. Fiscalize with a single receipt with agent attribute.
• Ignoring tagged caching for the catalog — with multivendor, cache is invalidated entirely. Configure tags by vendor_id.

Technology Stack

• 1C-Bitrix 'Business' or 'Enterprise' — sale + catalog modules as foundation. Multivendor wrapper — custom modules.
• Highload infoblocks — catalogs over 100,000 SKU. Regular infoblocks at such volumes fail on filtering: CIBlockElement::GetList with a dozen properties generates JOINs on dozens of b_iblock_element_prop_sNN tables. Highload solves this with a flat structure.
• Elasticsearch — full-text search. Elasticsearch processes queries 10 times faster than the built-in search module (Sphinx). User types 'nike sneakers' — finds 'Nike sneakers'.
• Queues — catalog import, payout calculation, report generation. Bitrix agents (CAgent) for light tasks, separate queue via RabbitMQ or supervisor + custom CLI for heavy tasks.

We guarantee that the developed module will handle a load of up to 5000 orders per day on a standard VPS. Certified 1C-Bitrix specialists (over 10 years of experience, 50+ completed projects) perform architecture audit before development starts. At a scale of 2000 sellers, average moderation time is 15 minutes, and 95% of orders are processed automatically.

Industry Marketplaces

Each niche has its own pitfalls:

• Building materials — oversized delivery calculation. Pallets, tonnage, floor lift. Standard delivery calculator cannot handle it; we write custom sale.delivery.handler.
• Food products — expiration dates in infoblock properties, temperature regime, same-day delivery slots. A logistics error means write-off.
• Auto parts — VIN selection via Laximo API, cross-references, originals and analogs. A separate headache is different delivery times from different sellers for the same part.
• Clothing — size charts (EU/US/RU), high return rate. Return processing logic with commission redistribution is a whole layer.
• Industrial equipment — B2B with tenders, quotation requests. Product card with 50+ parameters in table form.

Timelines and Stages

Trying to launch everything at once is a sure way to launch nothing.

MVP in 3-4 months. Full-featured platform — 6-12 months of iterative development.

What Is Included

• Documentation: architecture diagram, API description, seller instructions.
• Access: code repository, test environment, admin panel.
• Training: two sessions for administrators and managers.
• Support: 1 month free support after launch, then according to SLA.
• Warranty on developed modules — 12 months.

Contact us for an assessment of your project — we will calculate timelines and cost individually. Request a consultation, and we will show on a real case how we solve the multivendor problem in 30 minutes. Get a detailed development plan for your marketplace today.