1C-Bitrix and Wildberries Integration for Belarus

What Data Is Synchronized During Integration?

Wildberries uses a unified Marketplace API for Russia and Belarus, so Belarusian sellers do not need separate technical solutions. For an online store on 1C-Bitrix, integration includes two-way exchange: the product catalog (cards, prices, stock) is sent to WB, and orders from WB come back for processing. Without automation, this process becomes daily manual work — according to our estimates, about 50% of stock errors occur precisely during manual entry. We configure the full cycle: from card upload to label printing. Automatic synchronization via API is 30 times faster than manual data entry — everyone who switched to automation feels the difference. Typical integration costs range from $1,000 to $5,000 depending on catalog size, with monthly savings of up to $500 in manual labor.

How Does Stock Synchronization Work on Wildberries?

Uploading products to WB is not just about transferring name and price. Each card must contain item characteristics (in WB terminology) according to the category schema. For jeans — composition, gender, size grid; for smartphones — diagonal, memory, color. WB does not accept products with empty required characteristics. For the first upload you need to:

1. Obtain the characteristic schema via GET /content/v2/object/charcs/{subjectId}
2. Map WB characteristics to Bitrix infoblock properties
3. Normalize values: WB requires values from a reference (e.g., colors strictly from WB dictionary, not arbitrary strings)

Mapping WB characteristics ↔ Bitrix properties is the most painstaking part. For a catalog with 10 items (jeans, t-shirts, jackets…) this means 10 mapping tables. According to our measurements, each category takes about 8–12 hours of analyst work. Time savings after automation reach up to 80%.

Stock on WB is updated via POST /api/v3/warehouses/{warehouseId}/stocks. For Belarusian sellers, the warehouse can be either self-owned (FBS — fulfillment by seller) or WB warehouse (FBO). With FBS, we update stock from Bitrix; with FBO, stock is already on WB side, and synchronization is only needed for control. WB uses barcodes to identify SKUs when updating stock. The barcode is assigned during card creation. We store the mapping WB_barcode → Bitrix_offer_id in a separate table. Updating stock for all SKUs every 15–30 minutes is standard practice. WB limits: no more than 1000 positions per request. Therefore, for catalogs over 10,000 SKUs, batch splitting is required. Average processing time per request is 2–3 seconds. This reduces stock errors by 95% compared to manual entry.

How Are Orders Processed from Wildberries?

GET /api/v3/orders/new returns new orders in the "Awaiting assembly" status. For each order:

1. Find the corresponding product in Bitrix by barcode
2. Create an order in b_sale_order via \Bitrix\Sale\Order::create()
3. Attach WB metadata to the order: WB order ID, supply ID, delivery date

After assembly, we transmit the supply ID and labeling to WB. WB generates labels — we print them. The method GET /api/v3/orders/{orderId}/label returns a PDF label. The entire process from order receipt to label printing takes no more than 5 minutes in automatic mode — manually it takes up to 15 minutes.

Integration Specifics for Belarus

From the API perspective, there is no difference between Russia and Belarus — the same API, the same seller panel. Operational differences:

• Logistics: shipment goes to WB warehouses in Russia (Moscow, Podolsk) via transport companies or own transport
• VAT: Belarusian sellers operate under Belarusian legislation but sell to Russian buyers — tax nuances should be clarified with an accountant
• Settlements: WB transfers revenue in Belarusian rubles to an account in Belarus or in Russian rubles — depends on the contract

These specifics do not affect the technical implementation but require attention during the planning stage.

What's Included in the Service

A typical integration project includes:

• Audit of the current catalog and barcodes
• Preparation of characteristic mapping scheme
• Development of a synchronization module (REST client and agents)
• Setting up automatic stock updates and order import
• Testing on live data and staff training
• Documentation on the algorithm
• Support for 30 days after launch

We guarantee that integration will not lead to order duplication or stock loss. Our engineers have 10+ years of experience in Bitrix and over 50 marketplace integrations. Request a consultation and get a preliminary estimate of integration cost. Contact us – we will offer an optimal plan for your project.

Time Estimates

Cost is calculated individually. For an estimate, we need: list of catalog items, current state of barcode and characteristic data, logistics scheme (FBS/FBO). Get a personal estimate – leave a request.

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 via label/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?

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():

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_PROP property.
• 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_log with 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

1. 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.
2. Strategy — priority platforms, model (FBO/FBS/DBS), integration depth.
3. Module development — mapping, validation, error handling. Cover critical scenarios with unit tests: order splitting, stock recalculation on partial cancellation.
4. Testing — upload test products, simulate orders via platform sandbox APIs, edge cases (zero stock, product without photo, price below minimum).
5. Launch — sequentially launch integrations, monitor first exchanges in real time.
6. 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.