KazanExpress Integration: Where Product Exchange Breaks
Product exchange with a marketplace is not a one-time catalog upload. Products, prices, and stock live in two systems at the same time, and desynchronization between them begins in the first minutes after launch.
From there, it only accumulates if the exchange is not built as a continuous process with verification of the result of each operation.
Stock discrepancies are the most common failure point. An item is sold on the marketplace, but the accounting system still lists it as in stock; then a second order comes in that cannot be fulfilled.
A seller-fault cancellation lowers the rating, the marketplace shows the listings less often in search results, and losses grow not from a single error but from a stream of them.
Lost orders appear where item matching relies on matching names or manually entered SKUs. An order arrives but cannot find the product in accounting and remains unprocessed until it is found during reconciliation.
Manual product upload via spreadsheets handles this up to a certain volume: with a hundred SKUs it is tolerable, with several thousand, daily reconciliation consumes working time and still misses discrepancies.
Errors in product listings are a separate class of losses. Incorrect units of measurement, dimensions, and required category attributes lead to listing rejection or lower search placement, and for non-compliant data the marketplace imposes account restrictions.
These failures share one thing: the exchange runs on a schedule, without parsing the marketplace's responses and without an operation log. Below, we break down how this is addressed at the level of exchange architecture.
What Continuous Order and Stock Exchange Provides
When stock in the accounting system and on the marketplace storefront live separately, every order goes through a person: the item is checked by eye, availability is confirmed manually, and data is transferred into accounting.
With a flow of hundreds of orders per day, this creates a delay of several hours and a predictable class of failures — selling what is no longer in stock and seller-fault cancellations.
Continuous exchange removes this layer. Stock is reserved at the moment the order is placed, not at the moment of picking, so the item leaves the Magnit Market storefront as soon as it is no longer available.
The order enters accounting within minutes, not by the end of the shift, and then moves through statuses without operator involvement.
The share of automatically processed items in such a setup is 95–97%; manual operations remain only for exceptional cases: discrepancy due to defects, partial return, an order with non-standard delivery.
Stock synchronization works in two modes — batch updates on a schedule and point updates immediately after warehouse movement. It is the point mode that keeps availability current during peak hours, when batch updates physically cannot keep up.
The exchange is event-driven: the platform sends a notification about a new order, our side confirms receipt, and if the connection breaks, the request is retried.
Redelivery of the same event does not create a duplicate in accounting — this is designed in from the start, not fixed by reconciliation after the fact. We also keep a discrepancy log: if stock on the storefront and in accounting diverge, it is clear at which step this happened.
Connection Methods: Software Exchange, Files, Seller Account
Connection methods differ not by interface convenience but by how much manual work remains in the chain "order → shipment → status." Before choosing, we fix three parameters: daily order flow, frequency of stock changes, and whether the accounting system has an open interface. The answers determine which exchange mode makes sense at all.
| Method | When it fits | What limits it |
|---|---|---|
| Software data exchange (API) | Hundreds of orders per day, current stock and automatic statuses needed | Intermediary service required: request limits, retries on failures, operation log, test environment |
| File upload | Small flow, once-a-day update, closed accounting system | Delay between uploads, stock discrepancies, manual reconciliation, status arrives late |
| Work through the seller account | Isolated sales or launch without custom development | Manual entry, does not scale, input errors, no connection to the warehouse |
In practice, a mixed mode wins: orders and stock go through software exchange, the catalog and prices are updated by file on a schedule, and rare listing edits are made in the seller account.
This way we do not pay with complexity where the flow is small, and we do not hit a wall of manual work where it grows.
We discuss exchange limitations in advance. At Magnit Market (formerly KazanExpress), exchange and moderation rules change, so we remove some limitations on our side: a retry queue, protection against duplicate orders, and an error log with clear diagnostics.
Workflow: From Accounting System Audit to Handover
Exchange with KazanExpress (Magnit Market) is not "turn on a module" but a project where an error is visible on the very first day: stock diverged, a duplicate order arrived, a shipment status was lost. We follow a fixed route — from accounting inventory to handing the solution over to your team.
- Accounting system audit. We look at where the product catalog, stock, and prices live, which systems already exchange data, and where the order is still edited manually.
- Data flow design. We define the entities that travel both ways: stock, prices, orders, statuses, shipments. We fix the exchange frequency, the primary source for each field, and the conflict resolution rule.
- Exchange setup. We match nomenclature and warehouses, set price recalculation rules, and handle partial shipments and cancellations. Everything that can be checked before launch is checked here.
- Test operation. We run the exchange on live orders in small volume: reconcile stock, statuses, and shipment documents, and resolve every discrepancy down to zero.
- Fault tolerance. We set up a message queue, operation log, automatic retries when the external side is unavailable, and notification to the responsible person about a failure.
- Solution handover. We provide flow documentation, manual operation procedures, access, and employee training. After that — support and enhancements when the marketplace changes its rules.
By the time the exchange is enabled in production mode, the team already sees how the system behaves on real orders and knows the procedure to follow in case of a failure.
Exchange Scheme, Field Mapping, and Support Procedures
After launching the e-commerce integration with KazanExpress, the client receives not a "black box" but a set of documents by which the exchange can be verified, handed over to another contractor, or explained to a new employee. Below is what exactly remains in hand.
- Data flow diagram. Who initiates the exchange, which events go to the marketplace, what comes back, where the queue forms, and what happens if one of the sides is unavailable.
- Field and status mapping table. SKU, name, price, stock, order number, its state — how an accounting system field turns into a marketplace field and back.
- Error handling rules. For each typical error — the cause, the system response (retry, delayed sending, notification), and the attempt limit after which the request goes to a person.
- Employee instructions. What an operator should do in case of a stock discrepancy, a stuck order, or a rejected listing — with examples and step-by-step procedure.
- Support procedures. Frequency of checks, who is responsible for updating catalogs, how the growth of failures is tracked, and when an engineer gets involved.
- Change log and test scenarios. A set of checks before each update and a history of enhancements with the reason indicated — so that edits do not break an already working exchange.
This is enough to hand the integration over for support without us and not lose context.
Case Study: Connecting the Assortment and Synchronizing Stock
The client is an electronics and accessories supplier: about 4,800 SKUs in the warehouse and three sales channels, including KazanExpress.
The catalog was maintained manually by three people — listings were created by copying, stock was recalculated from a spreadsheet once a day, and prices were edited separately on each storefront.
By evening, discrepancies between the warehouse and storefronts reached 8–9%, orders for unavailable products were canceled, and response to a new order took 3–4 hours.
What We Changed
We placed an exchange service between the accounting system and the marketplaces. It pulls stock from accounting, maps it to a unified catalog by SKU and barcode, and distributes it across storefronts.
Only changes go out — deltas from the previous cycle, not a full catalog upload; the nightly reconciliation recalculates everything in full and closes accumulated discrepancies.
Orders and statuses go through a queue with retries on failure: confirmation, picking, transfer of the tracking number — without manager involvement.
Metrics Before and After
- Stock updates: once a day → every 10 minutes by deltas.
- Warehouse ↔ storefront discrepancies: 8–9% → 0.5%.
- Order response time: 3–4 hours → about 10 minutes.
- Manual assortment operations: about 120 per day → 10 (new listings only).
- Cancellations due to "out of stock": 6% of orders → less than 0.4%.
We provide support along the same circuit: exchange errors are visible in the log with a link to the SKU, and a failed operation can be retried manually or on a schedule.
A new marketplace is connected as another delta recipient — the accounting logic does not have to be rewritten.
How KazanExpress Integration Differs from Manual Upload
Manual upload is a file that an operator compiles and uploads to the Magnit Market seller account. While there are few SKUs and prices are edited rarely, the scheme works. A discrepancy appears when data in the accounting system changes more often than you can rebuild the file.
| Operating Option | When it fits | Limitations |
|---|---|---|
| Manual file upload | Dozens of SKUs, rare edits, one operator | Data becomes outdated between uploads — orders come in for a removed item |
| Scheduled exchange | Hundreds of SKUs, prices and stock change several times a day | Requires export from accounting and parsing of marketplace errors |
| Continuous event exchange | Thousands of SKUs, multiple warehouses, promos and campaigns | Requires normalized catalogs and order queue control |
| Exchange plus manual listing edits | Catalog is growing, content is refined by a person | Requires a priority rule over manual edits |
The threshold for assortment volume is set not by catalog size but by change frequency.
If stock and price change several times a day, manual mode stops reconciling already at several hundred active SKUs: the buyer places an order for something unavailable, and the listing gets blocked for cancellations.
Reconciliation labor costs grow linearly with the assortment: each cycle is a manual reconciliation of orders, statuses, returns, and stock. With a small catalog this is hours per week; with a growing one, it is a constant load that does not scale with sales.
The operating mode is chosen by three parameters: frequency of price and stock changes, number of warehouses, and number of orders per day. They show where file-based work ends and continuous exchange begins — next we configure the schedule, error handling, and batch rollback.
Technical Questions About Marketplace Exchange
Before starting, a technical lead runs through the same list: will the exchange integrate with the accounting system, what happens if the connection breaks, how to handle multiple warehouses, what will remain after handover. Below are short answers.
The accounting system does not expose data directly — is exchange still possible?
Yes. An intermediate layer pulls the export from the database or file storage on a schedule and brings it to the structure the marketplace expects. We match nomenclature by SKU and barcode; discrepancies go into a report instead of being silently lost.
What happens if the connection to the marketplace is lost for an hour?
Operations go through a queue with retries, and each is assigned an idempotency key — a retry does not create a duplicate order or movement. After the connection is restored, the exchange catches up on what has accumulated, and we reconcile discrepancies in the log.
How are multiple warehouses and complex product groups handled?
Each warehouse has its own identifier: stock is calculated separately, and shipping priority is set by a rule. For bundles and size ranges, we map parent and child SKUs so that a variant does not turn into a separate product.
What happens if we want to support the integration ourselves?
We hand over the exchange configuration, data flow diagram, matching rules, and retry queue description, plus instructions for typical failures. A walkthrough with your team and support on our side are discussed separately.
Let's Discuss Your Task and Come Back with an Estimate
For the estimate to be accurate rather than pulled out of thin air, we need source data on the store and the current logic of working with the marketplace.
Integration with KazanExpress / Magnit Market almost always comes down not to code but to how your catalog, stock, and order processing are set up — so we start there.
What to send at the start:
- the structure of product categories and attributes — it is used to build listing matching between your accounting system and the marketplace;
- the current method of uploading prices and stock (file, spreadsheet, accounting system) and how often the data should be updated;
- the list of shipping schemes you work with and the rules for distributing orders between warehouses;
- a description of the order processing flow: who confirms, who prints documents, at what point the status is set;
- information about returns and cancellation reasons — they define the rules for writing back to accounting;
- contacts of the people who make decisions on assortment and logistics.
The estimate comes not as a single number but as a work plan: stages, what we do at each, what data we need from you and when, and what counts as the result of a stage.
We separately show acceptance — which scenarios we use to check order and stock exchange and what we do in case of a discrepancy.
The first step is task analysis: we review the inputs, clarify disputed points on statuses and stock, and come back with an estimate, plan, and timeline. Describe the task in a convenient form — then we proceed according to the agreed plan.
