Why is there no tracking data for my shipment?
A tradeflow that stays empty almost always comes down to one of six causes. This page helps you tell them apart in about a minute, and shows what to do in each case.
Start here
Work down this list. It is ordered by how often each cause turns out to be the answer.
| # | Check | If yes, go to |
|---|---|---|
| 1 | Does the B/L or booking number return data on the carrier's own tracking page? | Reference not recognised if it does not |
| 2 | Does the carrier show the container, but nothing under the B/L? | Container-level only |
| 3 | Is the missing part a later leg, for example the final leg to the destination port? | Leg not released |
| 4 | Did you upload container numbers explicitly, or only a booking or B/L? | Import setting |
| 5 | Is the shipment missing entirely, rather than present but empty? | Never arrived |
| 6 | Is the shipment simply not in your view? | Deactivated |
1. The reference is not recognised by the carrier
The most common cause. Dockflow asks the carrier for data using the B/L or booking number you supplied. If the carrier does not recognise that number, it returns nothing, and Dockflow has nothing to show.
Three variants, all seen regularly:
- A typo in the B/L. A single wrong character is enough. One case was a missing trailing zero: the shortened number was unknown at the carrier, so tracking stopped.
- The carrier has not released the B/L yet. The number is correct but not yet active on their side. This resolves on its own once they publish it.
- The number belongs to a different shipment. Check it against the carrier's own tracking page first. That is the fastest way to separate a bad reference from a platform issue.
What to do: verify the reference on the carrier's tracking page. If the carrier returns nothing there either, correct the reference in Dockflow. Removing an unrecognised B/L makes Dockflow fall back to tracking by container number, which often recovers the shipment immediately.
If you have both a B/L and a container number, keep the container number. It is the more reliable of the two when a carrier is being difficult.
2. The carrier publishes at container level only
Some carriers return a full transport plan when you ask by B/L. Others return almost nothing at B/L level: no containers, no milestones, sometimes only the port of loading and port of discharge. The same carrier will often answer properly when asked by container number instead.
This is a property of the carrier's own data service, not of your shipment. It is more common with smaller and regional carriers.
What to do: add the container numbers to the tradeflow. Where the carrier supports container-level lookup, tracking starts from there. Note that a container-level answer is sometimes limited to the latest milestone rather than the full journey.
3. The carrier has not released that leg yet
A shipment can be tracking correctly and still show no vessel name and no ETA for the destination, because the carrier has only confirmed the earlier part of the route.
A typical case: the carrier has confirmed the deep-sea leg to the transhipment port and named the vessel for it, but has not yet decided or published the feeder leg onwards. Until they do, there is no vessel and no ETA for that leg to show. Dockflow shows what the carrier publishes.
What to do: nothing. It fills in once the carrier releases the leg.
While the final leg is unconfirmed, Dockflow still shows the ETA at the transhipment port, so you are not left without an arrival indication. Be aware this is the transhipment port and not the port of discharge. See ETA definitions for the distinction.
4. Your account only tracks containers you upload
Your account may have the setting "Do not import unknown containers from bookings and B/Ls" enabled. With it on, Dockflow tracks only the containers you explicitly include in your upload, and ignores any other container the carrier links to that booking or B/L.
The setting exists for two good reasons:
- A booking holds five containers, each belonging to a different customer, and you create a separate tradeflow per container.
- A booking holds five containers but you are responsible for only one, and you do not want the other four appearing in your dashboard.
The side effect is that if you upload only a booking or B/L and no container numbers, nothing gets tracked. It also explains missing automation emails, since there are no containers to trigger them.
There is a second, subtler case. If a shipment already has one booking and a second booking is added later, the containers on that second booking count as unknown and are skipped.
What to do: either supply the container numbers with your upload, or ask support to review the setting for your account.
5. The reference never reached Dockflow
Distinct from the cases above: the tradeflow is not empty, it does not exist. Nothing can be tracked because nothing arrived.
Two possibilities, and they are worth separating before anyone starts investigating:
- It was never sent. Support can confirm this by checking the inbound logs and files for your reference.
- It arrived but was not imported. The file reached the platform and the import step did not
produce the orders. One example: an order export began arriving with an extra
<xml>root wrapper, and the import returned zero orders for every file in that format until it was adjusted to accept both shapes.
Support checks the ingestion records directly, so this question gets a definite answer rather than an inference from what is missing downstream.
What to do: send support the reference and the approximate time it was sent. If you push data
over the API, include the request and response, and confirm the tradeflow_reference field was
set.
6. The tradeflow is deactivated
The shipment exists and has data, but it is not in your view. Dockflow deactivates a tradeflow once transport is complete, for example after the container has been returned empty, and dashboards filter to active shipments by default.
What to do: change the filter to include inactive tradeflows. If a tradeflow was deactivated while transport was still running, that usually means the reference on it described a completed journey. Check which containers actually belong to it, then ask support to reactivate it.
If none of these apply
Send support:
- the tradeflow reference, and the container or B/L number
- what the carrier's own tracking page shows, ideally as a screenshot
- when you expected the data to appear
That combination is enough to tell within one reply which of the six causes applies, or to confirm that it is none of them.
Related topics
- ETA definitions - which ETA you are looking at and why they differ
- Data quality in the console - freshness, time to first fix, and anomalies
- Source precedence - which source wins when two disagree
- Bulk import - supplying container numbers with your upload
Need help?
- Email support - [email protected]
- In-app chat - click the chat icon in the bottom right
Last updated: July 31, 2026