Carriers

The Evri rename: what to know about Hermes tracking IDs in 2026

Key takeaways

  • Hermes UK became Evri in 2022, but AliExpress data, cached carrier names, and buyers still say Hermes in 2026.
  • The rename changed the company name, tracking domain, and branding, but not the parcel network or the legacy tracking-ID formats.
  • A tracking ID that looks like Hermes is, for routing, an Evri parcel, so resolve the courier from the tracking-ID prefix rather than the carrier_name string.
  • Your mapping should treat Hermes and Evri as the same destination, normalise the display name to Evri, and flag ambiguous prefixes rather than guessing.
  • A wrong carrier hands buyers a dead tracking link, which drives item-not-received cases; Fetch Order Tracking resolves Evri from the prefix automatically.

Hermes UK became Evri back in 2022, but if you are a dropshipper in 2026 you are still tripping over the rename every week. AliExpress data lags. Old listings, cached carrier names, and supplier-side records still say "Hermes". Buyers still call it Hermes. Your tracking pages may say one thing and your sheet another. The brand changed; the mess it left in your data did not.

For an eBay seller sourcing from AliExpress, the practical question is narrow but it bites: when a parcel ships, do you correctly identify it as Evri so the buyer can track it on the right site? Get the carrier wrong and you hand your customer a tracking link that goes nowhere.

What actually changed (and what did not)

The rename was cosmetic at the brand level but messy at the data level. Here is the split that matters to you:

  • Changed: the company name (Evri), the consumer tracking domain, and the branding buyers see.
  • Did not change: the underlying parcel network, the depots, and — crucially — the tracking-ID formats that were in use under Hermes. Legacy ID patterns still flow through the same pipes.

So a tracking ID that "looks like Hermes" is, for routing purposes, an Evri parcel. The job is not to memorise a brand — it is to recognise the ID pattern and map it to the live carrier and the correct tracking URL.

The carrier name on the label is marketing. The tracking-ID prefix is the truth. When they disagree, trust the prefix.

Why AliExpress's carrier_name will lie to you

This is the part that catches people out. AliExpress's carrier_name field is notoriously unreliable — it might say a generic service, a Cainiao line, "Hermes", or nothing useful at all, even when the parcel is plainly moving on the Evri network. Relying on that string means some of your UK parcels get mislabelled and some buyers get a dead tracking link.

The robust approach is to ignore the label and resolve the courier from the tracking-ID prefix instead. We cover the general principle in why you should never trust AliExpress's carrier_name field on its own, and the specific UK codes in carrier prefix codes every UK dropshipper should know. The Evri/Hermes case is the textbook example of why prefix-based mapping beats name-based mapping.

What your carrier mapping needs to handle

To survive the rename cleanly, your mapping logic should:

  1. Treat Hermes and Evri as the same destination. Any legacy Hermes-pattern ID resolves to Evri, with the current Evri tracking URL.
  2. Match on the ID prefix, not the carrier_name string. The prefix is stable; the name field is not.
  3. Normalise the display name to Evri so your sheet and your buyer messages are consistent, even if the supplier data still says Hermes.
  4. Fall back gracefully when a prefix is ambiguous — flag it for a look rather than guessing wrong.

Do that and the rename becomes a non-event. Your buyers always get a working link, your sheet always says Evri, and you never explain to a customer why "Hermes" does not exist anymore.

Why a wrong carrier costs more than a wrong name

It is easy to dismiss this as cosmetic. It is not. A wrong carrier mapping has a direct line to your eBay metrics:

  • A buyer who cannot track their parcel is far more likely to open an "item not received" case — even when the parcel is on its way.
  • A dead tracking link generates a support message you have to answer, multiplied across every UK order.
  • Mislabelled carriers pollute your own analytics, so you cannot even tell which courier actually performs for you.

At a few hundred UK orders a month, a small mislabel rate turns into a steady trickle of avoidable tickets and the occasional defect. That is real money for a problem that is, fundamentally, a string-matching exercise.

Let the tool resolve Evri for you

Fetch Order Tracking resolves the real courier from the tracking-ID prefix — not the unreliable carrier_name — so legacy Hermes-pattern IDs are correctly identified as Evri and written to your Google Sheet with a working carrier and a valid delivery-proof link. You do not maintain the rename logic; the tool already knows Hermes and Evri are the same network.

That means every UK order lands in your sheet with the right carrier name, the right tracking status, and a proof link your buyer can actually open — automatically, across your whole batch. No more hand-correcting "Hermes" to "Evri", and no more dead links generating cases.

If you want carrier mapping that already handles the Evri rename and every other UK prefix gotcha, try Fetch Order Tracking and let it name the courier correctly so you never have to.

Frequently asked questions

Are Hermes and Evri the same carrier in 2026?

Yes. Hermes UK rebranded to Evri in 2022, and it is the same parcel network, the same depots, and the same underlying tracking-ID formats. Only the company name, the consumer tracking domain, and the branding changed, so any legacy Hermes-pattern ID should resolve to Evri with the current Evri tracking URL.

Why should I not trust the AliExpress carrier_name for Evri parcels?

The carrier_name field is unreliable and may say a generic service, a Cainiao line, Hermes, or nothing useful even when the parcel is moving on the Evri network. Relying on that string means some UK parcels get mislabelled and some buyers get a dead tracking link. The robust approach is to resolve the courier from the tracking-ID prefix, which is stable, rather than the name field.

What should my carrier mapping do to handle the Evri rename?

It should treat any legacy Hermes-pattern ID as Evri, match on the ID prefix rather than the carrier_name string, normalise the display name to Evri so your sheet and buyer messages stay consistent, and flag ambiguous prefixes for a look rather than guessing. Fetch Order Tracking does this automatically, writing the right carrier and a valid delivery-proof link to your Google Sheet so you never hand-correct Hermes to Evri.

Related guides


Try Fetch Order Tracking More guides