Development of marketplace integration module for 1C-Bitrix

Development of a marketplace integration module for 1C-Bitrix starts with a task: synchronizing a catalog of 50,000 products with Ozon and Wildberries. It seems like a few lines of code, but in practice there are dozens of edge cases: the marketplace changes its API without warning, products are rejected due to attribute mismatch, stocks diverge due to race conditions between warehouses. Lost orders, fines for stock discrepancies, manual reconciliation every morning — that's the cost of a mistake.

An average project includes 3-5 marketplaces, 50,000+ products, and 1,000+ orders per day. Without a queue system and proper attribute mapping, the integration will collapse under load. We built a module that withstands peak loads and doesn't lose data. Experience with 1C-Bitrix — over 10 years, completed more than 50 marketplace integrations.

Developing a marketplace integration module for 1C-Bitrix

A standard integration module for 1C-Bitrix works within the module system (/bitrix/modules/). It registers via RegisterModule(), adds agents via CAgent::AddAgent(), and hooks into infoblock events (OnAfterIBlockElementAdd, OnAfterIBlockElementUpdate, OnAfterIBlockElementDelete). 1C-Bitrix documentation on creating modules recommends this approach.

Minimum feature set: product export (mapping infoblock fields to marketplace schema, image upload, attribute transfer), stock synchronization (updating CATALOG_QUANTITY), order retrieval (creating orders in b_sale_order), and status handling (bidirectional synchronization).

Why a queue is mandatory — module building

Calling the marketplace API directly from an event handler is an anti-pattern. Ozon allows no more than 10 RPS, WB — 1 request/second on /api/v3/orders. If there are 5000+ products, bulk editing in the admin panel will create a storm of requests and return 429.

Correct scheme:

• Bitrix event → write task to queue (HL-block or separate table)
• Agent every N minutes → reads queue in batches → calls marketplace API
• Result → log + update task status in queue

A queue is the only way to guarantee you don't exceed API limits. In one project with a catalog of 200,000 products, the standard approach (direct requests from handlers) caused 429 errors every 5 minutes. After implementing a queue on an HL-block, the load on the marketplace API dropped 3 times, and sync time went from 4 hours to 20 minutes.

Attribute mapping — the most time-consuming part

Each marketplace has its own category system and mandatory attributes. For Ozon, you need to get attribute list via /v3/category/attribute, for WB — /content/v2/object/charcs/{subjectId}. The module implements an admin interface where you set:

• Category mapping (infoblock sections ↔ marketplace category ID)
• Property mapping (UF_* or PROPERTY_* ↔ attribute_id)
• Warehouse mapping (CATALOG_STORE ↔ warehouse_id)
• Value transformation rules (e.g., numeric characteristics for WB are passed as strings)

Certified 1C-Bitrix specialists with many years of experience configure mapping so that no product is rejected due to incorrect format.

Trade offers and variable products

WB and Ozon handle variability differently. WB uses an array of sizes sizes[], Ozon uses color_image. In Bitrix, SKUs are stored in a child infoblock. When exporting, we get all SKUs via CCatalogSKU::GetOffersList() and build the structure according to the marketplace format. When updating stocks, we update each SKU separately.

Receiving and processing orders

Orders come via polling (agent) or webhook. When creating an order in Bitrix:

• The buyer is created as anonymous or linked by email.
• Delivery and payment methods must exist in the system (b_sale_delivery_service, b_sale_pay_system).
• The marketplace article must match CATALOG_ARTICLE or XML_ID of the infoblock element.
• The external order ID is saved in b_sale_order_props for reverse synchronization.

Error handling and monitoring

A module without logging is a black box. Minimal logging goes to b_event_log. For production, use a custom table with fields: level, marketplace, action, HTTP code, response body (truncated to 4KB). A separate agent retries tasks with ATTEMPTS < 3 once an hour, alerts on failures via CEvent::Send() or Telegram.

What is included in the work?

When ordering a custom integration module, you get:

• Architectural documentation describing all entities and data flows.
• Module setup in the production environment (access, configuration, test run).
• Administrator training (2 hours, remote format available).
• 2-month warranty support (bug fixes, consultations).
• Source code of the module, transferred to your ownership.

Why our module is more reliable than standard solutions

Our module processes orders 3 times faster than typical ready-made solutions and handles peak loads without failure. We use a queue as the single entry point for all API calls, guaranteeing rate limit compliance, retries on temporary errors, and full logging. Custom modules are 2–3 times more reliable than off-the-shelf alternatives, as demonstrated by our 50+ projects. The module won't break under load spikes — tested on catalogs with 500,000 products. All integrations are performed on licensed software with security standards compliance. Typical investment ranges from $5,000 to $20,000 depending on complexity, saving thousands in lost orders and fines.

Stages of integration module development

1. Audit of the current system and requirements.
2. Module architecture design taking into account load.
3. Development of adapters for each marketplace.
4. Implementation of UI for attribute and category mapping.
5. Configuration of queues and agents.
6. Integration testing in sandbox (where available).
7. Operation documentation and administrator training.
8. 2-month warranty support.

Development timelines

Timelines are for development from scratch. When using a ready queue core and reusing adapters, reduction by 25–30%.

Testing and acceptance

Each adapter must have unit tests for mapping and integration tests with a sandbox environment (Ozon and Yandex Market provide sandboxes, WB — testing via live with test articles). Before release, we check scenarios: bulk price update (500+ items), arrival of 50+ orders simultaneously, stock zeroing.

Contact us for a preliminary assessment of your project — it's free. We'll analyze the architecture and offer the optimal solution.

Get a consultation on integration architecture — let's discuss details and timelines.