Offer downloads and price synchronization

Offer downloads — marketplace to us

Download requests enter the download queue, which is processed every minute. A separate mechanism schedules full downloads every few hours.

Items have a priority, from critical to background, and a source: a manual click, a schedule, or verification after a price change.

Download modes

• Full — the complete listing;
• Incremental — changes only;
• Single offer;
• Prices only — available for some channels only;
• Stock only;
• Match offers to products.

Download task and its status

Each run creates a task with a status, counters, and a heartbeat. This lets you distinguish a task that failed halfway through from one that is simply taking a long time.

Tasks without a heartbeat are considered stalled and are cleaned up periodically. If a task has been “in progress” for hours, cleanup will handle it, but it indicates that something on the channel side is not responding.

Prices — us to marketplace

A product price change enters the price queue, processed every minute, and from there goes to the change queue visible on offers (Changes and alerts — outbound queue and stock discrepancies).

Price configuration is separate for each channel + country pair. It contains the automatic synchronization switch, its mode, and frequency, as well as Test mode, which lets you see what would be sent without sending it.

This is not a connection setting. Automatic price synchronization is enabled in the price configuration, not in the integration form. Looking for it in connection settings is a common mistake — and a common reason prices “never went out”.

Empik: price is sent with the entire offer

When an offer changes, Empik (Mirakl) overwrites every field it does not receive — stock drops to zero and an active promotion disappears. Therefore, a price change on Empik first reads the offer from Empik and sends it back in full, changing only the price (or the discount during a promotion). Changing the regular price during a promotion leaves the promotion in place. If Empik quickly rejects the price (for example, because it is below the category minimum), the change fails with Empik’s reason, visible in the offer’s change queue. If Empik takes longer to process the import, a later verification decides the result: it compares the price visible on Empik but does not provide a rejection reason.

Offers with channel-specific prices or volume discount tiers are not changed; sending them without that data would erase it. The change fails with a request to make the change in the Empik panel.

During a promotion, Empik shows the discounted amount in the price field. Offer downloads save it as the promotional price and save the pre-discount amount as the regular price.

Offers without a country

Single-market channels (PrestaShop, Allegro) store offers without a country, even if a country is selected in the price configuration. Choose which price configuration prices them in the connection settings, under the price stage: Offers without a country: which price configuration should price them.

• Automatic (default) — the configuration without a country, or, if none exists, the only active configuration for the connection, even if it has a country set.
• Country (for example, PL) — that country’s price configuration. The list shows only countries with an active configuration for this connection.
• Do not synchronize — prices for countryless offers are not sent (reason countryless_offers_off).

If the configuration cannot be determined — Automatic with several country configurations and none without a country, or a country with no active configuration — the offer is skipped with reason offer_country_unknown.

The configuration also has safeguards limiting the scale of a one-off change, to prevent an incorrect price list being pushed across the entire assortment.

Net or gross — normalize before comparing

Channels do not all store prices on the same tax basis. PrestaShop stores a net price in products.price and adds VAT itself from the product’s tax-rule group; Ceneo reports gross prices; most consumer marketplaces declare neither, so the price is treated as received. On our side, the price group’s basis is the Source price basis field (net / gross) in the price configuration.

When the two sides declare different bases, the system converts the offer price to the WMS basis using the VAT rate stored with the offer (downloaded with its price — in PrestaShop, from the product’s tax rules for the store’s default country, configured under Store default country). This applies everywhere:

• Offer list and details show the marketplace price basis (for example, 1300.80 zł net) and the conversion ≈ 1599.98 zł gross. Price Δ and the discrepancy filter use the converted amount, so a net offer at 1300.80 against a gross price group at 1599.99 is a match, not “−19%”. The ≈ is intentional: the store keeps six decimal places while Noxti stores grosze, so conversion may differ by a grosz. A difference of up to one grosz counts as a match in the list, eq/ne/gt/lt filters, and the run.
• A synchronization run compares on the WMS basis and sends the amount on the channel’s basis (PrestaShop receives net, even when the group is gross). Thresholds and price-decrease/increase limits are calculated after conversion.
• An offer’s price-change request records the amount and basis the channel will receive.

If an offer has no VAT rate (PrestaShop did not respond to /tax_rules, or the webservice key lacks permission for /taxes), it is not compared when the bases differ. Offer details show a warning instead of “Prices match”; the discrepancy filter includes it; and the run skips it with reason No VAT rate to convert net/gross (tax_basis_unknown). The remedy is to refresh offers after granting the key permission, not to enter a price manually.

PrestaShop: one model price for all sizes

In a store with sizes, each PrestaShop offer is a combination (ID such as 129018-1306: model + size). The combination price in PrestaShop is only a surcharge on the model price, so Noxti changes the model price — one change updates all its sizes. Offer details for a size say this explicitly.

The synchronization run keeps this safe:

• Only one active change request is allowed per model, regardless of source: manual, bulk, or automation. A second request for another size of the same model is rejected until the first runs. Other sizes are skipped with reason Covered by model price change; that is not an error, because their price will change with the model.
• If sizes of the model have different prices in the WMS price group, the model is skipped with reason Model sizes have different WMS prices. A single model price cannot be derived; align the size prices in the catalogue.
• If any size is excluded from synchronization, the entire model is skipped (Model size is excluded from synchronization), because the change would affect it anyway.
• If the store panel has size surcharges (different prices per size), the request is rejected and lists the combinations with surcharges. Noxti does not overwrite them.
• The “below cost” threshold uses the highest purchase cost among the model’s sizes; the model price applies to all of them.
• If an offer downloaded as a regular product has since acquired sizes in the store, the request is rejected and asks you to download offers again. Otherwise it would change all the new sizes.
• If the integration sends prices to wholesale_price, changing a size price is rejected. In that column the combination has its own price, not a surcharge, so a model price change does not include it.

The price a customer sees in the store may still differ from the converted value: PrestaShop can apply its own specific prices (promotions or percentage discounts). Noxti does not manage these; remove such a difference in the store panel.

What the run compares — changed prices only or all prices

By default, the run takes only prices changed in the catalogue since the previous run (the price queue). A price manually corrected on the marketplace, or a discrepancy from before synchronization was enabled, will not enter the queue and will not be corrected.

The Compare all prices, not only changed switch in the price configuration changes this: the run reads the entire catalogue — every product with an offer on the channel — compares its price-group price with the last known offer price, and sends differences. It processes the catalogue page by page (the per-run product Limit / cycle) and remembers its position, so:

• an automatic run (each interval) handles one page per tick and traverses the catalogue over several ticks;
• Send prices now in this mode starts at the beginning of the catalogue and works page by page to the end. One click checks everything, including the promotional group if configured. A second click while it runs is rejected because a run is already in progress.

Comparison uses the last downloaded offer price, not a live marketplace request. It is only as fresh as the channel’s last offer download. Thresholds, price-decrease/increase limits, and purchase-cost protection work just as they do for queued changes.

Live run progress

On the Prices stage, under Send prices now, each configuration has a run card. During a run it shows the stage (queue / catalogue), progress and catalogue position, page count, and counters: changes sent, skipped by reason (price unchanged, below threshold, decrease over limit, below cost, no offer, etc.), and errors. After completion, the card remains as the result of the last run. Stopped responding means the run has not moved for half an hour; processing was interrupted, and the next click starts a new run.

Two card messages explain runs that appear empty:

• No prices compared — the configuration sends only changed prices, and nothing in the catalogue has changed since the last run. “Sent 0, skipped 0” does not mean the prices match. Enable Compare all prices, not only changed, save, and click Send prices now.
• Waiting in queue — the run is waiting for another channel’s offer download to finish. It will start on its own; clicking again will not speed it up.

Where to check which prices were sent

On the integration’s Prices stage. The counters are similar to stock:

• Last price sent — when something actually reached the channel;
• Sent (24 h) — changes accepted by the channel;
• In queue — items waiting, with the oldest item’s age, which shows whether the queue is stalled;
• Skipped (24 h) — items closed without sending.

Below is a list of recent changes: product, old/new price, status, and skip reason.

A green status for the last run does not mean a price was sent. It only means the run finished. The price queue has no “error” status: a price that could not be sent ends as skipped with a reason (most often “no matching offers or below threshold”). The “sent” counter comes from the offer-change queue, not the price queue, to preserve this distinction.

The panel explicitly names three calm-looking states that mean “nothing will be sent from here”:

• No configuration can send — none is enabled, uses a regular price group, and targets the channel at the same time. A promotional group alone or a “from channel to catalogue” direction is not enough; manual Send prices now is rejected too.
• Prices are not sent automatically — the configuration could send, but automation is off. Changes accumulate in the queue and go only after a manual send.
• Test mode — the run compares the catalogue with the channel but sends nothing.

Counters cover price groups used by the channel; the price queue itself does not know about channels. If another channel uses the same group, the panel says so: the same change counts for both.

Processed queue items are cleaned up after 7 days, so older changes will not be listed there. Search an individual product’s history by EAN in the synchronization console.

Order for connecting a channel

1. Download offers.
2. Match them to products (Linking a listing to a product — without it, nothing gets sent).
3. Check the warehouse mapping (Mappings — warehouses, carriers, price lists, categories).
4. Only then enable stock and price sending.

Doing this in the reverse order sends stock nowhere.