1C-Bitrix to Ozon (Marketplace) Integration

Ozon does not work via product feeds. Unlike Yandex.Market, where the main channel is a YML file, Ozon requires product upload via the Seller API. This involves POST requests with JSON body, a strict category-based attribute system, and mandatory linking to Ozon product cards. Without API integration, managing a catalog from 1C-Bitrix is impossible — manual filling through the personal cabinet is unviable for more than 50 products. Our experience: 10+ years of Bitrix marketplace integrations, including 50+ projects for Ozon, from small shops to catalogs of 50,000+ SKUs. We guarantee a turnkey, correct exchange. Typical integration cost ranges from $500 to $2000 depending on complexity.

How to Set Up Ozon Attribute Mapping in Bitrix?

The key complexity of Ozon is its category-based attribute system. Each category (category_id) has its own set of mandatory and optional attributes. They can be retrieved via /v1/description-category/attribute. Mapping is built according to the table:

Reference values

Many attributes are not free text but a selection from Ozon's reference. Brand "Samsung" is a specific option_value_id that must be found via /v1/description-category/attribute/values. When mapping Bitrix properties to Ozon attributes, a correspondence table must be created: infoblock property value → Ozon option_value_id.

Linking to product cards

Ozon combines identical products from different sellers into one card. Linking is done by barcode (EAN), manufacturer's article, or via manual moderation. If the product already exists in Ozon's database, your offer will be linked to the existing card. If not, a new one is created and passes moderation (1–3 days).

Data Mapping: Infoblock → Ozon API

A typical mapping scheme for the integration module:

Infoblock "Catalog" (iblock_id = N) ├── NAME → attribute_id 4180 (Name) ├── PROPERTY_BRAND → attribute_id 85 (Brand, reference) ├── PROPERTY_ARTICLE → offer_id (seller's article) ├── PROPERTY_BARCODE → barcode ├── DETAIL_TEXT → description (up to 6000 characters) └── DETAIL_PICTURE → images[] (up to 15 photos, min 200×200) SKU Infoblock (iblock_id = M) ├── PROPERTY_COLOR → attribute_id 10096 (Color, reference) ├── PROPERTY_SIZE → attribute_id (size, depends on category) └── Catalog price → price / old_price 

Mapping is stored in the integration module settings (if using a ready module from Marketplace) or in the configuration file of a custom solution. Our engineers develop customization for your structure. According to Ozon Seller API, when uploading products, all mandatory attributes must be transmitted.

Price and Stock Synchronization

Prices. Ozon works with two prices: price (selling price) and old_price (strikethrough). The difference must be at least 5% — otherwise Ozon won't show the discount. Update via /v1/product/import/prices, limit 1000 products per request. In Bitrix, prices are stored in the b_catalog_price table. For Ozon integration, a separate price type (e.g., "Ozon Price") is allocated, or the main retail price is used. The synchronization agent runs via cron every 15–30 minutes, selects products with changed price (TIMESTAMP_X) and sends a batch request.

Stocks. Method /v2/products/stocks. Critical for FBS — if the stock on Ozon > 0 but there is no product in the warehouse, you'll receive a fine for order cancellation. Stock synchronization should be as frequent as possible: every 5–15 minutes for fast-moving goods. For multi-warehousing, Ozon supports transmitting stocks by warehouse (warehouse_id). Each Ozon warehouse is mapped to a warehouse in Bitrix (if warehouse accounting via the catalog module is used).

Order Processing

FBS orders are fetched via /v1/posting/fbs/list with filter status = awaiting_packaging. The handler:

1. Retrieves a list of new orders.
2. Creates an order in Bitrix via Bitrix\Sale\Order::create() with field mapping: items, quantity, address (if available), total.
3. Upon order assembly and handover to delivery — calls /v1/posting/fbs/ship with posting_number and tracking number.

Ozon order statuses → Bitrix:

Why Is It Important to Sync Stocks Every 5 Minutes?

Stock discrepancy is the main cause of Ozon fines. If an order is created on Ozon but the sync agent hasn't fetched it yet — the stock in Bitrix hasn't decreased. The next stock request will send outdated data. Solution: upon receiving an order from Ozon, first reserve the stock in Bitrix, then synchronize. Our integration works 2 times faster than standard Marketplace modules due to async agents and batch processing.

Typical Issues

Product fails moderation. Reason #1 — incorrect attribute mapping. Check via /v1/product/info/list the field status_description. A common mistake: brand transmitted as text instead of option_value_id.

Rate limiting. Ozon API limits requests: ~60 requests per minute for most methods. For catalogs of 10,000+ products, price updates must be split into batches with delays.

What's Included

• Documentation on attribute mapping and data structure.
• Configuration of cron agents with required frequency.
• Testing of initial product upload and order processing.
• Employee training on working with the integration.
• 6-month guarantee for uninterrupted exchange operation.

Timeframes

The cost is calculated individually. Contact us for a free evaluation of your project. Get a consultation on integration timelines and costs.

All references to API methods are from the official Ozon Seller API documentation.