1C-Bitrix Integration with Wildberries Belarus

1C-Bitrix Integration with Wildberries Belarus

Wildberries operates in the Belarusian market using the same technical interfaces as in Russia: a unified Marketplace API and a single seller dashboard. For a store built on 1C-Bitrix, integration means two-way synchronisation: the product catalog and stock levels are pushed to WB, while orders from WB are pulled into 1C-Bitrix for processing. Without automation, this becomes daily manual work with a high risk of errors.

Wildberries API: What We Use

The WB API is available at https://suppliers-api.wildberries.ru/. Authentication is via an API key in the Authorization: {token} header. Keys are created in the seller dashboard; each key is scoped to a defined set of permissions.

Key endpoints for 1C-Bitrix integration:

• POST /content/v2/cards/upload — upload product cards
• POST /api/v3/warehouses/{warehouseId}/stocks — update stock levels
• GET /api/v3/orders/new — retrieve new orders
• POST /api/v3/orders/status — update order statuses
• GET /api/v3/supplies/{supplyId}/barcode — supply barcode for labelling

Product Cards: The Most Labour-Intensive Part

Uploading products to WB is not simply passing a name and a price. Each card must include subject characteristics (in WB terminology) that conform to the category schema. For jeans: composition, gender, size chart; for smartphones: screen diagonal, storage capacity, colour.

WB rejects products with empty required characteristics. For the initial upload:

1. Retrieve the characteristics schema via GET /content/v2/object/charcs/{subjectId}
2. Map WB characteristics to 1C-Bitrix infoblock properties
3. Normalise values: WB requires values from its own reference dictionaries (e.g. colours must come from the WB dictionary, not arbitrary strings)

Mapping WB characteristics ↔ 1C-Bitrix properties is the most painstaking part. For a catalog spanning 10 subjects (jeans, T-shirts, jackets…) this means 10 separate mapping tables.

Stock Synchronisation

Stocks on WB are updated via POST /api/v3/warehouses/{warehouseId}/stocks. For Belarusian sellers, the warehouse may be either seller-owned (FBS — fulfilment by seller) or a WB warehouse (FBO). Under FBS, stock is pushed from 1C-Bitrix; under FBO, stock is managed on the WB side.

WB uses barcodes to identify SKUs when updating stock. The barcode is assigned when the product card is created. We maintain a WB_barcode → 1C-Bitrix_offer_id mapping table.

Updating stock across all SKUs every 15–30 minutes is standard practice. WB imposes a limit of no more than 1,000 items per request.

Receiving and Processing Orders

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

1. Look up the corresponding product in 1C-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 submit the supply ID (supply) and labelling to WB. WB generates labels — these must be printed. The method GET /api/v3/orders/{orderId}/label returns a PDF label.

Belarus-Specific Considerations

From an API perspective, there is no difference between Russia and Belarus — same API, same dashboard. Operational differences:

• Logistics: shipments go to WB warehouses in Russia (Moscow, Podolsk) via freight companies or own transport
• VAT: Belarusian sellers operate under Belarusian law but sell to Russian buyers — tax nuances should be verified with an accountant
• Settlements: WB transfers revenue in Belarusian rubles to a BLR bank account, or in Russian rubles — depending on the contract

Estimated Timelines

Pricing is calculated individually. Required for estimation: catalog subject list, current state of barcode and characteristics data, logistics scheme (FBS/FBO).