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.

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.

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

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.

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.