Importing orders from a marketplace

Orders reach the system only by polling the marketplace. Channels do not send notifications; nothing arrives “by itself” at the moment of purchase.

Step by step

Check when this channel last fetched orders

1. Open Integrations → Integrations, tab My integrations, and open the connection.
2. The header tiles include Last sync with a date and time. This is the quickest check.
3. For more detail, open the Advanced stage and its Synchronization dates section (marked Admin). It has Last order download and Last offer synchronization, each with a date.
4. A dash beside Last order download means the import has never run for this connection. On a new deployment, this is the most common reason nothing arrives.

Move the import window backwards

1. In the same Synchronization dates section, each row has three buttons: -1h, -1d, and -7d.
2. They move the last-download marker backwards, so the next run looks further back and brings in orders that fell outside the previous window.
3. This is an administrative tool — hence the Admin label. Do not click it to “speed up” an import: it does not start anything immediately; it only widens the range for the next run.
4. If the date does not move forward by itself over many runs, moving it backwards will not help. One order is holding the marker because it fails to import every time. Find and fix that order in Tickets, with NOXTI support if needed; then the date will advance on its own. For Shoper, a wider window has a cost: each order in it requires a separate store request for its items, so a very wide window may exceed a run’s time limit. The system skips orders already seen with the same status and amount, but the first run after moving the marker back is still heavy.
5. Saving asks for a 2FA code.

Configure import behavior for a channel

1. On the connection screen, open the Orders stage. Its hint says: “How orders from the integration enter WMS and how their statuses map to yours.”
2. Settings are grouped into sections. Import rules are under Import orders from marketplace (“Order download rules, including handling unpaid orders”); unpaid-order handling is under Unpaid orders; confirmation, statuses, invoices, and tracking numbers are under Marketplace settings.
3. Available fields differ by channel; that is based on the data, not the screen code. To find a parameter, use Search settings… above the stage list (Sales channel — integration, connection, and setting).
4. Save changes with Save changes in the bottom bar. Saving asks for a 2FA code.

Check what arrived

1. Open Synchronization console — where to see what is happening and its Orders stage.
2. The table has Channel number, System number, Status, Their status, and When. Their status is the raw value from the marketplace; Status is yours after mapping.
3. A separate status-mapping table shows On channel → In system pairs. An order with a status missing from the table silently receives the default value; see Marketplace order statuses — mapping in both directions.

When orders do not arrive

A correctly configured connection is not enough; the import must run periodically. If synchronization dates do not change and no new orders appear, check tickets and contact NOXTI support.

What controls the import

Automatically adding products — use with care

When enabled, an unknown product on an order creates a new product record. This prevents an order being blocked by a missing SKU, but clutters the catalogue if mapping is not monitored. Enable it deliberately and review what gets created.

Status during import

Marketplace statuses are mapped to yours using the mapping table. An unknown status silently falls back to default; see Marketplace order statuses — mapping in both directions. Revisit the table a few days after connecting a new channel.

Orders with multiple parcels

When an order ships in several parcels, some connectors send only one tracking number to the marketplace. The others are lost even though shipping is recorded as completed. If customers on a channel report that the second parcel has no tracking number, this is why.

Kaufland: cancellations and tracking numbers

• If the entire order is cancelled on Kaufland, the next import also cancels it in the system, provided cancelled maps to the cancelled status. An order is considered cancelled only when every line is cancelled. If some goods have already shipped, the shipped status remains.
• Cancelling part of an order (for example, 1 of 2 units) reduces the line quantity and trims the picking queue. If picking or packing for that line has already started, the entire order leaves the queue (anything already packed stays packed), and the goods return to the bulk location. The order returns to the queue with the new quantities in the next cycle. A return after the queue has been delivered does not trigger this. Note: automatic import does not refresh order lines by default, to avoid restoring lines removed manually. Exception: if the marketplace changed a line (product, quantity, or price) since the previous import, the next import fetches the lines and removes the excess. Manual refresh with products and the products section in orders_auto_refresh_sections do the same.
• Line changes after packing. If the marketplace changes lines in an already packed order, the system does not change the lines. It creates the ticket “Marketplace changed the order lines after packing”. Compare the order with the marketplace and, if needed, stop shipment. Orders imported before this feature was introduced receive a baseline only on their first import after deployment; nothing changes for them.
• Parcels with different carriers in one order: Kaufland accepts one carrier per line, so the system refuses to send tracking numbers and returns an error (only parcels whose number has not yet been sent are considered). Enter the numbers in the Kaufland panel.
• If no Kaufland line is still waiting to ship (it has shipped, been delivered, or cancelled), a tracking number is not sent and the system does not mark it as submitted. A manual send returns “skipped”. Add a tracking number for an extra parcel on an already shipped order in the Kaufland panel.
• Cancelling from the system fails if any Kaufland line has no identifier. Cancel the remaining lines in the Kaufland panel.

OTTO: units, cancellations, and order total

OTTO handles orders unit by unit: each unit is a separate line with its own fulfilment status.

• A cancelled unit (CANCELLED_BY_PARTNER or CANCELLED_BY_MARKETPLACE) enters the system with quantity 0 and cancelled status. It is excluded from the order total, and its tracking number is not included; OTTO would reject the entire shipment. Picking-queue trimming works as for Kaufland: after a manual refresh with products or when the connection has products in orders_auto_refresh_sections. A zero-quantity line does not enter the picking queue or change the order type (one live unit is still SINGLE).
• An entire order cancelled is also cancelled in the system on the next import if CANCELLED_BY_PARTNER and CANCELLED_BY_MARKETPLACE map to the cancelled status. Without those mappings they silently fall back to the default. An order that is not yet in the system is not created.
• The order total is the sum of non-cancelled units plus all delivery fees. Previously delivery was excluded, so the line total did not match the payment and order confirmation stalled.
• An order where no unit has a readable price is not imported as a zero-value order. The import stops at that order and retries in the next cycle; the reason is in the worker log.
• Manual refresh of an OTTO order searches by OTTO’s order identifier (salesOrderId), not the number shown to the customer.
• Only one tracking number per order is sent to OTTO. Enter the second parcel’s number in the OTTO panel.

Payments

Some channels let the system check whether an order was paid and automatically move it to the next status. Others require manual confirmation.

Confirmation is not payment

Confirming an order on the marketplace does not mean the money has arrived. They are separate events, and on some channels they happen in the opposite order to what you might expect.

On Empik and Modivo, the customer is charged only after the seller accepts the order. So:

order arrives  →  we accept it  →  ~45 seconds  →  marketplace charges customer
                                                   ↑
                                      only NOW is the order paid

That is why a newly accepted order from these channels stays briefly in the unpaid status. That is expected. It leaves that status automatically at the next import after the charge (the import cycle is usually a few minutes).

If the order remains there longer than a dozen minutes, the marketplace has not collected payment. A declined card is the most common reason. Keep the order waiting; do not release it manually “to get it moving”, or the goods will ship for free. This has happened: two Empik orders were picked and packed even though the customer never paid.

Practical note: these channels also provide buyer details — phone and address — only after the charge. An unpaid order has no address label to print and stops at packing with a missing phone number or postal code. This is the same lack of payment showing up another way, not a separate fault.

Empik courier delivery. A pickup-point order (Empik store or parcel locker) already has the point name before acceptance, so it enters the system and is then accepted. Before acceptance, a courier order has neither a pickup point nor an address, so there is not enough information to create it. Therefore, with auto_confirm enabled, the system accepts it in Empik immediately during download, before it enters the system. Empik charges the customer and releases the address; the order arrives on the next import. With auto_confirm off, you must accept the order manually in the Empik panel. Until then, it will not appear in the system and does not block other imports.

An order rejected in Empik (manually or after the acceptance deadline) that is not in the system is skipped; there is nothing to send. A rejected or cancelled order that already exists in the system still arrives and is cancelled in the system if REFUSED/CANCELED maps to the cancelled status, as with Modivo. If picking or packing has started, the system does not cancel it automatically; it creates a ticket. Shipping an order Empik did not accept or cancelled fails instead of silently appearing as “already sent”. The system will not mark such an order as confirmed, even if it tries to accept it afterward. Workflows triggered by confirmation (courier order, ERP document) will not run for an order Empik did not accept.

Manual channel

The Manual channel polls nothing. Use it for orders entered outside integrations so they follow the normal warehouse process.