Where statuses come from — polling carriers

Statuses do not arrive from the carrier on their own. The system contacts the carrier, using a recurring background task, and asks about a batch of parcels at once. None of the connected carriers sends us notifications (webhooks).

Practical consequence: a status is only as fresh as the last poll — not as fresh as the carrier’s event.

Step by step — check whether the connection asks the carrier at all

When all parcels from one carrier are stuck while others work, check one setting. It is not visible on the tracking screen — you must open the connection configuration.

1. Go to Integrations → Integrations and stay on the My integrations tab.
2. Open the carrier connection whose parcels are stuck.
3. In the stage list on the left, select Shipping. Its description is Assign delivery methods to your carriers and fulfilment warehouses. The setting is in its Deliveries group.
4. The Search settings… field above the stage list is a faster way to find it. > Type Fetch, not “tracking”. The switch is called Fetch Tracking Numbers and has no Polish translation — you cannot find it using the Polish word. If nothing matches, search responds No settings match your search.
5. Check the switch. When it is off, all parcels from this connection are skipped on every run, with no message and no trace in the shipment list.
6. If you cannot access integration settings, ask an administrator — this cannot be determined from the Tracking module.
7. After enabling it, do not keep refreshing the list. Statuses appear only on the next background run; an administrator sets its frequency in the schedule.

The refresh button does not poll the carrier

The refresh icon on the list reloads only the saved view. The system has no button or URL that forces a carrier to check one parcel. Clicking refresh repeatedly will not make anything faster.

Which parcels are polled

The background task does not ask about every parcel. It considers a parcel only when all of these conditions are met:

The post-final window is measured from the carrier event date, so fetching the same event again does not extend it. A parcel younger than the window is always checked — a backdated carrier event does not take away its last chance. Separately, a parcel stalled at a “not collected” or “delivery refused” code is polled until the carrier reports a return, without the three-day limit. The 30-day limit from parcel creation still applies (see missing shipment status update).

Slowing down “dead” parcels

A parcel with Initial status that is older than 3 days is no longer polled on every run — the system checks it only every 4 hours. This is deliberate: a parcel that has not moved from stage zero for three days was most likely never physically handed over, and polling it uses up the carrier’s request limit.

Schedule

How often statuses are checked depends on the schedule in your deployment. You cannot read it from this screen — ask NOXTI support for details.

Polling is done in batches of 50 parcels at a time, separately for each carrier connection, with a one-hour lock preventing the same connection from running twice in parallel.

What one poll records

Each new carrier event is saved as a separate history entry with its date and carrier code. If the carrier returns the same code as last time, nothing is saved and no workflow automation runs — automations respond to changes, not polling runs.

The history is visible on the order card (Shipment on the order card — full history and actions), not on the shipment list.