Connection configuration — steps and key settings

The connection configuration screen groups settings into steps, roughly following the path that goods and orders take through the system.

Guided and expert modes

Use the two-icon switch in the connection header to choose how to work. Your browser remembers the choice.

• Guided mode (compass). Above the steps, it shows three connection stages: Account, Credentials, Test connection, with a sentence below explaining what to do next. Once the connection works, those stages are replaced by the Go-live checklist: credentials, test, status mapping, warehouse assignment, first orders, and first offer synchronization (some steps apply only to marketplaces). Each step has a button that takes you to the relevant stage. Hide the checklist with the eye icon; reopen it from the Go-live tile in the header. A How to set it up link beside the steps opens the article for that stage.
• Expert mode (lightning bolt). No steps, checklist, or help links. Field hints remain.

In guided mode, clicking an integration under the Available integrations tab opens the wizard in a window: Account (name and Active immediately switch), Credentials (same fields as the Connection step, with Save and test) and Test connection. After a failed test, Correct details returns to the fields; after success, Go to settings opens the connection page with the checklist. Integrations that sign in through an account authorization flow (Allegro, Amazon, some accounting programs) go to the connection page after the first step — sign-in is completed there. Skip wizard, I'll set it up myself creates the connection and opens its page immediately. The wizard is not available in expert mode.

A failed connection test blocks later steps for a connection that has never worked, as do missing required fields. The error appears above the fields in the Connection step.

A mapping step with a dashed circle and Check means the system does not know yet: the mapping table loads only when you open that step.

Step by step — configure a newly created connection

Work through the steps in order. Each is a separate tab; a completed step gets the Step complete marker, and the header shows a Remaining counter — click it to jump to the first missing field.

1. Open Integrations → Integrations → My integrations and click the connection.
2. Connection step. Enter the keys, login, and addresses supplied by the channel provider. The fields depend on the connector.
3. Save. A Unsaved changes bar appears at the bottom with a counter and Discard / Save changes buttons — click Save changes. In the 2FA verification required window, enter the Verification code and click Confirm (2FA confirmation when changing permissions).
4. Click Test in the header or Test connection in the Connection step and wait for the result. Do not continue until you see Connection OK. When changing credentials, the save bar also offers Save and test, which does both steps at once.
5. Orders step. Configure order import, the default status for new orders, and automatic confirmation. Also expand Status mapping here and map the channel statuses (Marketplace order statuses — mapping in both directions).
6. Stock and products step. Set the minimum stock and linked warehouse. In the warehouse-mapping card, add at least one mapping with stock sending enabled (Mappings — warehouses, carriers, price lists, categories). Without it, stock will not be sent and nothing will tell you.
7. Prices step. Choose the price group used to calculate the price sent to the channel.
8. Shipping step. In Courier mapping, which is expanded by default, map the channel’s shipping methods to your couriers (Delivery-method mapping and shipment validation). Without this, the order arrives but cannot be packed.
9. Review the Returns and Advanced steps at the end, if the channel shows them.
10. Turn on the switch beside Test in the header when you want the connection to start working.

To find a particular setting, you do not need to browse every step — use Search settings… above the steps. A search hides mapping sections, so return to them through the relevant step.

Settings changed most often

The full set depends on the marketplace; each one can have additional parameters of its own.

Three settings worth understanding in more detail

“Sync stock with marketplace” disables both directions at once

The name suggests sending, but the field also controls offer imports from the channel. Disabling it stops both. One field, two directions (Switches that stop an entire channel).

Minimum stock is a threshold, not a buffer

The value is not subtracted. While stock is above the threshold, the full quantity is sent to the channel; when it falls to or below the threshold, the channel receives zero. With a threshold of 2 and 5 units in stock, the marketplace sees 5; with 2 units, it sees 0. This protects the last units being picked from the shelf.

A linked warehouse does nothing without a mapping

Choosing a warehouse is not enough — you also need an active warehouse mapping with stock synchronization enabled (Mappings — warehouses, carriers, price lists, categories). Without one, stock is simply not sent, with no message at all.

PrestaShop: stock is sent for products disabled in the shop, too

In PrestaShop, stock is sent to every product whose imported offer is linked to a product in Noxti — including a product disabled in the shop (inactive offer). When re-enabled, the product therefore shows current stock, not the amount from before it was disabled. You do not need to enable Send stock for inactive offers for this. A product without an imported offer, or with an offer not linked to a Noxti product, receives no stock — import offers first and check the links.

PrestaShop: order changes the shop does not flag

Some PrestaShop shops change an order (add a line item, change the shipping price) without updating its last- modified date. A normal order import will not see the change. Therefore, when Re-read open orders by number is enabled (on by default), Noxti re-reads every order from this connection created in the last 14 days every 15 minutes, unless the warehouse has packed it or it has been cancelled. Both intervals can be changed in Re-read open orders every (minutes) and … from the last (days). An unchanged order is not saved and does not appear in the history. Orders already packed are not checked this way — changing their lines after packing does not change the order anyway; it raises an issue to resolve.

Advanced step

Two things are worth noting:

• Data retention — set how long the channel keeps customer data and order files under Settings → System → Data retention, along with how much disk space each file type from this channel uses (Disk space and data retention — file usage, downloads, deletion, and how long data is kept). The step has a section with Go to data retention, which opens that tab directly at this channel’s row. The section appears for channels that receive orders (marketplaces, manual orders, SubConnect), and only for company administrators.
• Synchronization dates — an admin tool for moving the last-sync timestamp back by an hour, a day, or a week, to retrieve something that was missed. Going back a week on a large channel means a lot of traffic — use it deliberately.

Fields whose options come from the shop

Some settings store the ID of a record on the shop side — which order status means “cancelled,” which couriers deliver to parcel lockers, or which employee is recorded for a status change. These are not text fields: the system requests the list from the shop and displays names, but saves the ID. In PrestaShop this applies to six settings: statuses treated as cancelled, statuses to import, couriers with pickup points, label languages, the employee for status changes, and the shop in multistore mode. A seventh field — Shop time zone — is also a list, but comes from the time-zone database, not the shop: PrestaShop does not provide its time zone through the API, which is why this setting exists. An unknown time zone does not stop imports — the system silently uses Europe/Warsaw. The real risk is different: a shop in another time zone (for example, a German shop on Europe/Berlin or a British shop on Europe/London) left on the default value gets order dates shifted by the time-zone difference, with no warning. Check this field for shops outside Poland.

In the Prices step, PrestaShop has two more fields whose lists come from the shop:

• Shop default country (PrestaShop ID) — a list of shop countries (name, ISO code, ID). Usually leave it empty — the system reads the country from the shop configuration (PS_COUNTRY_DEFAULT). Select it only if

the webservice key does not have permission for /configurations. This country determines the product VAT rate used to convert the shop’s net price to the gross price in the price group (Offer downloads and price synchronization).

• Shop default currency — only currencies that the shop has and that are active in Noxti. A currency outside that intersection would cause every price to be rejected anyway.

Shop lists are cached for a few minutes so opening the screen does not query the shop every time. A new courier or status added in the shop panel appears in the list within about five minutes.

The ID stays visible in parentheses — Cancelled (ID: 6) — because people use numbers in the shop panel, logs, and conversations with technical support.

Three things to know:

• An empty list does not mean “the shop has no entries.” If the shop did not respond, the field shows a red message — for example, The shop rejected the Webservice key… if the key is invalid or lacks permission for that list, or The shop did not return the list… for another error. The saved configuration remains untouched. Do not force-save the form; check the connection using Test.
• A value outside the list stays selected. If the field contains an ID the shop no longer returns (a deleted courier, a renumbered status), it remains available with the label not in list. That is a prompt to change it deliberately, not to ignore it — no current order has that ID.
• Deleted couriers are not in the list. PrestaShop soft-deletes a courier so old orders can still be opened. A new order cannot use it, so it is not offered. A disabled courier is offered, since it may return after the season.

Synchronization frequency is not configured here

The Stock step has no frequency fields for marketplace synchronization — that mechanism is wired only for warehouse integrations. Marketplace schedules are set elsewhere (What syncs and in which direction).

Saving requires 2FA

Every save of the connection settings asks for a code (2FA confirmation when changing permissions).

Changing the PrestaShop shop address removes the key

The shop address must be a public http(s) address — local and private-network addresses are rejected when you save. If you change it to a different server (a different domain or port), the saved Webservice key is removed: the key authenticates on its own, without a password, so it must not reach a server other than the one it was issued for. After changing the address, enter the new shop’s key. Switching http:// to https://, adding or removing www., or saving the same address again (for example with a trailing slash or /api) does not affect the key — it is the same shop. A key entered together with the new address in one save is kept. If saving the address fails, the key is kept as well.

If the shop redirects from http:// to https:// or between the www and non-www address, data import still works but a warning appears in the logs — update the shop address to the redirect destination. Sending statuses, stock, and prices to the shop works only after that correction. A redirect to another server or path always ends with an error naming the address to enter.

A shop on a local network (for example, a test shop in Docker) can be connected only in the development environment; in production the address must be public.

The shop address also generates the product page link saved with every imported offer: <shop address>/index.php?controller=product&id_product=…&id_lang=… (for a variant, also id_product_attribute, which selects that variant on the page). The language is the same one used to import the product name. The address opens the product in every PrestaShop version, regardless of friendly-URL settings — when that option is enabled, the shop redirects to its readable URL. Offers imported earlier receive the link on the next offer import.

If the shop cannot return one order or its items, customer, or address, the other orders import normally. That one order is not created; an “order data unreadable” issue appears instead. The system retries on every import for 24 hours from the order’s last change in the shop, then only after the order changes again. If the order was already imported, it remains unchanged — only its refresh was skipped, as the issue description says. The issue closes automatically when import succeeds. Open the order in the PrestaShop panel and check its products and addresses.

Order import goes back at most 14 days. If the connection was down longer, import older orders manually by number.

The key needs GET access to: orders, order_details, order_histories, order_carriers, customers, addresses, carriers, countries, states, currencies, order_states, products, combinations, stock_availables, tax_rules, taxes, languages, employees, shops, and configurations; POST access to order_histories; PUT access to orders, order_carriers, stock_availables, and products. Missing permissions disable only the feature that needs them — without employees, for example, the employee list will not load. Exception: without order_details, orders are not imported at all (rather than being created without line items), and an issue about unreadable order data appears.

Statuses configured as cancelled prevent a new order from being created. An already imported order is cancelled in WMS only by status Cancelled (ID 6) — “Return” (7) and “Payment error” (8) do not affect it, because after a payment error the customer often pays again and the shop marks the order paid.

Product page links in other shops

Every imported shop offer stores a link to its product page — the product feed for Google Shopping uses it, among other things. Only a full http:// or https:// URL is saved; a relative, empty, or other-protocol address leaves the offer without a link.

• IdoSell — its API does not return a product-page URL, so the link is built as <shop address>/product-<language>-<product ID>.html. IdoSell opens this address and redirects to the full URL containing the product name.
  • Shop address is the Public shop address setting (Connection step) — the address customers see, for example https://sklep.example.com. Enter it in every IdoSell connection that should appear in Google Shopping: Google accepts only links from a domain registered in Merchant Center. With several shops in one panel, each connection needs its own shop address (for example https://mojsklep.cz for the Czech shop).
  • If the field is empty or is not a full http(s):// address, the link is built from domain (without the /api/… suffix). This is usually the panel address (for example …iai-shop.com); it opens the panel’s default shop, but Google will reject the link.
  • Shop language (the Shop language setting, an IdoSell code such as pol, cze, eng; default pol) determines the language used to import offer names and descriptions and to open the link.
  • If the product has a custom URL in the panel for the shop and language used by this connection, that URL is saved instead.
  • After an address or language change, offers get their new links on the next full offer import.
• Shoper — link from the shop (permalink for the product); a relative address is completed with the shop URL.
• WooCommerce — link from the shop (permalink for the variant or product).
• Shopify — product URL in the online shop; a product not published to the Online Store sales channel has no page and therefore no link.
• GoShop — its API does not provide a product-page URL; GoShop offers have no link.

Offers imported earlier receive the link on the next full offer import.

Saving and setting hints

Choose names from lists wherever the form provides predefined options. Fields that allow multiple values retain all your selections. Technical settings are in Advanced; change them according to the field description.

Saving checks, among other things, number formats, ports, and available options. If there is an error, correct the indicated fields and save again — unsaved values remain visible. Leaving the password field blank preserves the existing password.

In PrestaShop, status lists may use names saved for this account in Noxti. The form notes this below the list. After changing statuses in the shop, use Refresh statuses in the status-mapping section. If no saved list exists yet, the system tries to retrieve it from the shop.