A retailer selling on its own site and on three or four marketplaces at the same time runs into the same wall: inventory accounting lives in 1C, while each storefront requires its own format and update cadence. Below is an open breakdown of how this is solved at the intersection of 1C, CommerceML, and marketplace Seller API through an integration bus. This is not a case study of a specific implementation, but an overview of established practice with links to standards and documentation.
The business result behind it all
The main measurable effect of synchronization is not automation for its own sake, but the reduction of two concrete losses. First, order cancellations because the item is actually out of stock while the storefront still shows stock. Second, platform penalties: marketplaces lower the listing in search results and may even block sellers for cancellations caused by them. Integration providers state the goal directly as reducing the risk of account suspension through prompt stock updates (rarus.ru). The third effect is freeing people up: manual uploads of price lists and stock to each account are replaced by background exchange.
Two different protocols for one task
It is important to separate the two technical flows from the start, because they work differently.
Online store - exchange via CommerceML. This is an industry standard for exchanging commercial information in XML, developed by 1C and Extra.RU with Microsoft back in 2000 (v8.1c.ru). Exchange happens through a set of XML files: the catalog and item master are exported to `import.xml`, prices and offers to `offers.xml`, and orders are returned from the store to 1C through `orders.xml`. In CommerceML 3.0/3.1, prices and stock are split into separate `prices.xml` and `rests.xml` files, which makes it possible to update them more often and independently of the heavy catalog (docs.cs-cart.ru). The store periodically polls the exchange endpoint, and 1C returns the changed data: a scheduled exchange model.
Marketplaces - exchange via Seller API. Ozon, Wildberries, and Yandex Market do not use CommerceML; each has its own REST API, with its own methods for updating stock, prices, and retrieving orders, its own keys, and its own request rate limits (totalcrm.ru). Here the exchange is closer to event-driven: when an order appears, it must be picked up almost immediately; when stock changes, it must be pushed to all channels.
Why a bus appears between them
The temptation to keep patching 1C with connectors for each platform leads to exchange business logic becoming embedded in the configuration, making it expensive to update. Architecturally, it is cleaner to move the exchange into a separate layer - an integration bus (middleware) that sits between 1C and the storefronts (totalcrm.ru).
The bus handles what fits poorly into 1C itself:
- Item master mapping. One SKU in 1C means different item codes and product cards on each platform. The mapping is stored in the bus, not spread across separate handlers.
- Different update rates. The catalog can be sent to the store once an hour, while stock for marketplaces can be sent every few minutes as a separate lightweight `rests.xml`/API call stream.
- API limits. The bus buffers and throttles requests so you do not hit the marketplace rate limit or get banned for flooding.
- Idempotency and retries. If the platform returns an error, the bus retries the exchange instead of losing the order.
- Stock reservation. When a product is sold simultaneously on the website and on three marketplaces, the bus becomes the single point that subtracts stock from the shared pool and sends updates to all storefronts, preventing oversell.
This approach follows the principle of minimally changing the tool's core: 1C remains the accounting system in a nearly standard configuration, while all changeable exchange logic lives alongside it in an isolated service. This lowers the cost of 1C updates and makes it possible to hand off the exchange to another team without rewriting it.
How the data flow works
Direct flow (out of 1C): item master and prices change in the accounting system -> the bus picks up the changes -> CommerceML (`offers.xml`/`prices.xml`/`rests.xml`) goes to the online store, and the marketplaces receive the corresponding API calls to update prices and stock.
Return flow (into 1C): orders from the website arrive in `orders.xml`, marketplace orders are fetched through the API -> the bus normalizes them -> creates documents in 1C -> statuses (packed, shipped) are sent back to the platforms.
A bottleneck that the exchange documentation warns about: in optimized exchange mode, stock and price exports from 1C into one of the environments must be disabled so that the two sources do not overwrite each other (docs.cs-cart.ru). A single source of truth for stock is essential; otherwise, synchronization creates data races, not order.
What to define at the start
- A single mapping directory for SKU ↔ marketplace item code as a separate entity.
- Split flows: the heavy catalog separately, and lightweight stock/prices separately and more often.
- Exchange log and alerting: you can see which order did not get through and why.
- Handle API limits and retries on the bus side, not in 1C.
Business process conclusion
Synchronizing 1C with marketplaces and the store is not just about setting up exports; it is a redesign of stock accounting into one managed flow. When stock is deducted from a shared pool and reaches all storefronts within minutes, the retailer stops selling what is unavailable, keeps prices consistent across platforms, and removes manual exports from managers. Technically, this is achieved by combining CommerceML for the online store and Seller API for marketplaces, separated through an integration bus with its own single source of truth for stock.
