Marketplace integration: stock, prices and orders kept up to date automatically

You sell on your own site and on one or more marketplaces, and you track your stock in stock management software. As the number of products and orders grows, you start to see sales of items with zero stock, prices that have fallen behind and orders copied from one screen to another. A marketplace integration done properly moves this work into the background and tells you plainly when something has not gone through.

The first decision is not a technical one: which system holds the truth for each piece of information. As a rule, stock comes from the stock management software, while descriptions and photos come from the store. If two systems are allowed to write to the same field, sooner or later they will contradict each other.

Where the chain breaks when you sell on several channels

The classic problem is overselling: the last unit sells on your site, and the marketplace goes on showing it as available until the next update. The second is price: you change the list in your stock management software and forget one channel, or you apply a discount that, once the platform’s commission comes off, takes you below cost.

The third is about people: someone downloads the orders, retypes them into the stock management software, issues the invoice and uploads the tracking number back to the platform. Every manual step is a chance for a mistake and a cap on volume, at exactly the time you are selling the most.

What we sync between the store, the stock management software and the platform

The link is a separate service that sits between the three systems: it reads changes on one side, translates them into the format of the other and keeps a record of what it has sent. That way you can add a second channel later without redoing everything.

Take a WooCommerce store, stock management software that has an API (the interface through which one program asks another for data) and a seller account on eMAG Marketplace. The usual flows:

• Stock: every movement in the stock management software goes out to all channels, with a safety buffer on fast-moving products.
• Prices: we start from the base price and apply rules per channel (markup, rounding, minimum price).
• Orders: an order placed on the platform enters the stock management software like any other and reduces stock everywhere.
• Statuses and documents: the tracking number, the invoice and the order status go back to the platform; returns are reflected in stock.

Mapping categories and characteristics

Every marketplace has its own category tree and, for each category, mandatory characteristics, often with permitted values taken from a fixed list. In your catalogue the colour may be “navy”; the platform only accepts “blue”. Without this translation, products are rejected at validation or end up in the wrong category.

We build a mapping table: your category to the platform’s category, your attribute to its characteristic, your value to the permitted value. Part of it matches automatically; a person fills in the rest, once. Where the product already exists in the platform’s catalogue, we link it to the existing listing, usually by barcode (EAN), instead of creating a new one.

Message queues, retries and what you see when there is an error

Platform APIs have request limits and maintenance windows. That is why we send nothing directly: every change becomes a message in a queue, that is, a list of tasks processed one at a time in the background. If the platform does not respond, the message stays in the queue and is retried at increasingly long intervals.

Two details matter. Idempotency: the same message, sent twice, produces a single effect, so a retry does not duplicate an order. Ordering: for stock we send the current value, not the difference, so that a delayed message cannot corrupt the figure.

• Automatic retry: for temporary errors, such as hitting the request limit.
• Blocked message list: for errors that need a person (a missing mandatory characteristic, for instance), with the reason given in plain language.
• Alert: a message to the team when the queue grows unusually or when an order has not reached the stock management software.
• Periodic reconciliation: a full comparison of stock levels between systems, which catches whatever slipped past the normal flow.

How a marketplace integration runs, from accounts to the first orders

We start with an audit: what API the stock management software has, what permissions the seller account has, how many products you have. Development starts with stock and price on a small group of products, moves on to pulling in orders and only at the end deals with publishing new products.

We test in the platform’s sandbox, where one exists, then with real low-value orders. We usually use Laravel (a PHP framework with a built-in queue system), Redis (an in-memory database, well suited to queues) and webhooks (notifications a system sends when something changes).

One limit, stated honestly: if you sell a small number of products on a single channel, an off-the-shelf plugin may be enough, and cheaper. Custom code is justified when you have your own pricing rules, several warehouses or stock management software with no connector.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.