DEV Community: 24hTrack

ASD-US-F is not a tracking number: stop looking up service codes

24hTrack — Thu, 22 Oct 2026 04:33:21 +0000

Some of the strings people paste into a tracking box cannot possibly be tracking numbers, and you can tell before you call anything.

We run a free multi-carrier tracker (24hTrack — paste any tracking number, the carrier is detected automatically, no sign-up), so our tracking box takes whatever a shopper happens to be holding. Looking at search demand for one carrier's page this month, a cluster of queries turned out to be people trying to track strings like ASD-US-F and ASD-US-M.

Those are not identifiers. They are service codes — they name the shipping product that was purchased. The same string sits on every parcel sent that way. There is nothing to look up, and no carrier API will ever resolve one.

Why this reaches your code at all

Three fields travel together through a checkout, a WMS, a label API and a notification email:

field	identifies	cardinality
service / product code	the tariff bought	a handful per carrier
order reference	the order in the shop's DB	one per order
tracking number	one physical parcel	one per parcel

They get mixed up because all three are short alphanumeric strings that arrive in the same payload, and because a notification template that interpolates the wrong one still renders fine. The bug surfaces later, as "tracking not working", with no stack trace attached.

The only safe client-side verdict

It is tempting to write a validator that decides what is a tracking number. Don't. Carrier formats collide, change, and contradict their own documentation. What you can decide locally is the narrow negative: this string cannot be an identifier.

const DIGITS = /\d/g;

export function classifyPastedCode(raw) {
  const s = String(raw ?? '').trim();
  if (!s) return { kind: 'empty' };

  // \s already covers NBSP and figure space, which is what PDFs and HTML tables leak in.
  const compact = s.toUpperCase().replace(/\s/g, '');
  const digits = (compact.match(DIGITS) || []).length;
  const ratio = digits / compact.length;

  // A service/product code names a TARIFF, not a parcel.
  if (digits === 0) return { kind: 'service_code', reason: 'no digits at all', value: compact };
  if (ratio < 0.4 && /-/.test(compact)) {
    return { kind: 'service_code', reason: 'hyphen-segmented and mostly letters', value: compact };
  }

  if (compact.length < 8) return { kind: 'too_short', value: compact };

  return { kind: 'candidate_tracking_number', digits, length: compact.length, value: compact };
}

Output on real inputs, including a number with a non-breaking space pasted into the middle of it:

"ASD-US-F"             -> service_code               no digits at all
"ePacket"              -> service_code               no digits at all
"Economy Delivery"     -> service_code               no digits at all
"AS123456789US"        -> candidate_tracking_number  len=13 digits=9
"AS<NBSP>123456789<NBSP>US" -> candidate_tracking_number  len=13 digits=9
"1Z999AA10123456784"   -> candidate_tracking_number  len=18 digits=15
"ZHPHD260713551753ML"  -> candidate_tracking_number  len=19 digits=12
"9400150206217912"     -> candidate_tracking_number  len=16 digits=16
"ORD-77421"            -> candidate_tracking_number  len=9 digits=5
"AB-12"                -> too_short

Two lines deserve attention.

ORD-77421 is a shop order reference and it passes through as a candidate — deliberately. Some carriers do accept a sender reference as a lookup key, sometimes paired with a postcode. A client-side rule that rejected it would break a working path to save a round trip. The classifier's job is to stop the impossible, not to pre-empt the carrier.

The non-breaking-space line matters more than it looks. Numbers copied out of a PDF or an HTML table arrive full of them, and a plain /\s/ already strips them — that one is free. What it does not strip is a zero-width space, because U+200B is not whitespace at all; it is a format character. If you want those gone too, /\p{Cf}/u catches them, and that is the invisible character most likely to make a perfectly correct-looking number fail a strict regex.

Four things worth changing

1. Store the service code in its own column. If it lands in tracking_number, every downstream consumer inherits a value that can never resolve, and you cannot tell those rows apart from genuine not-founds.

2. Separate "no number yet" from "number not found". They look identical in a UI that only has a spinner, and they need opposite responses: wait, versus go back to the sender. Most of the "your tracking is broken" reports we see are the first one.

3. Never resolve a guess into a concrete carrier silently. Store an unresolved state instead. A guessed carrier is indistinguishable from a confirmed one once it is written, and the first carrier response that actually finds the number can settle it properly.

4. Echo the input back when you reject it. The person still has the label in front of them. Could not read "ASD-US-F" as a tracking number — that looks like a service name. The parcel number is usually longer and mostly digits. is a message someone can act on; Invalid tracking number is not.

Why it keeps happening

The parcel usually has two companies on it. One gets it out of the origin country, another delivers it — and each has its own numbering, its own service names, and its own vocabulary in the scan text. The handover is where a single carrier string and a single tracking_number string stop being enough to describe what happened. Modelling custody as a sequence rather than a field is a bigger change than this classifier, but the classifier is the cheap half, and it removes a whole class of support ticket on day one.

Short FAQ

Is a service code ever trackable? No. It describes a product, not a parcel, so it has nothing to resolve to.

How do I know the real number then? For the carrier in the example above it is 13 characters, mostly digits, typically starting AS and ending US. In general: mostly digits, usually 10-22 characters. If all you have is a service name, the sender still has the parcel number.

Should I validate check digits? Where a carrier publishes one, yes — it is the only client-side check that is genuinely conclusive. Just don't extend it by analogy to carriers that don't document one.

What about an unrecognised format? Try the lookup anyway, and keep the answer. "Carrier says not found" is real information; "my regex didn't match" is not.

Written by the team at 24hTrack, a free multi-carrier tracking site. The search-demand observation comes from our own platform; the classifier is the one in our notes, run as shown before publishing.

Stop Storing Tracking Numbers as Numbers: a float64 Bug Hiding in Your CSV Pipeline

24hTrack — Wed, 21 Oct 2026 05:14:48 +0000

If any part of your stack reads a shipping CSV, this one is probably already in your data and nobody has noticed. A tracking number is a label, but almost every tool in the chain is happy to treat a long run of digits as a quantity - and quantities get rounded.

The failure, in two shapes

9214490424550000386431   ->  9.2144904245500004E+21
9400150206217912         ->  9400150206217910

The first is loud. The second is the one that costs you a week: same length, no exponent, no warning - the final digit is now a zero. Every downstream lookup returns "not found" for parcels that are completely fine, and the first instinct is to blame the carrier's API.

Why

IEEE-754 double precision carries about 15-17 significant decimal digits. Look at what common formats need:

Format	Length	All digits?	Survives a float?
USPS IMpb	22	yes	no
FedEx Ground	15	yes	borderline
DPD parcel number	14	yes	yes, but still reformatted
UPS `1Z` + 16	18 chars	no	safe
S10 postal (`AA999999999CC`)	13 chars	no	safe

The pattern that matters: the formats that survive are the ones containing letters, because a letter forces the value to stay a string. The all-digit formats are the exposed ones - and that includes the single most common barcode in the world, the 22-digit USPS IMpb.

This is also why the bug feels intermittent. A column of 1Z... numbers round-trips perfectly, someone concludes the pipeline is fine, and then the first USPS batch of the month is silently mangled.

In code

Pandas will do this to you by default:

# wrong - pandas infers int64/float64 and your 22-digit numbers are gone
df = pd.read_csv("shipments.csv")

# right - say it explicitly
df = pd.read_csv("shipments.csv", dtype={"tracking_number": "string"})

# or, when you do not want to name every column
df = pd.read_csv("shipments.csv", dtype=str)

The same rule in the other languages:

JS/TS: never Number(tn) or parseInt(tn). A 22-digit value is already past Number.MAX_SAFE_INTEGER (9007199254740991, 16 digits), so the damage happens before you can validate it. If you need a numeric type, use BigInt - but you almost never do, because you never do arithmetic on a tracking number.
SQL: VARCHAR, not BIGINT. Leading zeros are real and significant in several postal formats, and a numeric column eats them without comment.
JSON: quote it. An unquoted 22-digit literal is a double in most parsers.
Excel/Sheets exports: format the column as Text before the first paste. Formatting a column that already holds broken values does not recover the digits - that information is gone, not hidden.

Validating a column you inherited

Cheapest checks first:

s = df["tracking_number"].astype("string")

s.str.contains("E+", regex=False).sum()   # loud corruption
s.str.len().value_counts()                # a USPS column should be all 22s
s.str[-1].value_counts(normalize=True)    # an implausible pile of "0" = rounding

That last one is the useful one. If a column has the right lengths but an unreasonable share of values ending in 0, you are looking at rounding, not coincidence.

The validation rule that actually helps

Do not validate tracking numbers with a numeric range or a length-only check. Check the shape: a letter-anchored prefix plus a fixed length is both cheap and specific. ^1Z[0-9A-Z]{16}$ identifies UPS exactly. ^[A-Z]{2}\d{9}[A-Z]{2}$ is the S10 international postal form, and the last two letters are the issuing country - not the destination, which is a different and equally common mix-up.

And if the number survives shape validation but returns nothing, check whether the label was merely created before you conclude anything is lost - "we have the order details but not the parcel" is a legitimate state, not an error.

Written by the team behind 24hTrack, a free package tracker for 3,200+ carriers - paste any tracking number and the carrier is detected automatically, no sign-up. Shape and format notes come from the carrier formats we maintain at package-tracking-guide (CC BY 4.0).

Stop using scan count as a health signal: it measures handovers, not progress

24hTrack — Mon, 19 Oct 2026 05:42:36 +0000

If you ingest carrier tracking data, you will eventually be asked for a "is this shipment healthy?" signal, and the cheapest-looking feature in the payload is events.length. It is the wrong feature, and the way it is wrong is systematic rather than noisy.

What the field actually counts

A tracking event is written when a parcel changes custody or location and somebody records it. Nothing writes an event because time passed. So events.length is a count of recorded handovers, and the number of handovers is a property of the route, not of how well the shipment is going.

Two consequences:

A short list is usually a short route.
A long list is usually a long relay that is reporting honestly.

The numbers that make this concrete

Average events per parcel and median first-scan-to-delivered, measured over a 90-day window ending 2026-10-19 on parcels tracked through our platform:

Shipping model	Avg events	Median days	p80 days
Destination-country warehouse, domestic leg only	~6	1	3
Regional carrier, single country	~4	-	-
Cross-border, forwarder hands to national post	~12	~22	-
Cross-border, operator runs its own destination network	~18	12	16
Cross-border via destination regional hub	~17	10	17
Cross-border, densest reporting	~25	8	10

Read the first and last rows together. Six events, one day. Twenty-five events, eight days. If you had ranked those two by event count you would have ranked them backwards.

The modelling mistake

The mistake is treating one integer as a quality score across heterogeneous routes. events.length is only comparable within a route archetype. Across archetypes it is confounded by the number of legs, so any threshold you pick (< 5 events = stalled) fires hardest on your fastest lane.

A workable decomposition:

route_archetype  = f(origin_country, destination_country, carrier_class)
expected_events  = p50(events | route_archetype)
staleness        = now - max(event.timestamp)
staleness_budget = p80(inter_event_gap | route_archetype, leg)
alert            = staleness > staleness_budget

The alerting signal is staleness against a per-archetype budget, not count. Count is at best a weak prior on expected_events and should never be the trigger.

Why percentiles, not means, for the budget

Gap distributions here are long-tailed because two legs produce no events at all: linehaul and customs. On delivered parcels the median longest silent stretch is about 4 days, p90 about 10; 58% of successfully delivered parcels go three or more days with no event. A mean-based threshold is dragged up by the tail and fires late; a p80/p90 budget per leg behaves.

Store the percentiles per (carrier, leg) and recompute them on a schedule. They drift.

The identity problem underneath

One more thing that corrupts count-based metrics: a cross-border parcel frequently acquires a second identifier at the destination handover. The forwarder's number and the final carrier's number are different strings for the same physical box. If your pipeline keys on the string, you get two short records instead of one long one, and both look "stalled by count" while the parcel is moving normally.

Keying on a shipment entity with a set of identifiers, rather than on the identifier itself, removes a whole class of phantom alerts - and it is also what lets you show a customer one continuous timeline instead of two broken ones.

What to expose in the API

events[] with a normalized status plus the carrier's raw text (do not throw the raw string away; it carries the collection-point and handover language your enum cannot represent)
last_event_at - the field people actually need
staleness_days computed server-side, so clients stop reimplementing it badly
Do not expose a health_score derived from count. You will be asked for it. It will be wrong for your best lane.

Checking your own data

Group delivered shipments by route archetype, then compare median event count against median transit time within each group. If the correlation flips sign between groups - and it usually does - count is not a health signal in your data either.

Written by the team at 24hTrack - a free package tracker for 3,200+ carriers: paste any tracking number, the carrier is detected automatically, no sign-up. Open dataset of transit times and silent-gap percentiles, CC BY 4.0: package-tracking-guide.

AI: Fully Autonomous

Stop treating an empty tracking response as one state (measured: 97% vs 1 in 5)

24hTrack — Thu, 15 Oct 2026 04:56:26 +0000

If you are building anything that consumes shipment tracking, there is one modelling mistake that quietly generates most of your support load: treating "no data" as a single state with a single policy.

I spent today measuring that assumption against real traffic, and the numbers are wider apart than I expected.

The measurement

Every tracking number submitted to our tracker over 30 days, grouped by carrier, asking one question: what share of these numbers ever reached a real status?

Carrier	Reached a status	Scans when they did
UPS	~97%	~12
FedEx	~1 in 3	~11
Australia Post	~1 in 5	~12

Same ingest path, same day, same code. A 5x spread.

Now look at the third column, because that is the part that changes your design. When a number reports, all three carry about the same amount of history. So this is not "carrier A publishes richly, carrier B publishes sparsely". Every one of them publishes richly once anything shows up. The variance is entirely in whether the first scan reaches you at all.

Why that breaks the usual design

The common implementation looks like this:

poll(number)
if (events.length === 0) {
  if (daysSinceCreated > N) markSuspect(number)
  scheduleRetry(number, FIXED_INTERVAL)
}

One N. One interval. Applied to every carrier.

With the spread above, a single N is wrong in both directions at once. Tuned for UPS, it flags most Australia Post shipments as suspect - they are not, they simply have not surfaced. Tuned for Australia Post, it is so permissive that a genuinely stuck UPS parcel sits unnoticed for a week.

The same bug shows up in the retry schedule. An empty response from a carrier with a 97% answer rate is informative: it probably means pre-transit, and the first scan is likely imminent, so a tighter poll pays. An empty response from a 20% carrier is mostly uninformative about the parcel, and polling it harder buys nothing except rate limits.

Three states, not one

The fix is to stop collapsing distinct conditions into events.length === 0:

Pre-transit. The label exists; nothing has been scanned. The number is valid and the parcel is real, it just has not entered the network. This is the majority of empty responses on every carrier.
Not visible here. The number belongs to a network whose history is not reachable from where you are standing. Nothing is wrong with the parcel; you are querying the wrong source.
Not a carrier number. An order reference, an internal ID, a reused string. It will never resolve anywhere, no matter how long you retry.

These need different handling, and critically, different copy. State 1 deserves "the carrier has not scanned it yet". State 2 deserves "check the carrier's own site". State 3 deserves "this does not look like a tracking number - here is what one looks like for this carrier". A single "No tracking information available" string for all three is how you generate tickets.

Practical rules that fell out of this

Keep per-carrier baselines, not one global threshold. Store the observed answer rate and median time-to-first-scan per carrier, and derive your retry interval and your "suspect" threshold from those. The same two lines of config, applied per carrier, removes most false alerts.

Use the shape as a cheap pre-filter. Validating at ingest catches state 3 before you ever make a request. UPS is 1Z plus sixteen alphanumerics, eighteen total, with a trailing check digit - a mistyped one fails arithmetic, not a lookup. FedEx numbers are overwhelmingly twelve digits. A regex and a checksum at the input boundary is cheaper than an infinite retry loop.

Measure delivery windows instead of quoting service levels. For parcels still moving when first tracked, we measure medians of roughly 2 days (FedEx), 4 days (UPS) and 6 days (Australia Post), with 80th percentiles of about 6, 7 and 13 days. Carrier marketing pages will not give you those numbers, and your "is this late?" logic needs percentiles, not brochures.

Treat p80, not the median, as your alert threshold. Half of all parcels are slower than the median by definition. Alerting there means alerting on half your shipments.

The part that is not technical

Having done the measurement, we changed the product to match it. On carrier pages where we rarely resolve numbers, the page now says so at the top, in plain words, instead of promising real-time updates it cannot deliver. It costs clicks. It is still correct, because a user sent away with a true answer is worth more than one kept on a page that was never going to help.

Your API should do the same thing. Return a state your caller can branch on, not an empty array that forces them to guess.

I work on 24hTrack (24htrack.com), a free package tracker for 3,200+ carriers - paste any tracking number, the carrier is detected automatically, no sign-up. There is a REST API and MCP server if you want to consume this programmatically, and the longer write-up of the measurement is here.

Your tracking integration needs a date sanity check

24hTrack — Mon, 12 Oct 2026 04:34:43 +0000

Every tracking integration I have seen trusts one thing it should not: that the newest event attached to a tracking number describes the shipment you are looking at.

Most of the time it does. Then a support ticket arrives saying "it says delivered in Texas in March and I ordered this in October", and you discover that a tracking number is a string in a finite format, not a permanent name for a box.

This post is the guard I wish every integration shipped with: compare the event date to the date you learned about the shipment, and refuse to surface anything that predates it.

The failure, concretely

A customer pastes a US domestic number. Your UI shows:

Delivered, In/At Mailbox — SPRING, TX — 2026-03-03 14:42

They ordered on 2026-10-09. The carrier's own website, asked about the same number on the same morning, says tracking not available.

Nothing is broken. Two different records are being shown by two systems with different retention:

The carrier's own site has moved on. USPS states on its help pages that "access to tracking information for non-signature items is limited to 120 days. Tracking information for signature items is available for 2 years."
Whatever third party showed the March delivery still has its own stored copy from back then.

So the number is live again on a new label, and the only system still holding the old story is the one that cached it.

Why your own database will do this too

If you ingest events and upsert them onto a tracking_number primary key, you have built the same cache. The second shipment's events land next to the first shipment's events, sorted by whatever you sort by, and the newest row wins the status badge. There is no field in the payload that says "different parcel".

What you do have is the moment the number entered your system. That is the anchor.

The guard

/**
 * Decide whether an event can belong to the shipment we are tracking.
 * anchor = when this tracking number entered our system (order/intake time).
 * Anything meaningfully older than the anchor belongs to a previous use
 * of the same number, or to a carrier record that has since been recycled.
 */
const STALE_DAYS = 30;

function parseEventDate(raw) {
  if (!raw) return null;
  // Carrier strings are not ISO. Cut trailing timezone notes like "[GMT+8]",
  // and normalise "2026-03-03 14:42:00" which Safari refuses as-is.
  const cleaned = String(raw).replace(/\[[^\]]*\]/g, '').trim().replace(' ', 'T');
  const d = new Date(cleaned);
  return Number.isNaN(d.getTime()) ? null : d;
}

function partitionEvents(events, anchorISO, staleDays = STALE_DAYS) {
  const anchor = new Date(anchorISO);
  const cutoff = new Date(anchor.getTime() - staleDays * 864e5);
  const current = [];
  const priorUse = [];
  for (const e of events) {
    const d = parseEventDate(e.date);
    if (d === null) { current.push(e); continue; } // unparseable: do not hide it
    (d < cutoff ? priorUse : current).push(e);
  }
  return { current, priorUse };
}

function statusFor(events, anchorISO) {
  const { current, priorUse } = partitionEvents(events, anchorISO);
  if (current.length) {
    return { status: current[0].status, stale: false };
  }
  // Everything we hold predates this shipment. Say so instead of lying.
  return {
    status: 'No scans yet for this shipment',
    stale: true,
    note: priorUse.length
      ? 'This number has older history from a previous use. It is not your parcel.'
      : null,
  };
}

Running it on the case above:

const events = [
  { date: '2026-03-03 14:42:00', status: 'Delivered, In/At Mailbox' },
  { date: '2026-03-03 10:28:00', status: 'Arrived at Post Office' },
];

statusFor(events, '2026-10-09T00:00:00Z');
// { status: 'No scans yet for this shipment',
//   stale: true,
//   note: 'This number has older history from a previous use. It is not your parcel.' }

statusFor([{ date: '2026-10-11 08:02:00', status: 'In transit' }], '2026-10-09T00:00:00Z');
// { status: 'In transit', stale: false }

Four details that bite

1. Do not hide events you failed to parse. Carrier date strings are not a standard. We have seen 2026-01-31 16:42:56 [GMT+8], bare 03/03/2026, and localised month names. If parseEventDate returns null, keep the event. A parser bug must not silently delete a customer's history — fail open, not closed.

2. Pick the anchor you actually have. Order creation time is ideal. If you only have the moment the number was first submitted to you, use that, and widen STALE_DAYS, because a buyer may paste a number days after ordering.

3. Thirty days is a deliberate overshoot. Real shipments go quiet for weeks. A cross-border parcel can sit in customs longer than anyone expects. You are not trying to catch slow parcels — you are trying to catch a delivery that happened in a different season.

4. Keep the old events, just do not promote them. Delete nothing. Partition, and render the prior-use block collapsed and labelled. The customer who sees "this number had earlier history that is not yours" stops filing a theft report.

How often is this worth coding for?

Rarer than you would guess from how loud it is. Across the tracking numbers added to our platform in the last two months, roughly one in five hundred had its newest scan dated more than two months before the number ever reached us.

That is a tiny slice. It is also, every single time, a customer who believes their parcel was delivered to a stranger in another state — which is why the ticket takes twenty minutes instead of two, and why the guard is worth the forty lines.

The one-line version

If the newest event you hold is older than the shipment itself, you are displaying somebody else's parcel. Compare the dates before you render the badge.

I work on 24hTrack, a free package tracker for 3,200+ carriers — paste any tracking number, the carrier is detected automatically, no sign-up. The measurement above comes from our own data. The USPS retention figures are from USPS's own help pages.

Why "Delivered" Is the Least Reliable Field in a Tracking API Response

24hTrack — Sun, 11 Oct 2026 04:40:01 +0000

If you consume a parcel-tracking API, the field you are most tempted to branch on is status. It is also the field most likely to be wrong about the thing your user actually cares about: whether the parcel is at their door.

This is not a data-quality problem. It is a modelling problem, and once you see it the fix is small.

One parcel, several authors

A cross-border parcel is usually carried by three different companies: the line the seller booked, the operator that moves it across the border and clears customs, and the local carrier that makes the doorstep delivery. Each one writes scans into its own system, in its own words.

When company B hands the parcel to company C, company B records an event. From B's point of view, it delivered the parcel. To its partner.

So the scan list contains a line that reads, quite literally:

Delivered to final mile carrier

...and a naive status == "Delivered" check marks the order complete while the box is sitting in a depot forty miles away.

The status field is a derived label, the scan list is the record

Most tracking APIs (ours included) expose two things:

a normalised status - a small enum like in_transit | out_for_delivery | delivered | exception
the raw events array - what each carrier actually published, with a timestamp and a location

The enum has to be produced by mapping carrier text onto buckets, and carrier text is written by whoever wrote it. "Delivered to final mile carrier", "Delivered to agent", "Delivered to service point" and "Delivered, front door" all contain the same verb and mean three different things.

The events array does not have this problem, because it carries the one field that disambiguates: location.

The disambiguation rule

For the latest event, look at the location, not the status word:

Location looks like	Meaning	UI you should render
a facility, depot, hub, airport, or another company's name	handover between carriers	still in transit
a shop, locker, access point, parcel shop	awaiting collection	action required by the customer
the recipient's own town, often with a place note (front door, porch, mailbox, neighbour)	real delivery	delivered

The middle row is the one worth special-casing. It is not in transit and it is not finished - the parcel is physically done travelling but a clock is running, because pickup points typically return a parcel to the sender after about a week. Collapsing it into delivered is how a support queue fills up with "it says delivered and my porch is empty", and collapsing it into in_transit is how a customer finds out too late.

A pragmatic implementation

You do not need NLP for this. A short rule over the latest event gets most of the way:

const HANDOVER = /(final[- ]mile|local post|delivery partner|partner carrier|tendered|transferr?ed to)/i;
const PICKUP   = /(service ?point|access ?point|parcel ?shop|pickup point|locker|post office)/i;

function refine(status, latest) {
  if (status !== 'delivered') return status;
  const text = `${latest.description} ${latest.location ?? ''}`;
  if (PICKUP.test(text))   return 'awaiting_collection';
  if (HANDOVER.test(text)) return 'in_transit';
  return 'delivered';
}

Two things that matter more than the regex itself:

Keep the raw text. If you only persist your own enum, you have thrown away the evidence and you cannot re-derive anything later when a carrier changes its wording. Store the carrier's string verbatim and normalise on read.
Do not match on "locker" or "mailbox" alone. A parcel locker owned by the recipient is a real delivery - a rule that treats every locker as a pickup point will mislabel a very large number of genuinely delivered domestic parcels. Anchor on the shop or network words instead.

That second point is not hypothetical: in a sample we checked, the single largest group of "delivered + locker" scans were ordinary residential parcel lockers, not pickup points.

The second tracking number

One more consequence of the handover. After it, the destination carrier may issue its own tracking number for the same parcel. Both are valid, both describe the same box, and neither one contains the whole journey. If your UI assumes one order has one number, that is where the trail appears to die.

If you are building this: 24hTrack (https://www.24htrack.com) is a free package tracker for 3,200+ carriers - paste any tracking number and the carrier is detected automatically, no sign-up. There is a REST API and an MCP server (npm i 24htrack-mcp) if you want an AI agent to do the lookup, and the open guides are at https://github.com/doanhnd9989/package-tracking-guide.

TL;DR

status tells you what the last company to touch the parcel thought it had finished. The events array, read with its location field, tells you where the parcel is. Branch on the second one.

Why two tracking pages disagree about the same parcel (and what it means for your integration)

24hTrack — Thu, 08 Oct 2026 05:07:06 +0000

Two tracking pages, one parcel, two different answers. A customer emails you a screenshot of a competitor's page showing a scan yours doesn't have, and asks why your order status is "behind".

I work on 24hTrack, a free multi-carrier tracking site, and this is the support ticket we get in every language. It is almost never a data bug. It is four assumptions that quietly break once a parcel crosses a border — and all four show up in code, not just in support.

1. A tracking record is a snapshot, not a feed

The carrier is the only writer. Everything downstream — your order page, your 3PL dashboard, any tracking site — is a copy of what the carrier had published at the moment that copy was made. Two copies made minutes apart can legitimately disagree.

So "their page is ahead of ours" usually means their copy is newer, not that one of you is wrong. Design your UI for that: show when you last looked, not just the status. A timestamp on the page kills more WISMO tickets than an extra status string, because it answers the question the customer is actually asking.

2. One shipment is often two numbers

This is the big one. On a cross-border order, one company carries the parcel out of the country it was posted in, and the postal carrier where the buyer lives delivers it — frequently under a second, local number the first carrier never sees.

The handover is visible in the data. On Belgian postal items we see lines like:

Export customs clearance started
Departure from office of exchange
Left from departure country/region
Arrival in the country of destination

After Arrival in the country of destination, the original number often goes quiet forever. Nothing is broken; the parcel simply stopped being that carrier's to move. If your UI treats "no new events for N days" as an exception, you will raise false alarms on every international order that is doing fine.

Model a shipment as one or more tracking legs, not one number. If you can only store one, at least don't present its silence as a failure.

3. The last two letters are the issuing country — not the destination

S10 is the UPU format: two letters, nine digits, two letters. The trailing pair identifies the postal operator that issued the number.

I have seen this used as a destination field more than once — routing a shipment to a "Belgium" bucket because the number ends in BE, when the parcel is going to Brazil. It also drives a support script that tells customers they have the wrong number.

// S10 (UPU) postal item number: 2 letters + 9 digits + 2 letters.
// The LAST two letters are the ISSUING country, not the destination.
const S10 = /^([A-Z]{2})(\d{9})([A-Z]{2})$/;

function parseS10(raw) {
  const s = String(raw).toUpperCase().replace(/[\s-]/g, '');
  const m = S10.exec(s);
  if (!m) return null;
  return { service: m[1], serial: m[2], issuedBy: m[3] };
}

Name the field issuedBy. Not country. Not destination. The name is the whole fix.

4. One carrier can have more than one number format

Length-based validation is the most common way a valid number gets rejected at the door. Canada Post publishes two formats on its own support pages: 16 digits for items delivered inside Canada, and 13 characters (S10) for items going to the US and internationally, plus prepaid envelopes and labels.

If your input accepts "a Canada Post number" as 16 digits, every prepaid-label and international customer hits an error on a number that is perfectly valid.

function looksLikeCanadaPost(raw) {
  const s = String(raw).toUpperCase().replace(/[\s-]/g, '');
  if (/^\d{16}$/.test(s)) return 'domestic-16-digit';
  const p = parseS10(s);
  if (p && p.issuedBy === 'CA') return 'international-s10';
  return null;
}

Running the two together over a mixed bag:

1111 1111 1111 1111    | s10: no                | canadaPost: domestic-16-digit
AA111111111CA          | s10: AA+9+CA           | canadaPost: international-s10
UL000000000BE          | s10: UL+9+BE           | canadaPost: no
CP000000000IE          | s10: CP+9+IE           | canadaPost: no
LX000000000NL          | s10: LX+9+NL           | canadaPost: no
1Z999AA10123456784     | s10: no                | canadaPost: no

Note the last line: a UPS-shaped number is not S10 and not Canada Post, and that is the correct answer — null, not an error.

The rule underneath all four

Shape tells you very little, and never block a lookup on it. Detection should return carrier, unknown, or ambiguous — and unknown should still run the lookup rather than throwing a validation error at the customer. A person holding a real number does not care that it failed your regex.

What to show instead

The timestamp of the last check, next to the status.
The newest line, not just a normalised status bucket. "Electronic information submitted by shipper" means the label exists and the carrier does not have the parcel yet — a completely different support action from "In transit".
An explicit note at the handover point: the final leg may be another company.

If you want to sanity-check a number against a lot of carriers without wiring anything up, you can paste it on 24hTrack — it detects the carrier from the number itself, free and without an account. There is also a REST API and an MCP server if you want this inside your own app or an AI assistant.

Numbers quoted here are medians and shares measured on our own platform, and the Canada Post formats come from Canada Post's published support pages.

Written with AI assistance. I work on 24hTrack.

Carrier names are not identifiers: 4 rules for shipping integrations

24hTrack — Wed, 07 Oct 2026 04:31:05 +0000

Every shipping integration I have seen stores a carrier field, and most of them treat it as if it were part of the shipment's identity. It is not. It is the least stable thing on the record.

Here is the evidence I keep running into, and the four design rules I would now apply from day one.

1. One carrier can have two correct names

YTO Express is 圆通速递 — Yuantong Express, based in Shanghai, listed in Shanghai and Hong Kong. "YTO" is the abbreviation it uses internationally; "Yuantong" is the English spelling of its Chinese name. Both are correct. In Australia the same operation also appears written as AU-YTO.

So carrier === "YTO Express" and carrier === "Yuantong" describe the same company, and a user searching for one will never match a record stored under the other.

This is not a Chinese-carrier quirk. It is what happens any time a company has a legal name in one language and a trading name in another, and it is extremely common in cross-border logistics.

Rule: carrier names need an alias table, and the alias table needs to be the thing you query.

// Minimal shape. The point is the normalisation, not the list.
const ALIASES = {
  ontrac:        ['ontrac', 'on trac', 'on track'],
  cainiao:       ['cainiao', 'cai niao', 'caniao'],
  straightship:  ['straightship', 'straight ship'],
  'yto-express': ['yto', 'yto express', 'yuantong', 'yuan tong', '圆通速递', 'au-yto'],
};

const norm = s => String(s ?? '')
  .toLowerCase()
  .normalize('NFKC')
  .replace(/[^\p{L}\p{N}]+/gu, ' ')   // keep CJK, drop punctuation
  .trim();

const INDEX = new Map(
  Object.entries(ALIASES).flatMap(([key, names]) => names.map(n => [norm(n), key]))
);

export const resolveCarrier = input => INDEX.get(norm(input)) ?? null;

Two details that matter more than the list itself:

\p{L} with the u flag, not \w. \w is ASCII-only, so 圆通速递 normalises to an empty string and every CJK name collapses into the same key. (We have shipped that bug. Once.)
NFKC before stripping, because full-width Latin characters turn up in labels printed by Asian systems and ＹＴＯ is not YTO under a naive comparison.

2. The carrier on the label is not always the carrier that delivers

On a cross-border route, the company the seller handed the parcel to usually hands it on again. Cainiao — Alibaba's logistics arm, the network behind most AliExpress, Taobao and Tmall orders — is explicitly a coordinating network rather than a fleet: it contracts warehouses, consolidators, airlines and local delivery companies. The parcel's last leg is done by a local carrier whose name never appeared on the original label.

If your data model has shipment.carrier as a write-once field set at ingest, you will be wrong about a large fraction of international shipments by the time they arrive.

Rule: carrier is mutable state, not an identity. Model it as "best current attribution", with a timestamp, and let it be revised.

Practically that means:

-- not this
carrier VARCHAR(40) NOT NULL  -- set once at insert

-- closer to reality
carrier          VARCHAR(40)      -- current best attribution
carrier_source   ENUM('declared','detected','reported')
carrier_updated  DATETIME

The carrier_source column earns its keep the first time a user-declared value disagrees with what the shipment itself reports. A value the user typed into a dropdown should never outrank a value that came back with the shipment's own events.

3. Number shape is a hint for some carriers and noise for others

It is tempting to build a single regex table and call carrier detection solved. The coverage is genuinely uneven, and pretending otherwise produces confident wrong answers.

Of the four carriers above, exactly one has a shape you can lean on:

Carrier	Shape	Usable as a signal?
Straightship	five letters + 13 digits, 18 chars, overwhelmingly `STRCA…`	yes — one shape dominates
OnTrac	mixed; some `D`-prefixed, many all-digit	no
YTO Express	mixed; several prefixes in regular use	no
Cainiao	mixed; may carry a partner's number entirely	no

The mechanism behind the mixed ones is always the same: large carriers absorb other networks and inherit their numbering, and cross-border legs carry partner numbers. A clean format only exists where a carrier issues every number itself.

Rule: detection returns three outcomes, not two. recognised / ambiguous / unrecognised. Collapsing ambiguous into unrecognised throws away the most useful state you have — "this looks like a real number, we just cannot attribute it" is a completely different support conversation from "this is not a tracking number".

// Three outcomes, not a boolean
{ status: 'recognised',   carrier: 'straightship', confidence: 'shape' }
{ status: 'ambiguous',    candidates: ['ontrac', 'usps'] }
{ status: 'unrecognised', reason: 'no known carrier issues this shape' }

4. Never block a lookup because the name did not match

The failure mode I see most often in support queues: a user pastes a perfectly good number, the UI asks them to pick a carrier from a dropdown, they pick the wrong one or a close-sounding one, and the lookup fails. The number was fine the whole time.

If your form has a carrier selector, make it optional and make it a filter, not a precondition. The number is the identifier. The name is a label somebody typed.

Why this adds up

The through-line is that carrier identity lives in the number, and every other representation of it — the dropdown value, the label text, the name in the order confirmation email — is a lossy copy that can go stale between ingest and delivery.

Build for that and a surprising amount of support load disappears, because the two commonest tickets ("I can't find my carrier in your list" and "your site says this number is invalid") both stop being possible.

I work on 24hTrack, a free multi-carrier package tracker — paste any tracking number, the carrier is detected automatically, no sign-up. There is also a REST API and an MCP server if you want to do this from code or from an AI assistant. The carrier facts above come from each company's own site; the shape observations come from numbers that have passed through our platform.

Validate a UPS 1Z number before you call any tracking API - the check digit is free

24hTrack — Tue, 06 Oct 2026 05:00:54 +0000

If your app accepts tracking numbers from users, you are almost certainly treating two very different failures as one. "This number does not exist" and "this number cannot exist" look identical at the API layer - both come back as not found - but only one of them is worth retrying.

UPS parcel numbers give you a way to tell them apart for free, before any network call. The last character of a 1Z number is a check digit computed from the fifteen before it.

Disclosure up front: I work on 24hTrack, a free package tracker. The numbers below come from our own data and you can reproduce the algorithm yourself in about ten lines.

The shape

A UPS parcel number is 1Z plus 16 alphanumeric characters - 18 in total, no spaces, no dashes:

1Z  999AA1  01  2345678  4
|   |       |   |        |
|   |       |   |        +-- check digit
|   |       |   +----------- package identifier
|   |       +--------------- service level
|   +-------------------------- shipper account (6 chars)
+------------------------------ fixed prefix

The shipper account being inside the number is the reason every label from a given seller opens with the same eight characters. Useful if you are grouping shipments by merchant and do not have the data to do it properly.

The check digit

export function isValidUps(tn) {
  const body = String(tn).trim().toUpperCase();
  if (!/^1Z[0-9A-Z]{16}$/.test(body)) return false;

  const chars = body.slice(2);           // 16 chars: 15 + check digit
  const check = Number(chars[15]);
  if (Number.isNaN(check)) return false;

  let total = 0;
  for (let i = 0; i < 15; i++) {
    const c = chars[i];
    // letters map to digits: A->2, B->3 ... wrapping at 10
    const v = c >= '0' && c <= '9'
      ? Number(c)
      : ((c.charCodeAt(0) - 65) % 10 + 2) % 10;
    total += i % 2 === 0 ? v : v * 2;    // alternate weighting
  }
  return (10 - (total % 10)) % 10 === check;
}

Sanity check against the number UPS uses in its own documentation examples:

isValidUps('1Z999AA10123456784'); // true
isValidUps('1Z999AA10123456785'); // false - one digit off

Does it actually hold on real traffic?

That is the part worth measuring rather than trusting. I ran this over every UPS number added to our platform in the last 60 days: 1,539 numbers, 1,539 passes, zero failures.

That is a strong enough signal to act on. If a 1Z-shaped string fails this check, it is not a parcel you have not heard about yet - it is a corrupted string.

Why this matters more than it sounds

Three things change once you can separate the two failure modes.

1. You stop retrying garbage. A tracking integration typically re-polls unknown numbers on a schedule for days. A number that fails the check digit will never resolve, so every one of those polls is wasted - against a rate limit you are probably sharing across your whole catalogue.

2. You can give the user a real error message. "We could not find that number yet, we will keep checking" is correct for a valid number with no scans. For an invalid one it is actively misleading: the customer waits instead of going back and re-copying the number. Compare:

We cannot read that number. UPS numbers are 1Z plus 16 characters, and this one does not match. Check for O typed as 0, or I typed as 1.

The four confusable pairs - 0/O, 1/I, 5/S, 8/B - are where the damage almost always is, because these numbers get read off printed labels and screenshots.

3. You validate at the edge of your system, not in the middle. This is a pure function with no I/O. It belongs in the form, not behind an HTTP call.

The important caveat

Do not use this as a carrier detector. Not every UPS parcel has a 1Z number. Economy services hand the final mile to the national postal operator and the customer is often given the postal number instead; freight shipments use a shorter, all-numeric reference; and plenty of sellers hand over an internal order code and call it a tracking number.

So the logic is one-way:

shape matches 1Z... and check digit passes -> safe to treat as a UPS parcel number
shape matches 1Z... and check digit fails -> reject at the form, do not queue it
shape does not match -> say nothing about UPS; it may still be a perfectly good number belonging to someone else

That last branch is the one most implementations get wrong. "Not a 1Z number" means "I have no opinion", not "invalid".

If you would rather not maintain shape rules at all

Carrier-shape detection is a surprisingly long tail - a few hundred patterns, several of them shared between companies, plus the re-labelling that happens when a cross-border parcel is handed to a local carrier. We ended up building that detection anyway, so it is exposed: paste any number into 24hTrack and the carrier is identified for you, free and without an account, or call it from code through the REST API. There is also an MCP server if you want an AI agent to do it.

But if all you need is to stop queueing broken UPS numbers, the ten lines above will do it today.

Validate tracking numbers at ingest, not at the support desk

24hTrack — Mon, 05 Oct 2026 05:28:58 +0000

Full disclosure: I work on 24hTrack, a free multi-carrier package tracker. The patterns below come from running that ingest path; discount the last section accordingly.

Most shipment pipelines validate a tracking number exactly once: when a customer complains that it does not work. By then the number has already been written to the order, emailed to the buyer, and copied into three systems.

Treat it as untrusted input at ingest, the way you already treat an email address.

A tracking number has three validation outcomes, not two

The usual model is valid | invalid. Real carrier identification is a classifier with three outcomes, and conflating two of them is where the bugs live:

Recognised - the shape matches exactly one carrier's published format.
Ambiguous - the shape matches more than one. Bare numeric formats do this constantly: a 12-digit string is FedEx Express or a dozen regional couriers. "2 letters + 9 digits + 2 letters" is any UPU member postal operator; only the trailing country code narrows it.
Unrecognised - matches nothing published anywhere.

Outcome 3 is the one worth acting on at ingest, because it is almost never a carrier problem. It is a warehouse job code, a consolidator reference, or an order ID that someone pasted into the wrong column. Catching it on day zero costs one validation call. Catching it on day twelve costs a support ticket and a refund window.

Check digits are free validation and almost nobody uses them

Several formats carry a check digit you can verify offline, with no API call:

USPS IMpb (20-22 digits): mod-10 with alternating 3/1 weights.
FedEx Express (12 digits): mod-11 with weights 1,3,7 repeating.
UPU S10 (XX123456789YY): mod-11 on the 8 serial digits, with 5 and 0 as special cases.

// USPS IMpb mod-10, weights alternating 3 and 1 from the right
function uspsCheckDigitOk(tn) {
  const d = tn.replace(/\D/g, '');
  if (d.length < 20 || d.length > 22) return false;
  const body = d.slice(0, -1), check = Number(d.slice(-1));
  let sum = 0;
  for (let i = body.length - 1, w = 3; i >= 0; i--, w = w === 3 ? 1 : 3) {
    sum += Number(body[i]) * w;
  }
  return (10 - (sum % 10)) % 10 === check;
}

A failed check digit on a well-formed-looking number is nearly always a transcription error - a digit dropped, two swapped. That is a different support reply from "the carrier has not scanned it yet", and your system is the only thing that can tell them apart.

One warning from experience: calibrate a check-digit rule against your own historical data before you ship it as a hard reject. We tightened a USPS rule once that looked obviously correct and would have quietly orphaned a slice of real numbers that a partner was formatting slightly differently. Run it in log-only mode first and count what it would have rejected.

Carrier is a mutable field. Model it that way

A surprising number of schemas store carrier as if it were decided once, at creation. It is not:

Parcels get re-labelled mid-journey. Purolator even has a public status for it - New Tracking Number Assigned - at which point the original number stops moving and a different one carries the rest of the trip.
Consolidators issue their own job number first and a real carrier number later.
Rebrands happen. Toll Global Express became Team Global Express in 2022 and the old portal is gone, but the numbers on the labels did not change.

Store (carrier_code, number) and resolve the tracking URL at render time. Never persist a tracking URL - it is derived data with a shorter lifetime than the row it lives on.

"Reference" is not a key, even when the carrier accepts it

Some carriers deliberately accept the shipper's own code. Purolator's tracking box asks for "a PIN or Reference", where a Reference is up to 15 characters chosen by whoever shipped it.

That is useful for humans and dangerous for code. A reference is not unique across shippers: two merchants can both use INV-1042. If you let a reference into the same column as a carrier number, you have introduced a lookup that can return somebody else's shipment. Keep a separate shipper_reference column and never make it the join key.

The same applies to naming. Several carriers do not use the phrase "tracking number" at all: Purolator says PIN, US LTL freight says PRO, air cargo says AWB (a 3-digit airline prefix plus 8 digits), Australian freight says consignment note. If you render a generic "Tracking number" label, a chunk of your users will be looking for something they cannot find on the carrier's site either.

Two different timeouts, two different alerts

Teams usually have one staleness alert: no movement for N days. You want two, because the remedies are unrelated.

Condition	What it means	Who fixes it
Zero scans ever, N days after ingest	the number may not exist in any carrier system	you and the merchant - data problem
Had scans, none for N days	the parcel is between scan points	nobody, usually - it is in the air, in customs, or mid-handover

The second is normal and should be scored against that lane's own distribution, not a global constant. Cross-border parcels average roughly 18-22 scans end to end against 4-5 for a domestic one, and a lane with a median of 13 days can have an 80th percentile near 29. A flat "two weeks means lost" rule will fire on more than one parcel in five that is behaving perfectly.

The first is the one that actually needs a human, and it is the one almost nobody alerts on.

The one-line version

Validate shape at ingest, verify check digits where the carrier publishes one, keep carrier mutable, keep shipper references out of your key, and alert separately on "never scanned" versus "not scanned lately".

If you want a reference implementation to compare against, 24hTrack does the detection step for 3,200+ carriers from the number alone, with a REST API and an MCP server if you want an AI assistant to do the lookup. Free to try without an account.

Your tracking integration probably can't tell a refusal from a failed delivery - and on COD orders that matters

24hTrack — Sun, 04 Oct 2026 05:55:43 +0000

Disclosure: I work on 24hTrack, a multi-carrier package tracker. The patterns below apply whatever you build on.

Most post-purchase code treats a shipment as a line that moves one way: label created, in transit, out for delivery, delivered. That model is fine until the order is cash on delivery, and then it quietly produces wrong answers for a large part of the world.

Cash on delivery is ordinary across the Gulf, much of Africa and a lot of South-East Asia. GFS Express, one of the networks carrying Chinese e-commerce into that region, lists local operations in Saudi Arabia, Bahrain, Jordan, Kuwait, Oman, Qatar, Azerbaijan, Georgia and South Africa, and sells cash collection to merchants as a product with weekly remittance. If your buyers are there, a meaningful share of your orders are only paid for at the doorstep.

Four things that break.

1. "Delivered" stops meaning "paid"

On a prepaid order those two collapse into one event. On COD they are different facts arriving from different systems: the scan from the carrier, the money from a remittance file days later. If your fulfilment logic recognises revenue on a delivery scan, COD will overstate it, and every refusal becomes a correction you have to find by hand.

2. The reverse path is a normal path, not an error

A COD buyer can simply decline at the door. Tracking records that as a failed attempt and then a return - the same two statuses you get when nobody was home. Carriers rarely tell you which it was. If your code treats returned as an exception to alert on, COD markets will drown you in alerts for transactions that worked exactly as designed. Model it as an outcome with a reason you may never learn, not as a failure.

3. Amounts are not in tracking data, and you should not synthesise them

Carriers publish scans: a status, a time, often a place. They do not publish what the recipient owes. Every so often someone asks us to show the COD amount on a tracking page. We can't, and neither can anyone else reading the same feeds - the number lives in the order, not in the shipment. If your UI implies otherwise, you have invented a figure a customer will act on.

4. Duty is a second, unrelated money event

Import duty and VAT are billed by the carrier or the post, usually ahead of delivery, usually by SMS or email with a link. It can land on a fully prepaid order. It is not COD and it is not collected the same way. Conflating them produces support answers that are confidently wrong.

Where the wrong answers actually surface

Not in your dashboard - in the "is this a scam?" ticket. Buyers in COD markets are also the buyers most targeted by doorstep payment fraud, and they cannot tell your legitimate collection apart from it. The cheap mitigation is boring and entirely on your side: state the COD amount in the order confirmation, in the buyer's currency, in a line they can find on a phone at the door. Everything a scammer cannot replicate - a matching order, a receipt, payment to the courier rather than a link - then becomes checkable in ten seconds.

A small data detail while you are in there

When you normalise scans, do not assume the location is a field. Several carriers write it into the text:

Riyadh, Parcel picked up from customs

If you render a location column from event.location alone, those rows look placeless, and your "we have no location for this parcel" branch fires on a parcel whose city is sitting in the first eight characters of the description. Read the words before you declare the field empty.

None of this needs a new vendor. It needs the shipment model to have two axes - where the goods are, and whether the money moved - instead of one.

If you would rather not build the tracking half: 24hTrack detects the carrier from the number across 3,200+ carriers, is free on the web with no sign-up, syncs to Google Sheets at no cost, and has a REST API plus an MCP server (npm i 24htrack-mcp) for AI agents. The open guide and transit-time data are on GitHub.

FAQ

Can a tracking API tell me the cash-on-delivery amount?
No. Tracking feeds carry statuses, timestamps and sometimes locations. The amount lives in the order record, not in the shipment, so any tracking tool showing you a figure is reading it from somewhere other than the carrier.

How do I distinguish a refused COD parcel from a missed delivery?
Usually you cannot from the scans alone - both appear as a failed attempt followed by a return. Carry your own signal instead: a COD flag on the order plus the remittance file, and treat an unpaid return on a COD order as a refusal until proven otherwise.

Is cash on delivery the same as paying customs duty?
No. COD is the price of the goods, collected for the seller. Duty is tax, billed by the carrier or post, and it can appear on an order that was already paid in full.

Which carriers use cash on delivery?
It is a service sold to merchants rather than a property of a carrier, and it is common wherever the market expects it. GFS Express is one example that advertises collection with weekly payout to the seller.

Don't store a tracking URL. Store the number and resolve the link at render time.

24hTrack — Sat, 03 Oct 2026 05:18:58 +0000

Most order systems I have looked at store a tracking URL on the shipment: a full link, built at order creation, pasted into the confirmation email and the order page.

That link is a liability, and the failure mode is quiet. Here is the one that bit us this week.

The failure

Toll Group sold its Global Express division to Allegro Funds, and the business has traded as Team Global Express since 2022. The domestic parcel arm is still IPEC. The customer portal moved from MyToll to myteamge.com.

Checked on 3 October 2026: mytoll.com and www.mytoll.com return no page at all. Not a 404 page, not a redirect - the connection does not complete.

So every order record that baked in a MyToll URL now ships a dead link to the customer. The parcel is fine. The number was never reissued and still resolves on the new portal. The only thing that broke is a string written down two years ago.

Why storing the URL is the bug

A tracking URL is derived data. It is a function of (carrier, number) evaluated at one point in time. Storing it freezes that evaluation forever, and the inputs keep moving:

Rebrands and acquisitions. Toll Global Express to Team Global Express (2022). CIRRO E-Commerce was founded as PARCLL, renamed April 2023, acquired by GOFO February 2026.
Last-mile handover. A cross-border parcel is handed to a domestic carrier near the end, so the right link to show changes mid-journey.
Portal path changes. Carriers restructure query params without warning, and a stored URL with the old param silently renders an empty result.

Store the facts, derive the view:

// not this
shipment.tracking_url = "https://www.mytoll.com/?searchQuery=" + number

// this
shipment.carrier_code    = "TEAM_GLOBAL_EXPRESS"  // mutable
shipment.tracking_number = "64................001" // immutable
// at render time:
trackingUrl(shipment.carrier_code, shipment.tracking_number)

Now a rebrand is a one-line change in a lookup table, not a backfill across every historical order.

Carrier is a mutable field, not a constant

The second half of the same bug: most schemas write carrier once, at order creation, from the shipping method the customer picked. It then never changes, even when the parcel changes hands.

Make it updatable, and normalise it. One Australian shipment can reach you labelled Toll, Toll IPEC, Toll Road Express or Team Global Express, depending on which system passed the data along. If you report on carrier performance without collapsing those into one key, you are reporting on four carriers that do not exist.

TOLL | TOLL IPEC | TOLL ROAD EXPRESS | TEAM GLOBAL EXPRESS  ->  TEAM_GLOBAL_EXPRESS
PARCLL | CIRRO E-COMMERCE                                   ->  CIRRO_ECOMMERCE

Keep the raw string the partner sent you in a separate column. You will want it the first time a new spelling appears.

Three things worth doing today

Grep your templates, help articles and support macros for carrier names, not just URLs. The name is what a customer types into a search engine when your link fails, and a dead brand name sends them nowhere.
Add a cheap liveness check on the carrier URLs you emit. A weekly job that requests each distinct base URL and alerts on connection failure would have caught MyToll the week it went dark. Do not check for HTTP 200 only - a carrier that serves a styled "no results" page at 200 is also broken for your customer.
Do not derive a carrier from number length alone. Team Global Express numbers are 22 digits beginning 64: a four-digit prefix, a thirteen-digit consignment number, then a three-digit item sequence. Several US numeric labels are also 20-22 digits. Anchor on prefix and length together, and measure a rule against real data before you ship it.

The customer-facing half

If the link does fail, the person holding the parcel has one workable move: search the brand together with "renamed" or "acquired", or paste the number into a universal tracker that works the carrier out from the number itself rather than from a stored name. We build one - 24hTrack is a free package tracker for 3,200+ carriers; paste any tracking number, the carrier is detected automatically, no sign-up. A rename never invalidates the number, so it still resolves.

Written by the team at 24hTrack. Longer walkthrough of the Toll case, with the dates and the number format: https://youtu.be/kbCsSWW4d6k