Why a marketplace store loses orders without synchronization
You sold the last unit on your website, but the listing on the marketplace remained active — the buyer places an order, you confirm it, and there's no product.
A cancellation due to the seller's fault hurts your rating, and the platform's algorithm gradually lowers the listings in search results.
This isn't a one-off glitch but a systemic result of manually updating listings: while a manager adjusts stock by hand, catalog desynchronization accumulates between sales channels.
The reverse situation is no better: the product is sitting in the warehouse, but the listing shows zero — sales simply don't happen, and no one notices.
Add to this duplicate listings after re-uploading, different prices in the listing and in the accounting system, and orders lost between email, the seller dashboard, and the CRM. Each such gap is not only lost revenue but also employee time spent on manual reconciliation.
Integration with Avito via API eliminates the root cause: stock, prices, and order statuses are synchronized between the store and the platform automatically, based on events rather than on a duty manager's schedule.
Stock synchronization triggers at the moment of a sale in any channel, so a listing cannot sell something that isn't there, and an order from the platform goes straight into the accounting system and doesn't get lost in messages.
Next, we break down how this is handled at the level of data exchange and what exactly breaks with manual work.
What automatic store synchronization delivers
Synchronization is built on the "accounting system — marketplace" link: a product is entered once, and from then on the listing, price, stock, and order status live in a single loop.
Publishing a new item stops being a manual operation — the listing goes to the platform the moment it appears in the catalog, rather than a day or two later when the manager gets around to it.
For an assortment of hundreds of items, this is the difference between "listed in an evening" and "listing for a week."
Stock accuracy is the second measurable effect. Stock is deducted upon order placement and returned upon cancellation or return, so the discrepancy of "one thing on the website, another on the platform" is eliminated as a category.
This is usually where money is lost: a buyer orders an item that is no longer available, the order falls through, and the listing gets demoted in search results.
A unified catalog removes manual labor in support: editing a description, specifications, or price is done in one place and propagates across all sales channels.
Managers stop cross-checking spreadsheets and transferring data by hand — which means the class of errors that arises only during manual transfer also disappears: a typo in the price, a forgotten item, an outdated photo.
Sales automation manifests in order processing: a new order is pulled into the accounting system, the status goes back to the platform, and the buyer sees movement on the order without an operator's involvement.
The more orders per day, the more noticeable the difference — the manual loop starts to choke precisely at peaks, when losing orders is most costly.
The effect can be checked at four points: the time from a product appearing in the catalog to publication, the share of orders canceled due to outdated stock, the number of manual operations per order, and discrepancies between the catalog and the platform.
These metrics are captured before and after implementation — and they show whether the link paid off.
Connection methods: file exchange, API, intermediary
The three methods differ not in "convenience" but in where the matching logic lives and how quickly the store learns about a change.
With file exchange, you generate a catalog export and deliver it on a schedule; when working through an API, requests go directly to the marketplace; an intermediary service takes on the queue, retries, and error parsing.
The choice is dictated by the update frequency: stock levels and prices change constantly, while descriptions and photos change rarely.
| Option | When it fits | Limitations |
|---|---|---|
| File exchange | The catalog changes rarely, there are few items, and a delay is acceptable | No reaction to an event, errors are visible only after parsing the response, manual reconciliation |
| Exchange via API | Up-to-date stock levels and prices are needed, dozens and hundreds of items | Limits on the number of requests, mandatory handling of failures and retries |
| Intermediary service | Multiple sales channels, high update frequency, history is needed | Harder to maintain, requires separate monitoring and state storage |
In practice, an API is most often taken as the primary channel, and an intermediary service is built on top when there is more than one point of sale.
File exchange remains a workable solution for infrequent exports and one-off reconciliations — for example, when migrating a catalog or during inventory.
The limitations of the methods should be factored into the architecture in advance: request limits force you to group changes and update items in batches rather than one at a time.
Then a peak of edits in the catalog does not turn into a queue of failures, and the discrepancy between the store and the marketplace is closed within a single update cycle.
How the Avito integration implementation works
Implementation begins not with code, but with an analysis of the current state: how the catalog is structured, where stock levels come from, who changes prices and descriptions and how often.
At this stage, we record discrepancies between the accounting system and what has already been published on the marketplace — these are exactly what produce duplicates, "stuck" listings, and sales of items that are out of stock.
- Catalog and accounting data audit. We reconcile the item list, categories, units of measurement, and the rules for generating prices and discounts. The output is a mapping: which items are published, which are hidden, and what to do with products that have no stock.
- Designing the exchange scheme. We determine what is the source of truth, in which direction the data flows, and at what frequency. We define the conflict behavior: if a manager edited a listing manually and the accounting system sent a new value — who wins.
- Assembling the synchronization loop. We implement the exchange of stock levels, prices, listing statuses, and orders, along with error handling and retries during communication failures. Separately, we handle the marketplace's rate limits so that a burst of updates does not lead to request blocking.
- Test loop. We run scenarios on a limited group of products: mass price updates, zeroing out stock, returning an item to stock, order cancellation. We review the logs and reconcile the final state of the catalog with the accounting system line by line.
- Pilot on the live catalog. We connect real listings for a small share of the assortment and observe a full 24-hour cycle: nightly recalculations, morning orders, manual edits by managers.
- Handover to operation. We deploy exchange monitoring, set up alerts for discrepancies and failures, and describe the incident response procedure.
- Training and procedures. We hand the team instructions: how to add a product, how to temporarily unpublish it, and what to do when stock levels diverge.
After handover, the integration works without manual intervention, and catalog changes reach the marketplace within the specified interval. Describe your task — we will come back with a timeline estimate and a stage-by-stage work plan.
What the client receives after launch
After the integration goes live, the client is left not with a "black box" but with a set of artifacts that allow the system to be handed over to another team, extended, or rebuilt from scratch. Below is exactly what we include in the handover.
- Integration settings. Configuration of the exchange between the store and Avito: credentials, request limits, synchronization schedule, error handling, and retries. Everything is placed in a separate config rather than "hardcoded" into the code.
- Product matching rules. The logic by which catalog items are linked to listings: by SKU, barcode, or composite key, what to do with duplicates and discrepancies, and how new and discontinued items are handled.
- Data exchange schema. A flow diagram: which fields go to Avito, what comes back to the store, where the synchronization state is stored, and how conflicts are resolved when changes happen simultaneously.
- Integration documentation. A description of scenarios, request and response formats, and extension points. Enough for a new engineer to get up to speed without the original author.
- Exchange logs. Synchronization logs with history: what was sent and when, what came back, which items were rejected and why. Any failure can be diagnosed from them without reproducing it.
- Support regulations. What is monitored automatically, which alerts are triggered, who responds to a failure and within what timeframe, and how rollback is performed.
- Operations manual. Step-by-step actions for typical situations: add a category, change a matching rule, restart the exchange, connect a new store.
Each artifact is versioned together with the code — when rules and schemas change, they are updated in sync rather than drifting apart. Describe your task — we will come back with an estimate and a handover plan.
Case Study: How a Store Stopped Losing Orders on a Marketplace
What It Was Like Before Synchronization
The store sold through Avito and its own website, and managed stock manually: a manager would export a spreadsheet, edit it, and upload it back.
At peak sales, this resulted in up to 18% of SKUs with discrepancies — an item would sell on the marketplace when it was already out of stock, or conversely, it would show as "in stock" with zero inventory. Each such case meant a canceled order, a call to the customer, and a hit to the seller's rating.
Worse was the response delay: a marketplace order would only reach the accounting system after a manager manually transferred it from the seller dashboard. The average time to confirmation was about 40 minutes during a work shift and up to 9 hours on weekends. During that time, some customers managed to place an order with a competitor.
What We Changed
We set up integration with Avito via API: stock levels and prices are pushed to the marketplace with every warehouse change, and new orders are pulled from the seller dashboard and created in the accounting system automatically.
For edge cases — item reservation during checkout, retry on connection failure, an operation log with idempotent keys so that a single order doesn't get duplicated.
We also configured desynchronization rules: if an SKU isn't confirmed, it goes into a review queue instead of getting "stuck" in an incorrect status. The manager sees only exceptions instead of the full spreadsheet.
Implementation Results
- Stock discrepancy rate: from 18% to 1.2% — cancellations due to "out of stock" have virtually disappeared.
- Order response time: from 40 minutes to 2-3 minutes, around the clock, no days off.
- Manual export operations: reduced by approximately 90%, and the manager shifted focus to working with customers.
Two months after launch, the store stopped losing orders on the marketplace: disputed SKUs are resolved individually rather than blocking the entire storefront.
How API synchronization differs from file uploads
A file upload is a batch operation: you generate XML or CSV on a schedule, submit it to a personal account or via a link, and the platform accepts the file as a whole and processes it asynchronously.
Between two uploads, the store lives in the state of the previous snapshot: a price, stock level, or listing status changes only after the next run.
If a manager adjusted stock manually in the panel, the next upload will overwrite it — the file doesn't know what happened in the system after it was generated.
An API works on an event-driven model. A change in the accounting system (a payment, a goods receipt, a price change) puts a task in a queue, and the handler sends a request to the platform and records the response.
Data latency is measured not in hours between uploads, but in the time it takes for the queue to pass — under normal operation, that's seconds to minutes.
Synchronization frequency ceases to be a schedule parameter and becomes a property of the stream: only what has actually changed is updated, not the entire catalog.
Fault tolerance is the key difference. On a parsing error, a file upload returns a general failure for the entire batch: it's unclear which item failed and why, and you have to reconcile manually.
The API returns a result for each operation separately, and a network failure or rate limit is handled by retrying with an increasing delay.
A task isn't lost: unprocessed changes remain in the queue and go out after connectivity is restored, rather than rolling back to the state of the last file.
Hence the difference in the volume of manual operations. With files, someone has to monitor the schedule, parse error logs, and manually catch up on discrepancies.
With an API, the only manual work left is handling exceptions that the system couldn't resolve on its own — and their share is an order of magnitude smaller.
The choice between the approaches is a choice between "data is current as of the upload" and "data is current as of the change."
Common technical questions about marketplace integration
Integration with Avito almost never starts from scratch: more often the client already has a working solution — custom-built, on the contractor's side, or assembled from ready-made modules.
We don't break what keeps sales going: first we analyze the current exchange scenarios, failure points, and how the catalog is matched with the platform's categories.
Then we either extend the existing integration or migrate it to a supported architecture — while preserving order history and links between listings.
A separate topic is multiple platforms and a non-standard catalog. When a store sells not only on Avito but also on marketplaces and in its own online store, it's important not to multiply duplicate products and not to lose stock.
We build a unified synchronization layer: a single source of truth for nomenclature, prices, and stock, while platforms receive data through their own adapters.
Non-standard catalogs — bundles, services, made-to-order items, complex units of measurement — we describe with matching rules rather than manually editing each position.
Rate limits and exchange failures are not an emergency but a standard mode of working with an external API.
That's why the integration has request queues, retries with increasing backoff, and idempotent operations built in from the start: a repeated send doesn't create a duplicate listing or order.
If the platform is unavailable, changes accumulate locally and go into the exchange as soon as the connection is restored.
We already have an Avito integration — will we have to rewrite everything?
No. First, an audit of the current solution: which scenarios are covered, where data is lost, how limits and errors are handled. If the foundation works, we build out what's missing and close the bottlenecks.
We do a full migration only where the current architecture can't handle the load or isn't supported.
Can Avito and other platforms be synchronized from a single system?
Yes. We separate out a common synchronization layer: nomenclature, prices, and stock are maintained in one place, and each platform connects through its own adapter. This eliminates stock desynchronization and manual duplication of listings across sales channels.
What happens if the exchange fails or rate limits are exceeded?
Requests are queued with retries and increasing backoff, operations are idempotent — a repeat doesn't create duplicates. Changes that didn't reach the platform are stored locally and sent after the connection is restored, and discrepancies go into a report for review.
Let's discuss your store synchronization task
To come back with an estimate and a plan rather than generalities, we need to understand your workflow with Avito: how many active listings, how many categories, how often prices and stock change, and who currently updates them manually.
This determines both the scope of the Avito integration and the implementation timeline — synchronizing a catalog of several hundred items and exchanging orders with multiple warehouses require different architectures.
During the task review, we clarify the key points: what data flows from your accounting system to Avito, and what comes back — orders, statuses, reviews, buyer messages.
We check whether you have API access and permissions for the required methods, how stock accounting is structured, and what happens during a desync.
We separately discuss failure scenarios: what to do if a listing was unpublished while the item is still in stock, or if an order came in at the moment a price was being updated.
Based on the conversation, you receive:
- a data exchange scheme between your system and Avito, indicating directions and synchronization frequency;
- a list of API methods we will use and the constraints they impose on the logic;
- a phased work plan: access preparation, exchange development, test environment, production deployment;
- realistic implementation timelines broken down by phase, with points where your involvement is needed;
- post-launch support scope: exchange monitoring, error handling, response to changes on Avito's side;
- a list of data and access credentials we will need from you to start.
The next step is a short, focused conversation: describe the task, your current process, and bottlenecks, and we will come back with an estimate, work plan, and timelines.
If some processes are not yet formalized, that is not a blocker — we will sort it out together and propose how to close the synchronization without rebuilding your entire accounting system.
