1C-Bitrix Marketplace Integration
A manager manually updates stock on Ozon while Wildberries sells a product that is not in stock. The customer gets a cancellation, the rating drops, and the platform reduces exposure. We solve this with automatic synchronization via API: orders fall into Bitrix, stock and prices update from a single admin panel. Our experience — 60+ projects integrating with Ozon, WB, Yandex.Market. We guarantee that after setup, no product will go negative.
According to Wikipedia, marketplaces account for more than half of online retail in Russia. Products with correct stock get twice as many impressions. Without automation, you either lose sales due to overselling or spend hours on manual updates. We offer turnkey integration — from catalog audit to monitoring. We confirm stability with SLA: response time to failure — 2 hours during business hours. We use tagged caching and Bitrix agents to keep server load low. Labor savings after integration — up to 40 hours per month, which at a manager's rate gives significant savings.
Why Connect Marketplaces?
Marketplaces are ready-made traffic that a single online store cannot gather. More than half of online purchases go through platforms. You only need assortment and prices.
- Sales channels — millions of buyers with a card in hand.
- Unified management — products, stock, orders from all channels in Bitrix. No manual entry.
- End-to-end analytics — margin by each channel. Decisions based on numbers, not intuition.
How Does Stock Synchronization with Wildberries Work?
WB's supplier API requires updating stocks on warehouses every 15–30 minutes. Otherwise, stock diverges from the site, and the buyer orders a non-existent product. We configure a Bitrix agent: CAgent::AddAgent() with a 15-minute interval that calls /api/v3/stocks. Data is taken from the trade catalog taking into account reserves.
Typical mistake: in Bitrix stock is 10 units, on WB it is set to 10, but 3 are already reserved in WB orders. Our module subtracts the reserve before sending. Result: after integration, there are no discrepancies, and the seller's rating grows. Losses from overselling on a catalog of 5,000 SKUs average significant monthly savings — integration pays for itself in 3–4 weeks.
Which Marketplaces Do We Connect?
- Ozon — Seller API v3. Card creation (
/v3/product/import), price updates (/v1/product/import/prices), stock (/v2/products/stocks), FBO/FBS orders (/v3/posting/fbs/list), returns. We configure automatic barcode and label generation vialabel/task. - Wildberries — Supplier API. Upload nomenclature with characteristics by categories (
/content/v2/cards/upload), barcodes, stock synchronization on WB warehouses (/api/v3/stocks), order and supply processing, media content. - Yandex.Market — Partner API. Catalog via feed or push model, prices, stock, DBS/FBS/FBY orders (
/campaigns/{campaignId}/orders), integration with Yandex.Delivery. - Other platforms — SberMegaMarket, AliExpress Russia, Avito, industry platforms (Lamoda, Leroy Merlin). We also provide custom integration for niche marketplaces.
Why Direct API Integration Wins Over Aggregators
Direct API integration is the most reliable path. We develop a custom Bitrix module that directly calls the platform's endpoints. Full control: if the marketplace breaks backward compatibility (and WB does that regularly) — we update the module ourselves, not waiting for a third party. Each request is logged in b_event_log, retries on 429/500 are automatic.
Aggregators like RetailCRM, MySklad, ApiShip offer quick start, but they act as a black box: when something breaks, debugging through a third-party layer is difficult. Suitable for limited budgets, but on highload catalogs (10,000+ SKUs) direct API work is three times cheaper in long-term support than monthly aggregator fees plus lost revenue from downtime. Feeds (YML/XML) are an alternative for catalog export, generated via catalog.export module or a custom handler on CIBlockXMLFile.
How Long Does a Typical Integration Take?
| Task | Timeframe |
|---|---|
| Integration with one marketplace (basic) | 2–4 weeks |
| Integration with one marketplace (advanced) | 4–6 weeks |
| Multi-channel (3+ platforms) | 6–12 weeks |
| Feed generation (YML, XML) | 3–5 days |
| Monitoring and analytics | 1–2 weeks |
Specific timeframes depend on catalog size, number of platforms, mapping complexity, and state of 1C exchange. Detailed estimate after audit. Contact us to evaluate your project — we will give a reliable timeline.
Product Upload and Synchronization
Upload is not just "pressing a button." It involves serious preparatory work.
- Category mapping — matching Bitrix infoblock sections with the platform's category tree. Ozon has its own taxonomy (
/v1/description-category/tree), WB has its own. Required attributes differ. - Property mapping — infoblock properties (
PROPERTY_*) → marketplace characteristics. Unit conversion, formats — automatically via a matching table in a highload infoblock. - Card enrichment — rich content for Ozon, video reviews for WB, 360 photos. Platforms rank by completeness: the difference between a bare and a well-developed card is twofold in sales.
- Images — automatic generation in required resolutions via
CFile::ResizeImageGet().
Synchronization — scheduled via agents CAgent::AddAgent():
| Data | Frequency | Direction |
|---|---|---|
| Stock | 15–30 min | Bitrix → Marketplace |
| Prices | 30–60 min | Bitrix → Marketplace |
| Orders | 5–10 min | Marketplace → Bitrix |
| Statuses | Real-time (webhook) | Two-way |
| Cards | On change | Bitrix → Marketplace |
What Happens When the Marketplace Changes Its API?
Marketplaces regularly update APIs, often breaking backward compatibility. Direct integration gives you control: we update the module on the day of change. Typical response time to a failure in integration through an aggregator is from 24 hours, ours is 2 hours. Savings on lost orders per month can be substantial. For example, a 3‑hour downtime on WB for a catalog with 500 orders/day costs approximately $1,500 in lost revenue — direct integration reduces this risk to minutes.
Order Processing
Orders from platforms fall into b_sale_order automatically and are processed in a single stream.
- Creation — the order arrives with all details. The module parses the API response, creates an order via
\Bitrix\Sale\Order::create(), assigns it to the marketplace's payer type and payment system. - Single stream — managers work with orders from all channels in one interface. The order source is visible in the
ORDER_PROPproperty. - Status synchronization — collected, shipped, delivered — the status updates on the marketplace via callback. Handler
OnSaleStatusOrder. - Returns — cancellation on the marketplace creates a return in Bitrix. Stock is automatically returned to warehouse.
- Transfer to 1C — orders go to 1C:Enterprise via standard CommerceML exchange. One source of truth.
Monitoring and Stability
Multi-channel trading without monitoring is chaos. We monitor each channel.
- Stock control — alerts for discrepancies between Bitrix, marketplace, and 1C. Product with zero stock is automatically blocked — you cannot sell what you don't have. Check via cron every 10 minutes.
- Logging and retries — each API request is logged in
b_event_logwith request and response body. Failure? Automatic retry with exponential backoff. Critical error? Notification to admin's Telegram bot. - Pricing — automatic calculation considering platform commissions, logistics, and target margin. Formula in module settings:
price = base_price / (1 - commission) + logistics. - Analytics — dashboard: revenue, orders, average check, returns, margin by each marketplace separately. Updates once per hour.
Integration Approach and Scope of Work
- Audit — review Bitrix catalog, infoblock structure, existing exchanges with 1C. Determine data readiness. Sometimes 80% of the work is putting cards in order: filling required properties, unifying units of measurement.
- Strategy — priority platforms, model (FBO/FBS/DBS), integration depth.
- Module development — mapping, validation, error handling. Cover critical scenarios with unit tests: order splitting, stock recalculation on partial cancellation.
- Testing — upload test products, simulate orders via platform sandbox APIs, edge cases (zero stock, product without photo, price below minimum).
- Launch — sequentially launch integrations, monitor first exchanges in real time.
- Support — platforms regularly update APIs (WB without warning). We adapt promptly.
The work includes:
- Audit of current catalog, infoblocks, and 1C exchange — documentation with recommendations.
- Development of integration module (for each marketplace) with source code.
- Configuration of category and property mapping.
- Setup of agents and webhooks.
- Testing in sandbox and on real data.
- Training managers to work with a unified order flow.
- Monitoring for the first two weeks after launch.
- Technical support and updates when platform APIs change.
Get your catalog audited — we will evaluate your project and propose a tailored integration solution. Contact us for a free consultation and cost estimate.







