Integration of 1C-Bitrix with Wildberries

1C-Bitrix Integration with Wildberries

Wildberries is closed ecosystem with non-standard API. Unlike Ozon and Yandex.Market, there's no single Seller API with clear documentation. API is split into several independent services (Content API, Marketplace API, Statistics API, Prices API), each with its own authorization, limits, and data formats. Integration with 1C-Bitrix requires work with each service separately.

Wildberries API Structure

Authorization — via tokens generated in supplier's personal account: Settings → API Access. For each service, separate token can be created with limited rights.

All requests — REST, JSON. Authorization via Authorization: Bearer <token> header.

Product Card Upload: Content API

Card creation — POST /content/v2/cards/upload. WB card structure fundamentally differs from Bitrix infoblock:

Nomenclature (nmID) — top level combining product variants. Inside — sizes array, where each size has its skus[] (barcode list). WB identifies specific product by barcode, not article.

Mandatory fields when creating card:

• vendorCode — supplier article. In Bitrix — property ARTICLE or ARTNUMBER.
• brand — brand. Must match registered in WB.
• title — title. WB generates automatically from category + brand + characteristics. Manual title may be rejected.
• description — up to 5000 characters.
• subjectID — WB category ID. Obtained via GET /content/v2/object/all.
• characteristics — array of characteristics, depending on category.
• sizes[].skus[] — barcodes for each size.

Characteristics (characteristics). Each WB category has its own set of mandatory characteristics. Get list: GET /content/v2/object/charcs?subjectID={id}. Characteristics are text and reference. For reference — value must exactly match option from WB directory.

Mapping to Bitrix infoblock:

Infoblock element → nmID (after creation WB returns nmID)
  ├── NAME → title (but WB may override)
  ├── PROPERTY_ARTICLE → vendorCode
  ├── PROPERTY_BRAND → brand
  ├── DETAIL_TEXT → description
  ├── PROPERTY_COLOR → characteristics[{id: N}]
  └── DETAIL_PICTURE + PROPERTY_PHOTOS → mediaFiles[]

Trade offers → sizes[]
  ├── PROPERTY_SIZE → techSize
  ├── PROPERTY_BARCODE → skus[]
  └── Price → (via Prices API separately)

Photo Upload

Photos uploaded via separate request: POST /content/v2/cards/upload/add for binding media files to card. WB accepts photos by URL — specify array of image links from your server. Requirements: minimum 900×1200 px, JPG/PNG format, white background for most categories.

In Bitrix images stored in /upload/iblock/. URL formed as https://your-domain.ru/upload/iblock/xxx/photo.jpg. Ensure files accessible by direct URL without authorization.

Price Management

Prices API works separately from Content API. Method POST /api/v2/upload/task sets price and discount:

• price — price before discount (retail).
• discount — discount percentage. Final price = price * (1 - discount/100).

WB imposes SPP (loyalty discount) on top of your discount. Final price for buyer = your price - your discount - SPP. This means when setting price from Bitrix you need account for SPP — otherwise margin lower than expected.

Sync: cron agent in Bitrix every 15–30 minutes checks products with changed price in b_catalog_price and sends batch request. Limit — 1000 products per request.

Inventory and Orders (FBS)

FBS Inventory. Method PUT /api/v3/stocks/{warehouseId} updates inventory on supplier's warehouse. warehouseId — your warehouse ID in WB (created in personal account). Each product identified by barcode (sku), not article. Barcode → infoblock element mapping must be one-to-one.

FBS Orders. Get new orders: GET /api/v3/orders/new. Each order contains skus[] — barcodes of ordered products. Bitrix handler:

1. By barcode finds infoblock element / trade offer.
2. Creates order in sale with product mapping.
3. When packing — calls PUT /api/v3/orders/{orderId}/confirm and forms sticker for packaging via POST /api/v3/orders/stickers.

Important: WB doesn't transmit buyer data (name, address, phone) to supplier. Order in Bitrix created with minimal data — essentially just product list and amount.

Typical Problems

Card not created. Reason — incorrect subjectID or missing mandatory characteristic. API returns error with description, but sometimes unhelpful. Check characteristics set for category via /content/v2/object/charcs.

Card duplicates. WB may merge cards with identical barcode or article. If during integration barcodes incorrect — instead of updating existing card, new one created.

Rate limiting. Content API — up to 100 requests per minute. With bulk catalog upload, need queue with delay. In Bitrix implemented via agents with step-by-step processing.