Integrating MoySklad with a website: where synchronization breaks
Integrating MoySklad with a website almost never breaks "entirely" — it degrades in a pinpointed way, and that is more dangerous.
Stock synchronization runs on a schedule, not at the moment of purchase: between the export and the order placement there is a window in which the website shows an item as in stock even though it has already been sold in the warehouse.
This leads to double sales, manual refunds, and customers who have to be told why a paid order will not ship.
The second silent break is a mismatch in the item catalog. SKUs in the accounting system and on the website follow different rules: some were changed manually, some items were created twice, some units of measurement did not match.
Order exchange continues, but line items are matched by name — and the order goes into accounting with a "zero" line that the manager catches only after confirming with the customer.
The third class of failures is lost events. If the exchange is built on periodic polling without a change log, any price or stock edit between two passes simply disappears.
The website and the accounting system diverge on a cumulative basis, and after a couple of weeks no one can say which side is "correct" — it has to be reconciled manually.
The cost of these failures is measured not in integration errors but in failed orders: the customer placed an order, paid, waited — and got a rejection. Below we break down how each of these failures is closed at the level of the exchange scheme rather than through manual edits.
What Exchange Setup Delivers: Products, Orders, Stock
Product Synchronization: The Catalog Stops Diverging from the Shelf
The exchange pulls nomenclature, prices, units of measurement, and attributes from the accounting system into the website catalog. Matching is done by the item's external identifier, not by name — renaming or changing an SKU doesn't create duplicates or break links.
The result: a catalog with several thousand items reconciles with the accounting system in minutes rather than in an overnight run, and a price edit appears on the site without a manual file export.
Order Export: The Document Is Created Once
A placed order goes into the accounting system as a separate document with its composition, discounts, and customer data.
Idempotency by order number closes the main risk — resending when the connection drops: no duplicates appear in accounting, and the status on the site is pulled back after assembly and shipment.
The customer sees the order's progress, and the manager doesn't have to reconcile two databases manually.
Up-to-Date Stock: Selling Without Rejection
Stock by warehouse updates more frequently than the catalog and with priority — an item with zero stock goes to "backorder" or is hidden by rule.
This eliminates the class of rejections where "the customer paid but the product isn't available": the share of canceled orders drops, and the reserve for a placed cart prevents selling a single unit twice.
Exchange Mode and Synchronization Schedule
The exchange is built on the accounting system's standard software interface: events (webhooks) for orders and stock plus a scheduled poll for the catalog.
The schedule is set to match the sales rhythm: stock — every few minutes, catalog — less often, heavy exports — during a low-load window. A queue with retries keeps the exchange running when one of the parties is unavailable and doesn't lose changes.
| Option | When It Fits | Limitations |
|---|---|---|
| Event-driven exchange (webhooks) | Orders, stock, frequent point changes | Requires handling of retries and undelivered events |
| Scheduled poll on a timetable | Catalog, prices, bulk updates | Delay equals the poll interval |
| Hybrid: events + poll | Stores with active sales | More complex setup of the queue and priority rules |
| Direct exchange via an intermediate database | High load, multiple sales channels | Requires a separate service and its maintenance |
МойСклад provides products, stock, and orders through a documented interface — that's enough to build an exchange without manual exports and third-party add-ons.
How we implement integration: from audit to handover
Integration between an accounting system and a website almost never comes down to "turning on synchronization." You need to agree in advance on what counts as the source of truth for stock levels, how nomenclature and warehouses are matched, and what to do with an order placed on the website at the moment the item has already been written off on the sales floor. That is why we work in stages, and each one ends with an artifact that can be verified.
- Audit of the accounting system. We review nomenclature directories, warehouses, prices and price types, movement history, duplicates, and "junk" items. We record which entities are actually ready for integration and which will have to be normalized before the start.
- Design of the integration scheme. We determine the direction of flows, frequency, and triggers: stock levels and prices go to the website, orders go to the accounting system, statuses go back. We define matching rules by SKU and external identifier, behavior on conflict, and behavior when an item is deleted.
- Synchronization setup. We implement the integration through built-in mechanisms and APIs, set up error handling and retries, and limit the load during bulk exports so the catalog does not "freeze" during peak hours.
- Building the test environment. A copy of the catalog and the accounting database, where we run through scenarios: price change, stock write-off, order placement and cancellation, return, appearance of a new item. We check that no discrepancies remain between the systems.
- Testing on real data. We move the integration to the production environment with a limited set of products, reconcile stock levels and orders line by line, measure how long a full cycle takes, and see how the system behaves when the connection drops.
- Regulations and monitoring. We set up alerts for integration failures and discrepancies, and describe what the operator does on an error so the problem does not have to wait for a developer.
- Handover of documentation. We provide the flow diagram, the field mapping chart, instructions for managers, and access to the settings.
This order delivers a predictable result: the integration launches without stopping sales, and discrepancies are visible in the test environment rather than on the first day of operation. Describe your accounting system and catalog — we will come back with an estimate and a work plan.
How does scheduled exchange differ from real-time exchange?
Integrating MoySklad with a website almost always starts with one question: how often to sync data. Scheduled exchange runs on a timer — every 5, 15, or 60 minutes — and pulls changes in batches.
Real-time synchronization works differently: an event in the accounting system (an order was created, stock was changed, a price was updated) immediately goes to the website via a webhook or a change stream.
The difference is not about being "modern," but about what delays and what load you are willing to accept.
Update delay is the key metric for choosing. With scheduled exchange, the stock on the storefront lags by the timer interval: if an item is sold in the store, and the website updates an hour later, the customer will place an order for something that is no longer available.
In real time, stock reconciles within seconds, but each event is a separate request to the website and to the accounting system.
With an assortment of several thousand SKUs and active sales, the event stream becomes dense, and the website starts spending resources on receiving updates instead of serving pages.
Exchange frequency is a trade-off between data freshness and load on the website.
The practice is this: stock and prices — frequently (every 1-5 minutes or on an event), nomenclature and descriptions — rarely (once a day or when an edit is made), orders — immediately, because a lost order costs more than an extra request.
A hybrid scheme covers almost all scenarios: data critical for sales goes in real time, heavy reference data goes in batches on a schedule.
Peak loads deserve separate consideration. A mass price update or a scheduled goods receipt may coincide with evening traffic and bring down the website's response time.
That is why the exchange is moved into a queue, the number of simultaneous requests is limited, and heavy tasks are spread out over time. Then synchronization does not get in the way of customers, and the data stays as up to date as the business requires.
Case study: how we eliminated double-selling during exchange
The client is a retail chain with an online store on a dedicated server and accounting in a cloud system. The exchange was built on regular file uploads: the website pulled stock balances once an hour, and orders went back the same way.
Under peak load — a sale, a new batch arriving — the desync window stretched, and two buyers would order the last unit of a product. The share of orders with stock discrepancies reached 8%, and managers spent several hours a day sorting out cancellations and returns.
What exactly was breaking
The root cause was not the exchange itself, but its asynchrony and the lack of locking at the moment of checkout. The website reserved a product only after the order reached the accounting system — and until that moment, the stock balance on the storefront remained unchanged.
The second problem was write conflicts: if a manager edited a card in the accounting system while the website was sending an order at the same moment, some of the changes were overwritten.
What we changed
We switched the exchange to an event-driven model: the accounting system itself notifies the website about a stock change, and the website reserves the product at the moment it is added to the cart and confirms the reservation at checkout.
A message queue smooths out peaks and guarantees that no event is lost during a brief connection drop. Write conflicts were separated by priority: reference data belongs to the accounting system, real-time reservations belong to the website.
| Metric | Before | After |
|---|---|---|
| Share of orders with stock discrepancies | up to 8% | less than 0.3% |
| Stock update delay | up to 60 minutes | seconds |
| Cancellations due to "out of stock" | regular | isolated |
| Manual conflict resolution | daily | by exception |
МойСклад in this scheme remains the source of truth for nomenclature and stock balances — the website merely reacts to it in a timely manner.
This approach removes the very ground for double-selling: the buyer sees the current stock balance, and the reservation is locked in before payment confirmation.
Concerns about compatibility, migration, and exchange rollback
Integrating MoySklad rarely raises questions at the "connect the exchange" stage — they appear later: what will happen to the accumulated order history, how will the exchange coexist with the current catalog, and what to do if a stock discrepancy surfaces after launch. Let's address these concerns head-on.
What if the site already has its own product and order database?
The exchange does not require a clean installation: on the first pass we match items by SKU and barcode, and conflicts on stock and prices are output as a separate report rather than being silently "overwritten." Order history is transferred in a separate pass so as not to break the analytics already collected.
What if the exchange breaks at night? Every operation goes through a queue with retries, and discrepancies are recorded in a log — if a failure occurs, you can see exactly which order or stock item failed to synchronize.
The rollback plan is built on a backup of the catalog and orders before the first run: returning to the previous state is a switch to a saved snapshot, not manual troubleshooting.
How hard is it to return to the previous way of working if the exchange doesn't suit you?
Rollback is thought through before launch: a snapshot of the catalog and orders, fixed switchover points, and a clear return procedure. If after the test period you decide to stop, we return to the original state without losing the data accumulated during the exchange.
What if you need to restrict access? Roles and permissions are configured separately: the exchange runs through a dedicated user with the minimum required permissions, not through an administrator account.
This also simplifies auditing — you can see which actions were performed by the exchange and which by a person.
After handover, the client receives:
- an exchange scheme with a list of entities and synchronization directions;
- a configuration for matching products, prices, and stock;
- a regulation for handling conflicts and discrepancies;
- a description of the rollback plan and points for returning to the previous state;
- an access and role matrix for the exchange;
- a synchronization log with examples of troubleshooting failures;
- exchange documentation for the team that will maintain it.
Describe your current setup — what data has already been accumulated, how the catalog is structured, and who works with orders. We'll come back with an estimate and a migration plan tailored to your case.
Implementation timeline for integration by stages
The timeline depends on the number of warehouses, sales channels, and how dirty the data is in the accounting system. Below is a guideline by stages for a typical project: a catalog of up to several thousand items, one website, one warehouse.
The stages proceed sequentially, but some of the work on preparing reference data runs in parallel with the integration.
In total, for a typical project — from two to four weeks. Most of the time goes not into the integration itself, but into getting the reference data in order: as long as items are duplicated and prices live in different places, any integration will produce discrepancies.
What if we have several warehouses and points of sale? A stage is added for setting up warehouse priority rules and reservation logic — plus about a week.
What if the website is already running and the integration is needed without stopping sales? The test launch runs on a copy, and we switch the production environment in one short interval, usually at night or during a lull.
Can it be sped up? Yes, if the reference data is already clean and the matching rules are obvious — the preparation stage is cut almost in half.
Describe your warehouse and sales channel configuration — we'll come back with an estimate and a stage-by-stage plan.
