Sending stock to the marketplace
The fastest pipeline in the system — its queue runs every few seconds. It also has the most conditions a product must meet to enter the queue.
A stock change enters the stock-send queue, which is processed every few seconds. This is the shortest interval in the system.
How the stock level is calculated
Stock in the linked warehouse is compared with the minimum stock level: above the threshold, the full quantity is sent; at or below it, zero is sent. The result is then subject to exclusion rules for the product–channel pair (Offer exclusions — stock rules per product and channel).
That is why the number on the marketplace almost never exactly matches warehouse stock — and that is expected.
Conditions for entering the queue
The product must meet all of these conditions:
- the connection is active;
- stock sending is enabled — and because it requires offer downloading to be enabled, both switches must be on (Switches that stop an entire channel);
- there is an active warehouse mapping with stock synchronization enabled;
- the product has a linked, active offer, if the channel requires one;
- the product is not excluded for this channel.
If any condition is not met, the product does not enter the queue at all. You will not see a rejected entry; there will be no entry (Switches that stop an entire channel).
Queue item statuses
Statuses appear in Synchronization console — where to see what is happening. The labels below match the screen:
| Screen status | Meaning |
|---|---|
| Pending | Waiting to be sent |
| In progress | Being sent now |
| Sent | Accepted by the marketplace |
| Failed | Failed; will be retried |
| Permanently failed | All attempts used |
| Skipped | Deliberately skipped |
Failed items are retried with increasing delays, and items stuck In progress are periodically unlocked. One failure does not require action from you; only Permanently failed means you should investigate.
Items also have priority: a movement after a sale is sent before a routine refresh.
The duplicate-offer trap
An ended or blocked offer that shares a key with a live offer can block the live offer’s entry until it is permanently rejected or cleared after several days.
Symptom: stock does not update for one product while the rest of the channel works normally (Marketplace offer — our local mirror of a listing).
Kaufland: several markets on one connection
One Kaufland connection can serve several markets (DE, CZ, SK, PL, AT, FR, IT). Stock and price are sent separately for each market where the offer is listed:
- a product marked unavailable in a country gets zero for that market; a country excluded from the minimum-stock rule gets stock without a threshold;
- an offer whose market cannot be determined is skipped on a connection with several markets (its queue item ends as skipped), rather than sent to a guessed market — the same offer ID can belong to a different offer in another market. With one market, it is sent there;
- a price in a currency other than the market currency (for example, PLN for Germany) is rejected; Kaufland would interpret the number as euros;
- an offer no longer found by Kaufland (404) is marked ended and removed from stock sending;
- nothing is sent to a market unchecked on the connection, even if the offer exists there;
- a connection with no market selected sends nothing, and the connection test reports this;
- Kaufland request limits (429) and temporary outages (503) do not use up attempts: the batch is deferred and retried;
- if Kaufland rejects credentials (401), sending the batch stops at that offer instead of repeating the same error for each item. The remaining items end with “not sent” and are retried like other failures; each uses one attempt.
OTTO: stock and prices
- Stock is sent to OTTO in batches of up to 150 products per request. If OTTO rejects a batch because one product is invalid, the system splits it and continues; only that product fails, not the whole batch. If OTTO rejects the whole request regardless of products, the whole batch is marked for retry without splitting it into hundreds of individual requests.
- A queue item without a readable quantity fails on its own.
- OTTO request limits (429), outages on their side (5xx), and no response do not use up attempts: the batch is deferred and retried; after a 429, the whole channel waits as long as OTTO requires.
- Changing the regular price does not remove an active promotion. OTTO always accepts the full price record, so the system first reads the active promotion and sends it with the new price. If the promotion cannot be read or its amount is unclear, the price change is paused and retried rather than silently removing the promotion. A product OTTO does not return at all receives only the price. A promotion ends only when it is explicitly removed, or when the regular price is lowered to the promotion price or below: then the promotion no longer makes sense and OTTO would reject it, so only the new price is sent.
- Reading one offer (for example, to check its price) does not reset its saved stock level.
History
Old queue contents are archived, and archives can be searched (Synchronization console — where to see what is happening). An entry from months ago has not disappeared; it is in the archive.
Want to see this with your orders? We’ll show you NOXTI with your sales channels and warehouse.
Book a demo