Early last year a manufacturer from Riga called us. They had about 2,000 product names in 1C, and a development team had promised automatic synchronisation with the new WooCommerce store. Four months later, products synchronised but prices only sometimes. Stock arrived three to four hours late. Order statuses went back to 1C only by hand. Everything looked fine in the demo and started failing under real load.
This is not rare. 1C is a fundamental tool for many companies in the region, and websites and online shops still have to connect to it. The problem is rarely 1C itself. It is the integration approach.
Why 1C integration is harder than it looks
The 1C installed base is varied. You may run 1C:Enterprise 8.2, 8.3 or a localised configuration maintained by a local partner ten years ago. Each has a different data structure and API availability, and not all have the web service enabled by default.
The bigger issue is that 1C data is often not clean. A customer with 1,500 items can turn out to have 300 duplicates, 50 items without a SKU and a price list where the same item’s price depends on the buyer category. A naive integration either fails silently, reloads everything on each run or, worst of all, starts publishing wrong prices in the public shop. We have seen all three, and the third is the most stressful for client and developer alike.
Where integrations usually break
- Stock desynchronisation. The warehouse updates 1C, the website learns late, and a customer buys an item that is sold out. The fix is not only a shorter sync interval but also a reservation mechanism: when an order arrives on the website, stock is marked as reserved immediately, whether or not 1C has updated yet.
- Price group logic. Most 1C configurations have several price groups: wholesale, retail, regular customers. The website is often integrated with only one. It works until you want logged-in users to see wholesale prices, and then the integration turns out not to support that.
- Product hierarchy. 1C can store items in a complex group structure. A website catalogue often needs it mapped differently. If the integration does not solve that at the start, categorisation becomes manual work with every catalogue update.
- Order return flow. Sending an order from the website to 1C is one thing. Receiving status changes back (shipped, invoice paid) is another. Many integrations are one-way: the site sends, 1C never answers.
- Error handling. The 1C web service may not respond, the data format may change after a configuration update, permissions may expire. Without a clear error log and retry logic you learn about problems from customers who call to say their item still shows as available.
How we approach 1C integration
There is no universal solution, but there are principles that work.
- Data audit before code. We ask for a 1C export and look at what is in it. How many duplicates? Which price groups are active? What does the product hierarchy look like? This step reveals most problems that would otherwise surface in production.
- A sync log. Every run records what was received, what changed and what failed. If something breaks after a 1C update, we have an exact starting point, not guesswork.
- A buffer, not a direct connection. The website server does not call 1C directly; a queue or intermediate service sits between them. A 1C restart or slow response then does not stop order intake on the website.
- Two-way order status. It takes more work, but without it the sales team works in two systems and re-enters information by hand.
What “working” means
Getting data through is one thing. Behaving correctly when something goes wrong is another. What does your website do if 1C is unavailable for 20 minutes? Show every visitor an error? Stop taking orders? Continue with the last saved data? That decision belongs in development, not in a crisis.
The same goes for sync frequency. More often is not always better. If the 1C configuration is slow and you have 3,000 items, a full sync every minute may cost more than it gives. Delta synchronisation, sending only changed records, combined with webhook notifications for critical events such as stock reaching zero, is usually better.
Technical options in 2026
- HTTP web services (OData or custom) are the most common option on the website side. If your 1C configuration supports them and they are set up properly, they are a stable base. Not every configuration enables them by default, and sometimes a 1C specialist is needed.
- CommerceML / XML exchange is older but still widespread, especially in 1C:Trade configurations, and many WooCommerce developers use it. It works, but the format is clumsy and less flexible than REST.
- Middleware, a separate synchronisation service, is the best choice when you have complex logic or several systems to keep in step with 1C: a website, a CRM, perhaps an accounting module such as Moneo.
We have worked with all three in different e-commerce projects. There is no single right option, only the right one for a given company and 1C version.
Questions to ask before you start
- Which 1C version and configuration do you run? That decides what integration options exist at all.
- Is a 1C specialist available to change the configuration on the 1C side if needed? The website side can be perfect, but if the 1C web service is not enabled it does not help.
- What delay is acceptable? Real-time stock needs a different approach from price sync, where once a day may be enough.
- Must orders reach 1C automatically? And how should an unavailable integration be handled?
These are not formalities. They decide how complex, and therefore how costly, the integration will be. Related reading: B2B e-commerce portals and the same pattern for another system, Jumis with WooCommerce.
How we can help
FSM Studio has worked since 2006 with companies that need web development with real integrations: systems that fit existing processes, not just good-looking sites. Before an offer we usually ask three or four specific questions about your 1C configuration. It saves time for both sides. If you are stuck halfway with an unstable integration, write to us.
