1C-Bitrix integration with Ozon (marketplace)

1C-Bitrix Integration with Ozon (Marketplace)

Ozon doesn't work through product feeds. Unlike Yandex.Market, where main channel is YML file, Ozon requires product upload through Seller API. These are POST requests with JSON body, strict attribute system by categories, and mandatory binding to Ozon cards. Without API integration, managing catalog from 1C-Bitrix is impossible — manual entry through personal account with 50+ products is not viable.

Integration Architecture

Ozon Seller API (https://api-seller.ozon.ru/) — REST API with authorization via Client-Id and Api-Key. Keys are created in seller's personal account: Settings → API keys.

Main method groups:

• /v3/product/import — product upload and update
• /v2/product/info/list — get product information
• /v1/product/import/prices — update prices
• /v2/products/stocks — update inventory
• /v1/posting/fbs/list — order list FBS
• /v1/posting/fbs/ship — shipment confirmation

Integration is built on Bitrix side as set of cron agents or event handlers that send requests to Ozon API and receive responses.

Product Upload: Ozon Attribute System

Key complexity of Ozon — categorical attribute system. Each category (category_id) has its own set of mandatory and optional attributes. Get them via /v1/description-category/attribute.

Example for "Smartphones" category:

Reference values. Many attributes — not free text, but selection from Ozon directory. Brand "Samsung" is specific option_value_id, which needs to be found via /v1/description-category/attribute/values. When mapping Bitrix properties to Ozon attributes, create correspondence table: infoblock property value → Ozon option_value_id.

Card binding. Ozon merges identical products from different sellers into one card. Binding happens by barcode (EAN), manufacturer's article, or manual moderation. If product already exists in Ozon base, your offer binds to existing card. If not — new card is created, which undergoes moderation (1–3 days).

Data Mapping: Infoblock → Ozon API

Typical mapping scheme for integration module:

Infoblock "Catalog" (iblock_id = N)
  ├── NAME → attribute_id 4180 (Title)
  ├── PROPERTY_BRAND → attribute_id 85 (Brand, directory)
  ├── PROPERTY_ARTICLE → offer_id (seller's article)
  ├── PROPERTY_BARCODE → barcode
  ├── DETAIL_TEXT → description (up to 6000 characters)
  └── DETAIL_PICTURE → images[] (up to 15 photos, minimum 200×200)

Infoblock TO (iblock_id = M)
  ├── PROPERTY_COLOR → attribute_id 10096 (Color, directory)
  ├── PROPERTY_SIZE → attribute_id (size, depends on category)
  └── Catalog price → price / old_price

Mapping is stored in integration module settings (if using ready module from Marketplace) or in configuration file of custom solution.

Price and Inventory Synchronization

Prices. Ozon works with two prices: price (selling price) and old_price (strikethrough). Difference must be at least 5% — otherwise Ozon won't show discount. Update via /v1/product/import/prices, limit — 1000 products per request.

In Bitrix, prices are stored in b_catalog_price table. For Ozon integration, separate price type is allocated (e.g., "Ozon Price") or main retail is used. Sync agent runs via cron every 15–30 minutes, selects products with changed price (TIMESTAMP_X), sends batch request.

Inventory. Method /v2/products/stocks. Critical for FBS — if Ozon inventory > 0 but warehouse has no product, you get penalty for order cancellation. Inventory sync should be maximum frequent: every 5–15 minutes for fast-moving products.

For multi-warehouse, Ozon supports inventory transmission by warehouses (warehouse_id). Each Ozon warehouse maps to warehouse in Bitrix (if using warehouse accounting of catalog module).

Order Processing

FBS orders retrieved via /v1/posting/fbs/list with filter status = awaiting_packaging. Handler:

1. Gets list of new orders.
2. Creates order in Bitrix via Bitrix\Sale\Order::create() with field mapping: products, quantity, address (if available), amount.
3. When order is packed and sent to delivery — calls /v1/posting/fbs/ship with posting_number and tracking number.

Ozon order statuses → Bitrix:

Typical Problems

Product didn't pass moderation. Reason #1 — incorrect attribute mapping. Check via /v1/product/info/list field status_description. Common mistake — brand sent as text, not option_value_id.

Rate limiting. Ozon API limits request number: ~60 requests per minute for most methods. With 10,000+ product catalog, price update must be split into batches with delay.

Inventory mismatch. If order created on Ozon but sync agent hasn't fetched it yet — inventory in Bitrix hasn't decreased. Next inventory request sends stale data. Solution: when receiving order from Ozon, first reserve inventory in Bitrix, then sync.