You have 1C in accounting and a shop online. Both of them believe they know your stock. Somebody reconciles them by hand, usually in the evening, usually wrong.
The integration is not technically hard. It is hard because it starts with a question a developer cannot answer.
The question that comes first
For each field, which system is right?
Stock: 1C or the shop? If a customer buys online while a salesperson removes the same item from the warehouse through 1C, which number wins?
Price: does it change in 1C and flow down to the shop, or the other way round? What happens to promotions that exist only online?
Descriptions and photos: almost certainly the shop, because 1C was not built for them — but then a new product created in 1C arrives in the shop with no copy, and someone has to know it is their job to write it.
The order: created in the shop and pushed to 1C, but its status then changes in 1C. So for orders the direction reverses halfway.
That is a business decision before it is a technical one, and if you do not make it, it gets made implicitly by whoever writes the code — who will get it wrong, because they do not know how your warehouse works.
Once the answers exist, the rest is execution.
Three ways in, in order of preference
1. The REST/OData interface, if the version allows it
Since platform 8.3.5, 1C generates a REST interface over your database on its own, using OData. Nothing is programmed inside 1C: you publish the infobase to a web server and tick the option in Designer, under Administration → Publish to the web server → Publish standard OData interface.
This is the cleanest option: read and write against configuration objects, in real time, with no intermediate files and no second copy of the data that can fall behind.
2. HTTP services written inside 1C
When the standard interface is not enough — you need an operation that means five steps in 1C rather than a simple read — an HTTP service is written directly in the configuration.
That requires someone working inside 1C. Usually your 1C partner, not us. It is a boundary worth drawing at the start: we take everything outside 1C, they take what is inside.
3. File exchange, if the installation is old
CommerceML is the standard XML format through which 1C exports the catalogue, prices, stock and orders. It works on installations where neither REST nor HTTP services are available or permitted.
It is the slowest route and the only one that is not real time: the exchange runs on a schedule, every few minutes or every few hours. For stock that means you will occasionally sell something that just ran out. You compensate with a buffer — never showing the last two units online — but the compensation is a decision, not a fix.
What we need before starting
The list is short and every item blocks if it is missing.
Which configuration and which version. "1C" is not one product. Trade Management, Accounting, and a configuration someone modified six years ago are three different things with different objects.
A way in. One of the three above. If the database runs on a machine in your office with no external access, we need a VPN or an agent that reaches out.
The field decisions. The ones at the top of this article, written down. It does not need to be a formal document, but it needs to be explicit.
A test copy of the database. Not the live one. The first run of an integration writes wrong things — that is normal — and where it writes them matters.
Someone on your side who can change things in 1C. Even if we choose the route that needs no programming inside 1C, a moment will come when something has to be published, a permission granted, or a field added.
What usually goes wrong
Both systems write the same field. The most common one, and it only appears in the second month: stock synchronises in both directions, and on a few seconds of overlap the last writer wins. That is solved by the rule at the top of this article, not by cleverer code.
1C does not answer at night. Many installations close or lock during the end-of-day routine. An integration that assumes 1C is always available will lose orders in exactly the window nobody is watching.
Product codes do not line up. In 1C the product has an internal code, in the shop it has another, and at some point someone matched them by name. The first rename breaks the link silently. Match on a stable identifier, never on text.
Price with and without VAT. 1C usually holds the net price, the shop displays the gross one. If the two are not agreed at the start, the difference shows up on an invoice, not in the code.
How long it takes and what it costs
The code for an ordinary synchronisation — products, prices, stock, orders — is days of work, not months.
What stretches it is everything outside the code: getting access to the database, a modified configuration where the objects are no longer where they should be, and waiting for the field decisions. We have seen integrations where half the elapsed time went to the question "who owns stock", asked halfway through.
The best thing you can do before asking for a quote is answer the questions in the first section yourself. With those written down, what you get back is a price. Without them, it is an estimate.