A valid tracking number that returns nothing: two carrier facts that break order lookups

If you have ever built or maintained an order-tracking feature, you have seen this ticket: the customer has a real tracking number, your lookup returns nothing, and everyone assumes the parcel is lost. Usually it is not. Two documented carrier behaviours cause most of it, and both have consequences for your schema.

Disclosure: I work on 24hTrack. Written with AI assistance.

1. Corporate ownership is not a tracking namespace

FedEx acquired TNT in 2016, and tnt.com today carries FedEx's own property notice plus the line "TNT will become FedEx". It is natural to conclude that a TNT number is now a FedEx number. It is not. TNT's own FAQ still states:

FedEx shipments can be tracked at fedex.com, and TNT consignment tracking is available at tnt.com.

One group, two tracking systems. If your integration routes by company rather than by number issuer, you will send TNT consignment numbers to a FedEx endpoint and get an empty result that looks exactly like a missing parcel.

The lookalike-name version of the same bug: Team Global Express is not a renamed TNT. Its own About page says it began as Team Global Express following its acquisition from Toll Group, with a heritage going back to Albert F Toll in 1888. Routing on a fuzzy brand-name match will happily send a consignment to the wrong carrier.

Takeaway: resolve the carrier from the number and the sender, not from the brand name on the order.

2. Short numbers are recycled, so they are not unique keys

TNT documents that the eight- or nine-digit numbers used to track parcels get reused every three or four weeks. That is a carrier statement, not an inference.

If you did this:

CREATE TABLE shipment (
  tracking_number VARCHAR(40) PRIMARY KEY,  -- bug
  order_id        BIGINT,
  status          VARCHAR(32)
);

then a recycled number collides with an order from last month. Depending on your upsert you either reject a real shipment or silently overwrite a historical one.

CREATE TABLE shipment (
  carrier         VARCHAR(40) NOT NULL,
  tracking_number VARCHAR(40) NOT NULL,
  shipped_on      DATE        NOT NULL,
  order_id        BIGINT      NOT NULL,
  PRIMARY KEY (carrier, tracking_number, shipped_on)
);

The same applies to caching and webhooks: key events by carrier + number + ship date, and treat scans dated before the order as belonging to a previous shipment rather than as a time-travelling update.

A two-line triage for support

1. Do the scan dates start after the order date? If not, it is the recycled earlier parcel.
2. Does the tool match the issuer? A TNT consignment number needs TNT's tool.

That closes a lot of tickets without opening a claim.

24hTrack (24htrack.com) is a free package tracker for 3,200+ carriers - paste any tracking number, the carrier is detected automatically, no sign-up. It also has a REST API and an MCP server if you want an AI assistant to do the lookup. The carrier notes above are on the TNT page.