According to the Bureau of National Statistics, in 2025, the volume of retail e-commerce in Kazakhstan reached almost 3.8 trillion tenge — 19.4% more than the previous year, with online sales accounting for 14.3% of total retail. Marketplaces accounted for about 3.2 trillion tenge, or 86% of the market, while company-owned online resources handled 531.3 billion tenge. This second figure interests us more than the first: half a trillion tenge in turnover goes through websites that someone needs to populate with products, prices, and stock. In most cases, in Kazakhstan's small and medium businesses, this is done by a person exporting from 1C and using an Excel spreadsheet.
At West Star Ltd, we specialize in integrating accounting systems with external services, and over the past few years, we've dismantled dozens of such "manual bridges" between 1C and websites. The thesis of this article is simple: the exchange of products and prices between 1C and a website is a long-solved engineering task, but it is solved in three fundamentally different ways, and the choice is not the one usually offered by default. The mistake in choice doesn't cost money on implementation but rather years of small daily losses: outdated prices, orders for out-of-stock items, and a manager who spends half an hour every morning "updating the website."
WHY MANUAL EXPORTS LAST SO LONG
Manual exchange survives not due to laziness but because it always works "well enough." The scheme is familiar: an accountant or manager generates a report on the nomenclature in 1C, exports it to Excel, edits the columns, hands it over to a content manager, who uploads the file to the website's admin panel. The cycle takes from twenty minutes to two hours and repeats daily, weekly, or, frankly, never.
The problem is not the labor costs but the delay and silent errors. Between changing the price in the accounting system and its appearance on the website, several hours to several weeks can pass. During this time, the client sees the old price, places an order, and the manager calls to explain that "the price has changed." In our practice, such calls are one of the main reasons for online refusals among companies with non-product assortments. The second silent loss is stock. The item is sold from the warehouse, but it remains available on the website for another day. The order is accepted, sometimes the money has already been processed, but there's nothing to ship.
The third category of errors is discrepancies in directories. Manual exports almost always go by product name rather than identifier. Someone renames an item in 1C, and a duplicate appears on the website. Over two years, one client had 340 duplicate cards with a real assortment of 1900 items.
THREE WAYS TO LINK 1C AND A WEBSITE
The first method is standard exchange via the CommerceML standard. This is the official exchange format from the 1C vendor, with the current version being CommerceML 2.05. Technically, it works like this: 1C generates two XML files, import.xml with the catalog and product structure description and offers.xml with prices and stock, and the website accepts and parses them. The exchange is configured in the configuration section for website exchange, and CMS support is almost everywhere — from boxed solutions to popular engines with plugins.
The advantage of this approach is that it doesn't require programming. The downside is that it's a batch, file-based exchange. It transfers the entire catalog or its modified part on a schedule, usually once an hour or less frequently. With a catalog of several tens of thousands of items, a full export can take tens of minutes and significantly load both the 1C server and the website. A separate pain point is images: with optimized image exchange enabled, the vendor directly recommends disabling price and stock exports to avoid overlapping processes.
The second method is the standard OData interface. Starting with platform version 8.3.5, 1C:Enterprise can automatically publish a REST interface to all data in the information base via the OData protocol version 3.0. Simply enable support when publishing on the web server, and directories, documents, and registers become available via HTTP, with responses in Atom/XML or JSON format. No configuration writing is needed, and the base remains on a standard update.
This is the most underrated option. The website or intermediary service requests exactly the data it needs from 1C, exactly when it needs it: the price of a specific item when opening a card, the stock when adding to the cart, the order status when the client inquires. There's no need to store a copy of the catalog or wait for the next export.
The third method is event-driven integration through an intermediary layer. Here, a custom service is placed between 1C and the website, which retrieves data from the accounting system (most often using OData), structures it as needed, caches it, and delivers it to the website ready-made, while also accepting orders and placing them in 1C. This is more expensive to develop but removes the main limitations of the first two methods: the website doesn't load 1C with direct requests, and the data transformation business logic lives separately from the accounting system and doesn't break during configuration updates.
HOW TO CHOOSE
The practical rule we've come to: look at two things — the catalog size and the required data freshness.
If you have up to a couple of thousand items, prices change once a week, and stock isn't critical (items on order, services, project supplies) — use the standard CommerceML exchange. It can be set up in a day, doesn't require a developer, and solves the task.
If there are many items, prices are dynamic, or stock is critical (retail, spare parts, building materials) — you need real-time data requests, i.e., OData directly or through an intermediary. The difference between the options is whether you're willing to let the website access the 1C database. We almost always recommend the intermediary: it provides caching, request frequency limitation, logging, and the ability to replace the data source without touching the website.
A separate scenario is when a company has both a website and marketplaces. Considering that 86% of online turnover in the country goes through marketplaces, such a configuration is more the rule than the exception. Building two independent exchanges here is a mistake. The source of truth should be one, and the platforms should be consumers of the same data stream, otherwise, the price on the website and the marketplace will inevitably diverge.
HOW LONG DOES IT TAKE
Guidelines from our projects to make the budget discussion substantive. Setting up a standard file exchange on an unchanged configuration and a website with a ready module takes from a few hours to one working day, with most time spent not on setup but on reconciling directories. Publishing the base on a web server with enabling the standard interface and setting up service user rights usually takes half a day if the infrastructure is already there, and several days if the base is being deployed anew.
Integration with an intermediary service is another order of magnitude: two to four weeks for the catalog, prices, stock, and order acceptance, plus time for load testing. Most of this estimate usually involves not code but data preparation: cleaning duplicates, setting missing attributes, deciding which price type is considered showcase. On a project with an assortment of about two thousand items, this preparation took us three times longer than the exchange development itself, and this is a normal proportion, not an exception.
WHAT IS USUALLY FORGOTTEN TO INCLUDE
Identifiers. The link between a position in 1C and a card on the website should be by a unique object identifier, not by name or article number. Articles are duplicated and changed, names even more so.
Reverse flow. Exchange is not only "products to the website" but also "orders to 1C." Half of the implementations we've seen do only the first direction, and the manager continues to manually enter orders from the admin panel.
Pricing rules. In 1C, there are usually several types of prices, discounts by counterparties, promotions. Decide in advance which price type goes to the website and what happens with prices below cost or zero — they shouldn't appear on the showcase at all.
Error handling. If the exchange fails, who will know about it? Monitoring and notification are needed, otherwise, the website will run on outdated data for two weeks, and the client will notice it, not you.
LIMITATIONS AND WEAK POINTS
Honestly about where this automation doesn't shine.
— OData returns data in the 1C structure, not in a convenient format for the website. Attributes are named in Russian, links to other objects come as identifiers, prices are in separate registers. Without a transformation layer, the website developer will struggle, and logic will spread across the frontend.
— Performance is limited by 1C. The standard OData interface is not fast on large selections, and filtering and sorting are performed on the 1C server side. With traffic growth, without caching, you'll get a slow website and complaints from accounting about slow database performance.
— Security requires separate work. Publishing OData opens access to all database objects, including those that have no business on the website. A separate service user with limited rights, a restricted set of published objects, and closing the interface from the outside world are needed.
— Configuration updates break integrations. Any modification in 1C risks changing the object structure on which the exchange depends. This affects fully standard schemes less, but with a modified configuration, regression is almost inevitable and requires regulatory testing after each update.
— Data freshness is not free. Real-time means constant load on the database. The compromise between relevance and performance will have to be chosen consciously: stock can be updated every five minutes, not instantly, and in 95% of cases, this is enough.
— Automation doesn't fix accounting mess. If the nomenclature in 1C is poorly maintained — duplicates, empty attributes, items without prices — the same mess will go to the website, only faster and in all directions at once. Tidying up directories almost always takes more time than the integration itself.
WHAT TO DO
For the specialist. Start with an inventory: how many items, what types of prices, where are the warehouses, are there configuration modifications. Check if the base is published on the web server and if OData support is enabled — it often turns out that half the infrastructure is already there. Before writing code, agree on the object link key and what to do with exchange errors.
For the manager. Measure the current cost of the manual process: how many hours per week are spent on exports, how many orders per month are canceled due to incorrect prices or out-of-stock items. These two figures are the budget justification. Demand two-way exchange and monitoring from the contractor, not just a "catalog export."
For the owner. The key question is not "to integrate or not," but "where is the source of truth." If data about products, prices, and stock live simultaneously in 1C, on the website, and in marketplace cabinets and are edited in three places — no integration will save it. The decision on a single data source is made at the company level, not at the developer level.
FREQUENTLY ASKED QUESTIONS
Do I need to modify the 1C configuration for exchange with the website?
For standard CommerceML exchange and the standard OData interface — no. Both mechanisms are built into the platform and standard configurations. Modification is needed when non-standard logic is required: custom pricing rules for the showcase, specific status document flow for orders, combining several warehouses into one stock.
Which is faster to implement — file exchange or OData?
File exchange via CommerceML is set up faster, often in one working day if the website supports it out of the box. Integration via OData requires development on the website or intermediary service side and takes from a week. But it provides data relevance that batch exchange doesn't offer in principle.
Is it safe to open access to the 1C database via the internet?
Only with proper setup. Minimum set: a separate user with rights only to the necessary objects, a limited list of published objects, access via a secure connection, and preferably no direct interface exposure to the internet — the website accesses the intermediary service, which then accesses the database within the perimeter.
What if products are sold both on the website and marketplaces?
Build one data stream from the accounting system and distribute it to platforms, not make separate integrations for each. Otherwise, prices and stock will diverge, and you'll discover the discrepancy from a client complaint or a platform fine for order cancellation.