Integrating 1C with Your Website and Online Store: How to Set Up Data Exchange

Why connect 1C with your website at all

In most companies across Uzbekistan, 1C remains the core accounting system: it holds the product catalog, warehouses, prices, shipments and customer settlements. The website and online store are the storefront and sales channel. As long as these two systems live separately, someone has to move products by hand, update stock and re-enter orders. That is slow, expensive and almost always error-prone: you sell something that is out of stock, or display an outdated price.

Integration solves a simple task — make data flow between 1C and the website automatically. A manager keeps working in the familiar 1C, the customer sees real stock and prices on the site, and orders land in the accounting system on their own. Below we cover exactly what gets exchanged, what the typical traps are, and how to choose the right exchange mode.

What gets exchanged: products, stock, orders

Every integration is built from several data flows, and it pays to agree from the start which flow goes in which direction.

• Product catalog (1C → site): names, SKUs, descriptions, attributes, categories, images, units of measure. Usually 1C is the source of truth for the catalog.
• Prices (1C → site): retail, wholesale, by price type or customer segment. Often only one or two price types are pushed to the site.
• Stock levels (1C → site): by warehouse or in total. This is the flow most sensitive to freshness.
• Orders (site → 1C): new orders with line items, quantities, customer data and delivery method. In 1C they become a customer order or sales document.
• Order statuses (1C → site): paid, picked, shipped, delivered — so the customer can track progress in their account.

The key technical point is product matching. Every item needs a stable identifier (a GUID from 1C or an SKU) so the system knows that "this product on the site" and "this product in 1C" are the same thing. Without a reliable matching key, any exchange will sooner or later start producing duplicates.

Integration approaches

Technically there are several ways to connect 1C and a site, and the choice depends on the store platform and the 1C version.

• Standard CommerceML / "exchange with site" protocol. Many 1C configurations (Trade Management, Retail) can export the catalog and import orders via the standard XML protocol. CMSs like 1C-Bitrix understand it out of the box. It is the fastest start, but the protocol is inflexible and struggles with large catalogs.
• Exchange via REST API. The site exposes an API, and a handler is written on the 1C side to send and pull data in JSON. Flexible, controllable, and well suited to custom logic and large volumes.
• Middleware / connector. A separate broker service that talks to 1C (via web services or OData) and to the site, normalizes data and keeps a log. Handy when there are more than two systems involved (for example, a marketplace and a warehouse app as well).

In Uzbekistan's reality, 1C often runs on a local server in the office while the site sits on hosting or in the cloud. That means you either open secure external access to 1C, or arrange for 1C itself to initiate the connection to the site. The second option is safer and almost always preferable.

Real-time or scheduled

One of the central project questions is how often to synchronize data. There is no universally correct answer here — it depends on the flow and the business.

In practice a hybrid is usually the smartest. Orders from the site should almost always go to 1C in real time — the customer is waiting for confirmation. Stock is also better updated frequently or by event, especially if the product sells in offline points and online at the same time. The full catalog with descriptions and photos, however, can be exported on a nightly schedule — it changes rarely and is heavy.

Common problems and how to avoid them

Most 1C integration failures repeat from project to project.

• Duplicate products and orders. They appear when there is no stable matching key, or when re-running the exchange creates records anew. Cured by idempotency: each object has a unique identifier, and a repeat transfer updates rather than creates.
• Encodings and special characters. Problems with Uzbek Latin, Cyrillic and special characters in names. UTF-8 and proper escaping must be used everywhere.
• Silent exchange failure. The exchange breaks at night and you find out a week later from customer complaints. You need logging, monitoring and an alert to the responsible person on failure.
• Heavy full exports. Pushing the entire catalog every time is slow and loads the server. The fix — incremental exchange: transfer only what changed since last time.
• Differing prices and currencies. If the site runs a promotion while 1C holds the base price, you must clearly decide whose price wins and prevent the exchange from wiping promotional prices.

Error handling deserves separate thought from the outset. A good integration does not merely "transfer data" — it knows how to retry failed operations, park problematic records in a separate queue, and present a clear report of exactly what failed and why.