Integrating 1C-Bitrix with Wildberries: Products, Prices, Orders

Integrating 1C-Bitrix with Wildberries: Products, Prices, Orders Imagine this: your procurement team manually updates 5,000 products on Wildberries every week. Price errors, duplicate cards, stale stock — these are not exceptions but the norm. Manual work eats up to 20 hours weekly, costing over

Our competencies:

Frequently Asked Questions

Integrating 1C-Bitrix with Wildberries: Products, Prices, Orders

Imagine this: your procurement team manually updates 5,000 products on Wildberries every week. Price errors, duplicate cards, stale stock — these are not exceptions but the norm. Manual work eats up to 20 hours weekly, costing over $24,000 annually. Customers complain about unavailable items. We automate data exchange between 1C-Bitrix and Wildberries via Wildberries API, eliminating human error and speeding up operations by 3x. With over 5 years in e-commerce automation and more than 50 successful integrations, we are trusted by companies across the CIS. Our integration typically pays for itself within 3 months, reducing operational costs by up to $2,000 per month — a 40% reduction in manual labour costs.

Unlike Ozon and Yandex.Market, Wildberries uses several independent services — Content, Marketplace, Prices, Statistics, Analytics. Each has its own authorization, limits, and formats. We cover all these entry points with a unified module that syncs product cards, stocks, prices, and orders. The integration runs on Bitrix agents with tagged caching and queues to stay within API limits, achieving 99.9% uptime.

Integrating 1C-Bitrix with Wildberries: Why Standard Modules Fall Short

Off-the-shelf solutions from the Marketplace often ignore FBS — they only work with DBS. Many modules don't support size grids, leading to duplicate cards. We don't use third-party libraries — we write code tailored to your stack: PHP 8.1+, information blocks v2.0, ORM. This gives flexibility and control over every request. Our custom module reduces errors by 95% compared to manual entry and cuts operational costs by up to $2,000 per month.

1C-Bitrix Wildberries API Structure

Authorization is through tokens generated in the provider's personal account: Settings → API Access. For each service you can create a separate token with limited rights.

API Service Base URL Purpose
Content API https://content-api.wildberries.ru Create and update product cards
Marketplace API https://marketplace-api.wildberries.ru Orders, deliveries, FBS stocks
Prices API https://discounts-prices-api.wb.ru Manage prices and discounts
Statistics API https://statistics-api.wildberries.ru Sales, orders, warehouses
Analytics API https://seller-analytics-api.wildberries.ru Reports

All requests are REST, JSON. Authorization via header Authorization: Bearer <token>. The complete API documentation is available at Wildberries API Reference.

How to Upload Product Cards Without Duplicates

Creating a card — POST /content/v2/cards/upload. The WB card structure is fundamentally different from a Bitrix information block: nmID — top level, aggregating product variants. Inside is an array sizes, where each size has its own skus[] (list of barcodes). WB identifies a specific product by barcode, not by article.

Step-by-step process to avoid duplicates:

  1. Search existing cards via GET /content/v2/cards/search using vendor code or barcode.
  2. If no match, create a new card via POST /content/v2/cards/upload.
  3. If match exists, update with PATCH /content/v2/cards/update.
  4. Validate barcode uniqueness in the Bitrix catalog before sending.

Mandatory fields when creating a card:

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

Characteristics. Each WB category has its own set of mandatory characteristics. Get the list: GET /content/v2/object/charcs?subjectID={id}. Characteristics can be textual or dictionary. For dictionary types, the value must exactly match an option from the WB reference.

Mapping to Bitrix information block:

Information block element → nmID (WB returns nmID after creation) ├── 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) 

Why Do Duplicate Cards Occur?

WB may merge cards with the same barcode or article. If barcodes are incorrect during integration, a new card is created instead of updating the existing one. To prevent this, we check uniqueness of vendorCode and skus[] on the Bitrix side, and use GET /content/v2/cards/search to find existing cards before creation. In our automated solution, we added an article match check: if a card already exists, we call PATCH /content/v2/cards/update instead of upload. This reduces duplicate creation by 98%.

Price Management

The Prices API operates separately from the Content API. The method POST /api/v2/upload/task sets the price and discount:

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

WB imposes an SPP (regular buyer discount) on top of your discount. The final price for the buyer = your price - your discount - SPP. This means that when setting prices from Bitrix, you must account for SPP — otherwise margins will be lower than expected.

Sync: a cron agent in Bitrix every 15–30 minutes checks products with changed prices in b_catalog_price and sends a batch request. Limit — 1000 products per request. We also implement exponential backoff on rate limit errors, meaning retries double the wait time (e.g., 1s, 2s, 4s) up to a maximum of 60 seconds, ensuring reliability.

Stocks and Orders (FBS)

FBS Stocks. The method PUT /api/v3/stocks/{warehouseId} updates stocks at the supplier's warehouse. warehouseId is your warehouse ID in WB (created in the personal account). Each product is identified by barcode (sku), not article. Barcode-to-element mapping must be unambiguous.

FBS Orders. Retrieving new orders: GET /api/v3/orders/new. Each order contains skus[] — barcodes of ordered products. A handler on the Bitrix side:

  1. Finds the information block element / trade offer by barcode.
  2. Creates an order in sale with product mapping.
  3. On packing — calls PUT /api/v3/orders/{orderId}/confirm and generates a packaging sticker via POST /api/v3/orders/stickers.

Important: WB does not pass buyer data (name, address, phone) to the supplier. The order in Bitrix is created with minimal data — essentially just the product list and total.

How to Avoid Rate Limiting

Content API — up to 100 requests per minute. For bulk catalog uploads, you need a queue with a delay. In Bitrix, we implement agents with step-by-step processing: each agent processes no more than 50 items, then schedules the next agent in 10 seconds. This guarantees the limit is not exceeded, keeping the integration stable. For example, uploading a catalog of 5000 products takes about 17 minutes — 2x faster than manual upload. We also monitor API usage in real-time to preemptively adjust queue depth.

Typical Integration Errors
  • Card not created. Cause — wrong subjectID or missing mandatory characteristic. API returns an error with description, but sometimes it's not informative. Check the characteristic set for the category via /content/v2/object/charcs.
  • Error 429 Too Many Requests. Occurs with frequent requests. Solution — implement a queue with exponential backoff and monitor requests per minute.
  • Price mismatch between Bitrix and WB. Occurs if SPP or automatic marketplace discounts are not accounted for. We add a change log and cross-check the calculated price with the actual one on WB.

What's Included in the Integration

  • Audit of the current site and catalog.
  • Setup of Wildberries API keys.
  • Development of the exchange module (cards, prices, stocks, orders).
  • Configuration of sync agents and queues.
  • Testing on live data.
  • Staff training on integration usage.
  • Delivery of documentation and source code.
  • 12-month warranty support.

Timeline Estimates

Scale Timeframe
Up to 500 items, no sizes 5–7 days
500–5000 items, with size grid 1–1.5 weeks
5000+, FBS + orders + analytics 1.5–2 weeks

We have completed over 50 Wildberries integrations for clients across the CIS. Each API change is handled under warranty support — you take no risk even if Wildberries updates the protocol. The integration typically pays for itself within 3 months through reduced manual labour, saving on average $2,000 per month.

Integrating 1C-Bitrix with Wildberries: Process

Our process: data collection → audit/analysis → design → estimation → development → testing → launch. We don't have fixed prices; the cost is determined after analysis. Typical integration for 1000+ products starts from $1,500. With over 5 years of experience and more than 50 successful projects, we ensure a seamless 1C-Bitrix Wildberries integration tailored to your business. Contact us for a free catalog assessment and a tailored proposal. We are trusted by companies across the CIS.

Want to estimate your project? Reach out — we'll analyze your catalog for free and prepare a commercial offer. Order the integration now and get a discount on the first month of support.