By Janson Wang, founder of ASG Dropshipping | Shopify documentation read 2026-08-17, sources re-checked 2026-09-14
Shopify tracking looks different from one order to the next for a structural reason. One order can be split into several fulfillments.
Each fulfillment carries its own carrier and its own tracking fields, as of August 2026.
What a buyer sees is decided by that one segment rather than by your storefront as a whole.
Scope: one store, several suppliers, and what the customer can actually see. Not lost parcels, not transit times.
This is not always a tracking-app problem, and it is not always a fulfillment-splitting problem.
Check four things in order: the fulfillment split, the tracking fields, the customer-side rendering, and the event feed.
They are four checks, not four separate diseases — one order can be sitting in more than one of them.
Key Takeaways
You do not have one Shopify tracking problem. You have one for each fulfillment flow you run — a supplier or integration, a carrier service, a label source. Your customer sees them side by side, in the same store.
Four checks decide what each buyer sees. How many segments the order is split into (Split). Whether the number, the tracking company and the tracking URL describe the same parcel (Field). What the customer-side page shows (Render). Whether shipment events keep arriving (Feed).
Each check is answered in a different place. The admin gives you the split and the stored values, and reading the admin alone does not prove what the customer sees. Field correctness shows when you open the link, Render shows on the customer-side page, and Feed shows on a shipment you watch over time.
Some Shopify tracking differences are unified by presentation, some by a service that carries its own carrier data, and some cannot be unified at all. Shopify itself states that tracking event sources, accuracy and timing vary by carrier.
By now you are probably sorting your own store into these problems and finding it hard. The right question is not how to unify tracking.
It is which differences can be unified at all.
To answer that, you need to know which layer a difference lives in. Here are the four.
Each layer measures one thing, on purpose. They are four checks rather than four mutually exclusive faults, so one order can fail more than one of them at the same time.
A model that blends two meanings reads smoothly, then fails the moment you classify something with it.
The Four Layers That Decide What Customers See
Layer
What this layer measures
Where you can see it
Split
How many fulfillment segments this order is cut into
Shopify admin, on the order page
Field
The tracking number, the tracking company and the tracking URL, and whether all three describe the same parcel
Admin shows the values; whether they match shows when you open the link
Render
How Shopify displays that shipment to the buyer: live status and a map, or a bare outbound link. Two separate Shopify pages feed this, one for clickable links and one that Shopify points at for automatic status updates
Customer-side order status page
Feed
Whether shipment events keep arriving, and at what level of detail. Carrier, carrier service, fulfillment app behaviour and label source can all affect it
A live shipment, watched over time
Illustrative. The four checks are dimensions, not four separate faults — one order can sit in more than one of them. Sources, in order. Split rests on the fulfillment service guide plus the order-splitting help page.
Field rests on the tracking input reference plus the order tracking help page. Render rests on the order status page documentation and on the two Shopify pages it depends on.
Feed rests on the Shopify staff answers in the developer forum, plus what a live shipment shows you.
Now the sentence I most want you to keep. Reading your admin does not tell you what your customers are seeing.
Split you can count on the order page. Field shows its values there, but whether the number, the company and the URL describe the same parcel only shows when you open the link.
Render is a customer-side rendering, so you check it where the customer is. Feed is a question about time, so you check it on a shipment that has already left.
So a merchant opens the admin, sees four tidy tracking numbers, and calls the store consistent. He has read the stored values and nothing else.
That is why this feels like a ghost. You look where the light is.
Where to start, and what the example does not prove
Symptoms do not map cleanly onto layers. This table is honest about which do and which have to be worked through in order.
Read the middle column as where to start, not as a verdict.
Where to start, and what the example does not prove
What the merchant reports
Start with this layer
What this example does not prove
Carrier name shows as Whistl while the number is DHL
Field
Nothing about carrier support or rendering; the number itself was fine
Several API calls, each producing its own email and its own number
Split
Nothing about field quality; each segment may have been filled correctly
Link opens the wrong carrier’s site and returns nothing, including one store where a UPS number arrived with a DHL link
Field
Nothing about whether either carrier is supported by the platform
Link works, but the status line never moves and the map sits still
Render, then Feed
Nothing about the parcel; the shipment may be moving normally while the page stays blank
That third row needs a note. The merchant with two shipping options reported that Shopify sent his UPS tracking code with a DHL link attached.
That is not a rendering question: both carriers are on the clickable list.
A Shopify staff member in that same thread named a blank or missing tracking company field as a cause he had seen before — a candidate mechanism for that symptom, not a published verdict on that order.
So Field is where I would start. A symptom that looks ambiguous from outside often narrows once you read the second post in the thread.
Narrows, not closes.
The last row needs a sequence rather than a single answer.
Shopify’s own wording for an unsupported carrier is that “the order status isn’t displayed, and the pin on the map doesn’t update in real time.” So what the status line is doing is where you start, not what you conclude.
If nothing appears where you expected a status, check Render first: the carrier, the customer-side page and the tracking fields sitting behind it. If the carrier’s own page has moved and Shopify has not, check three things before you call it a stalled feed: same parcel, same transport leg, same level of detail.
Shopify’s own notification page says event sources, accuracy and timing vary by carrier, so one new scan at the carrier does not have to produce one new line on your page.
Before the explanations, here is where to look first. Match the symptom your customer reported, then read the section named in the second column.
A 60-Second Symptom Diagnosis
What the customer sees
Start with this layer
One order produced several parcels or several emails
Split
The tracking link opens the wrong carrier
Field
The link works, but Shopify shows only a plain outbound link
Render
The carrier’s own page moves, but Shopify does not
Feed
A branded tracking page looks better but still shows no events
Feed
The four layers are not four headings below.
Split is covered in the section that follows, Render and Feed together in the section on what the order tracking page shows per carrier, and Field in the section after that.
You have felt this one. A customer emails you about order 1043.
She bought two things.
One shipment shows a moving map and a status line. The other shows a number that does nothing when she taps it.
She wants to know why your store treats her two parcels differently.
So you open the admin. Both fulfillments look fine.
Both have a tracking number. Both were marked fulfilled.
Nothing looks broken from where you are standing. And yet she is right.
A merchant named MauriceWirtz posted the exact shape of this on the Shopify Community in January 2023:
“We have two shipping options: Standard (DHL) and Fast (UPS).
But the tracking link that is being sent with the tracking code is not being recognized if it is using the FAst [sic] (UPS) shipping”
One store. Two shipping paths.
One link works, one does not.
He was not imagining it. Neither is your customer.
Here’s the thing — you will answer that email as a support issue, and it is not one. It is a structural fact about how Shopify tracking gets assembled, and it repeats on the next order.
A note on my evidence, up front. Every merchant quote below comes from the Shopify Community forums. That is one platform.
That is a real limit on what these quotes can prove.
They show that merchants keep asking this question. Between 2020 and 2025, six separate threads carrying quotes.
They do not show how common it is. I will say so again where it matters.
When Each Supplier Is Connected as a Separate Shopify Location
Two Shopify documents explain the split. Neither one explains it alone.
The first is the fulfillment service developer guide :
“Each fulfillment service corresponds to an inventory location in Shopify and allows you to manage fulfillment orders assigned to this location.
Each physical fulfillment centre or warehouse should have its own fulfillment service.”
The second is the merchant help page on fulfilling orders , as of August 2026:
“If the order can’t be fulfilled using the inventory at a single location, then your order is split into multiple Unfulfilled sections, also known as fulfillments, based on location.
You need to fulfill each fulfillment separately.”
Put those two side by side. A supplier that is registered as a fulfillment service gets its own location.
An order that spans locations gets split into separate Unfulfilled sections.
Count that carefully, because the words underneath it are not interchangeable.
Connecting an app is not the same thing as registering a fulfillment service, and not every app creates a location of its own. What the admin groups for you is work assigned to a location.
The API calls that grouping a FulfillmentOrder . A fulfillment is the record of goods actually going out.
One location can hold more than one of those groups, a single group can be fulfilled in more than one go, and one fulfillment can cover more than one parcel.
So: three suppliers, each registered as its own fulfillment service, each shipping the part of the basket it stocks. That order splits three ways.
Read it as an example with its conditions attached, not as a formula. Your supplier count is not your segment count, and your segment count today is not your final parcel count.
The condition deserves its own sentence, because skipping it makes the whole chain wrong.
Handle fulfillment manually instead, pushing all supplier shipments through a single location, and Shopify will not split the order by supplier identity alone.
The mess moves into your spreadsheet instead of onto the order.
Split into segments, notified per segment
Now the part your customer feels.
Shopify’s customer notification documentation states the triggers directly, as of August 2026:
“Shipping confirmation: Sent when an order is fulfilled”
“Shipping update: Sent when tracking information is updated”
The trigger is the fulfillment. It is not the order.
The same help page that describes splitting also puts a notification checkbox on each fulfillment action.
Its wording: “To send a shipping confirmation email to your customer after you fulfill the order, select Send a notification to the customer.”
A three-segment order can generate multiple shipping confirmations, because notification control exists per fulfillment.
The actual number depends on the merchant action or the fulfillment app’s notification settings.
A merchant named merejsoft, working out what that would mean for his buyers, wrote this in February 2023:
“our customers will receive 5 emails with 5 separate tracking numbers. As a consumer, that would be really annoying.”
That is a merchant predicting a consequence, not a merchant reporting a test. Worth separating, because this is where writing about Shopify tracking usually goes wrong.
It is not true that your customers will always receive N emails. The notification is a checkbox.
The same documentation has a whole section on turning shipping confirmations off.
The opposite failure runs on the same mechanism. The documentation does not spell this direction out.
It follows from the same switch. When a supplier’s integration does not ask Shopify to notify the buyer, that fulfillment sends no Shopify shipping confirmation.
Whether she hears anything at all then depends on whatever else you have running — the Shop app, the supplier’s own emails, a tracking app.
If none of them speaks up, she emails you, because she thinks the order was forgotten.
Both ends come from the same mechanism. Writing only about the noisy end is a half-truth.
Why an individual shipment stops updating is a separate piece: why tracking updates become a fulfillment bottleneck .
Managing the supplier mix itself is another: how growing stores manage multiple suppliers .
One sentence in Shopify’s help documentation turns this topic from an opinion into a constraint.
It sits right after the instruction to click “Add another tracking number.” As of August 2026 it reads:
“All tracking numbers must be from the same carrier.”
That rule describes one path through the platform, not the whole platform. Keep three things apart.
In the admin. The native “Add another tracking number” flow holds you to one carrier, and “the same tracking company will be applied to all tracking numbers specified.” Numbers added that way share one company name, whatever the numbers themselves belong to.
Through the API. A tracking URL you supply yourself wins.
The GraphQL tracking input takes a urls field alongside numbers and pairs the two by position, and an explicit URL is used instead of one built automatically from the company name.
So a shared company name does not mean every link must land on the same wrong website.
What it does mean is that you cannot claim each number inside that fulfillment carries its own carrier identity, or its own automatic status behaviour.
Whether to open a second fulfillment. That is a question about the goods, not about the carrier name. Different items, leaving at different times, are separate fulfillments.
That is the mechanical reason your multi-supplier orders carry several tracking numbers, and not a plugin you failed to install.
One boundary belongs here, because cross-border parcels hit it constantly. A parcel handed to a last-mile carrier and given a new number is still the same parcel.
Record that as a second fulfillment of the same goods and you overstate what you shipped. You also send her a second shipping email for a box she already knows about.
Keep the two numbers attached to the same fulfillment where your integration allows it.
Tracking services that consolidate origin-country and destination-country events for one parcel do exist. AfterShip documents it as a feature of its own product .
That tells you the mechanism is real. It does not tell you your own stack has it.
Legacy API note. Older REST Admin API discussions describe a single tracking number per fulfillment, and that answer still circulates. Shopify treats the REST Admin API as legacy.
The GraphQL tracking input accepts several tracking numbers on one fulfillment.
Read the REST-era answers as REST-era answers rather than as a description of the platform today, and do not read the GraphQL behaviour as something newly announced.
So the constraint is not how many tracking numbers you may store.
It is that every tracking number stored in one fulfillment shares one tracking company, which means that fulfillment can present only one carrier identity to the buyer.
How many numbers does it produce? One merchant, janmichaeluy, put a figure on his own store in February 2022:
“It’s even more difficult for customers whose orders are separately fulfilled by multiple suppliers (they usually need around 3-4 separate tracking numbers per order).”
That is his store. It is not an industry average, and I am not going to dress it up as one.
Your own number depends on how many suppliers touch a typical basket in your catalog.
Two renderings, one documentation page
Most merchants have never seen this part written down.
Shopify’s page on understanding order status pages describes two different customer experiences. Same page.
The variable is the carrier. Verified as of August 2026.
Two renderings, one documentation page
What the buyer gets
Supported shipping carrier
Unsupported shipping carrier
Official wording
“If you ship through a supported carrier, then the order status updates in real time and the shipment location is displayed on a map.”
“If you use an unsupported shipping carrier, then the order status page has a tracking number that links to the shipping carrier’s website.”
Status line
Confirmed, On its way, Out for delivery, Delivered, Attempted delivery
“The order status isn’t displayed”
Map behaviour
Live shipment location on a map
“the pin on the map doesn’t update in real time”
What she has to do
Read your page
Leave your page for the carrier’s site
Nothing in that table is a switch inside your store. The lever you do have is upstream: which carrier that segment ships on.
That page also confirms multi-segment support: “The order status page works with partial fulfillments, even if they’re made through different shipping carriers.
Shopify creates new sections on the order status page for multiple fulfillments.”
That is the whole of what the documentation says about it. It does not describe what those sections contain, or how they are ordered.
The same carrier name, two different outcomes
In April 2026, a Shopify staff member posting as Alan_G answered a developer-forum thread about automatic delivery status.
He posted two lists. One of carriers whose status updates automatically without a Shopify shipping label.
One of carriers that update only when the label came from Shopify.
Those two lists are not clean opposites. Six names sit on both: Canada Post, DHL Express, DHL eCommerce, FedEx, UPS and USPS.
Read the thread to the end and the overlap stops being a puzzle, because he explains it himself two posts later:
“the repeated entries (Canada Post, DHL Express, DHL eCommerce, FedEx, UPS, USPS) work with both methods”
So for those six names, the label source is not the deciding factor. Three days after that, the merchant who opened the thread said this explained why his DHL parcels had been updating.
That is an answer, and I am not going to keep it filed as an open contradiction.
What it does not give you is a tested guarantee for your own store.
A dated support answer names carriers, while carrier service, account configuration and region sit underneath each of those names.
He also said this about his own company’s documentation:
“Our documentation isn’t super clear on that for sure, so I’ll push for that to be updated on our end.”
That sentence is about the documentation being unclear. It is not a licence to treat the specific question he just answered as still open.
Read the thread in order and the rest gets more useful too. Five days earlier he had given a broader answer of his own.
Then a merchant pasted in a reply from Shopify Plus support, drawing the line much tighter: fully supported only when labels are bought through Shopify.
Post 6 is Alan_G partly walking back his own earlier answer. He calls the support line “partly correct.”
Two framings were in circulation at once, inside one company, and one of them was his.
The useful takeaway is structural. Whether a buyer sees real status movement is a combination.
Carrier, and label source. It is not a single switch you can find in settings.
A store with several suppliers is exactly the store that lands in several different cells of that grid.
Several China cross-border carriers appear on neither of Alan_G’s two lists, and he never said those lists were complete.
That is a lead to test, not a conclusion about what the platform supports.
Two documents, two different jobs
Now the piece that makes all of this confusing, and Shopify writes it down on its own page.
One list decides whether a tracking number becomes something your customer can click. That is the supported tracking companies list in the API reference.
A different page governs whether the status advances. The help page above does not leave that to interpretation.
The words “supported carrier” are themselves a link. They point at the shipping carriers page .
The API reference points at the same page for automatic shipment_status updates. Two sets of documentation, one destination.
One list, one page, two different jobs. You cannot read one as an answer to the other.
That is not my reading of the page layout. Six days after the exchange above, the same staff member put the distinction in writing:
“I agree the current docs don’t make this distinction clear enough, especially the difference between generating clickable tracking links and automatically progressing shipment status.”
The distinction is where multi-supplier China stores land. 4PX, YunExpress and China Post are on the clickable list. They are not on the page both of those cross-references send you to.
Here is exactly how far that gets you, and it is less far than it looks. Shopify’s own cross-references make no promise of automatic status progression for those carriers.
They also do not put them anywhere.
That target page is built around which Shopify labels you can buy from which fulfillment location, and which carrier accounts you can connect for checkout rates.
It is not labelled as a complete register of every carrier’s automatic-status behaviour, and “unsupported” is not a column anyone published. So absence from it is not a classification.
What actually happens on your store is unknown from the documentation alone.
In April 2026 that same staff member named ten carriers that are absent from that page and update automatically anyway, and on the documentation his words were: “isn’t super clear on that for sure.”
So: clickable number, no documented promise about the status line, and no documented verdict in either direction. Whether it runs for you is step 4 further down.
Sometimes nothing is wrong with the carrier at all. The field is wrong.
Shopify’s FulfillmentTrackingInput reference is unusually direct about this:
“Send the tracking company name exactly as written in the list (capitalization matters).”
And about what happens when you skip it:
“The tracking number has a Shopify-known format. Shopify will guess the tracking provider and build the tracking url based on the tracking number format.
Not all tracking carriers are supported, and multiple tracking carriers may use similarly formatted tracking numbers. This can result in an invalid tracking URL.
It is highly recommended that you send the tracking company and the tracking URL.”
Read that as a warning about your supplier integrations. Send only a number, and the platform guesses.
Guess wrong, and your customer gets a link that opens the wrong carrier’s site and returns nothing.
Shopify’s order tracking help page hands the whole question to your vendors, as of August 2026: “If you use a third-party service for fulfillment, such as an app, then how you add tracking information depends on the service that you use.”
That is the quiet sentence in the whole topic. It means each supplier’s integration quality is the ceiling on what your customer can do with that tracking number.
Not your theme. Their field mapping.
Merchants describe the result in plain language. In July 2024, sebastiaanjopp wrote :
“Instead of DHL, it shows Whistl, even though the tracking number is from DHL. This is causing confusion for my customers.”
In February 2025, mns-burg described the same failure from the other side :
“At the moment our tracking numbers links to Deutsche Post, where the tracking numbers don’t work.”
Two merchants, seven months apart, reporting the same symptom: a carrier name that does not match the number attached to it. The mechanism above is the candidate I would check first in both.
But those threads hold a merchant’s account and other people’s guesses. That is not a diagnosis.
So I will not tell you what broke in those two stores, and I will not rule out that some of it sat with the platform.
The mechanism is documented by the platform. The symptoms are self-reported by merchants in a public forum.
I am keeping those two labelled separately, and a symptom that matches a documented mechanism is still only a symptom that matches a documented mechanism.
Where this lands for you. If you run several China suppliers into one store, and you have been treating Shopify tracking as a support problem, it is not one.
It is a handover problem in some layers and a carrier-behaviour problem in others, and the two need different answers.
Look — let me argue the other side properly. The other side has real evidence.
Start with the buyer. Baymard Institute’s research on order tracking reports that 50% of respondents in their quantitative study named order tracking the most important account feature.
The same page reports that 67% of test sites neglected to consistently provide all key order-tracking details.
Two notes on dating that, since I am asking you elsewhere to date everything. The page was first published in 2019 and carries an update stamp of May 2026.
The quantitative study behind the 50% is tagged by number only. Baymard does not state the year it ran, so I am not going to attach one.
One test participant said this. She was on the store’s own order details page, and had to click out to a third-party tracking page:
“I would try clicking on this tracking number. But this is not a hyperlink.
It’s just a number.”
She found a way through in the end — a track-your-order button that took her to a branded third-party tracking page.
So read that quote for what it is: a buyer hunting for tracking information across more than one page.
It is not evidence about which carriers Shopify updates automatically, and I am not going to borrow it for that.
Be precise about what that research measured: whether sites provide tracking details consistently. It did not study whether two orders inside one store look different.
I am using it for the buyer’s reaction, not for my thesis.
Merchants have been asking for the fix for years, in their own words.
In September 2020, a merchant posting as Rari asked the community for a way to let customers track orders from the store itself:
“Does anyone know if its [sic] possible to add a tracking order button onto shopify website so customers can track orders; and is this possible with drop-shipping as different suppliers use different couriers.”
The same request keeps reappearing: a second merchant replied in that thread, and in February 2024 another asked how to set up tracking numbers while running two dropshipping platforms.
Those posts are from 2020 and 2024, and platform behaviour changes, so they prove one thing only: merchants keep asking. For today’s behaviour, read the documentation sections above.
Here is where I argue against my own interest.
Those merchants are right. A single tracking page is a good buy for a lot of stores.
Does most of your volume land on one carrier, with the inconsistency mostly about presentation? Then build or buy one branded tracking page.
It will take away the part of the confusion that comes from presentation, and it is far less work than anything else in this article.
Do that first. Do not hire anyone to rebuild your supply chain over a rendering problem.
Before you buy, work out which of three Shopify tracking products you are being sold, because they arrive under the same words:
A presentation layer. It restyles what Shopify already holds. Same data, better frame.A tracking service with its own carrier connections. It queries carriers itself, so it can hold events and detail that never reached your Shopify order.An integration that writes back into Shopify. Shopify exposes a mutation, fulfillmentEventCreate , which lets an app with the right permission push fulfillment events into Shopify itself. AfterShip, as one named example, documents syncing its checkpoints to Shopify on its Enterprise plan, over GraphQL, with the matching permission. That is one product on one plan tier. Do not read it as something every tracking app does.
So compare them on data sources, carrier coverage, write-back permission and status mapping. Not on how the demo looks.
The boundary is what happens underneath all three. None of them can invent a transport event the carrier never sent.
That is the next section.
If you have got this far, you are probably hoping most of it turns out to be fixable. Some of it is a process problem you can solve.
Some is a physics problem you can only manage.
Mixing the two is how stores buy tools that were never going to fix what they bought them for. So sort your Shopify tracking differences into those two piles first.
What Can Be Unified, What Structurally Cannot
What you want to unify
Can it be unified
The reason
The page the customer lands on
Yes
Presentation is yours to control, whatever the carrier sends
Field quality across suppliers
Yes, by process
The documentation names the requirement: company and URL, spelled exactly
Number of shipping emails per order
Partly
Notifications fire per fulfillment and each one has a checkbox
Whether status advances on the page
Partly, and you have to test it
It turns on the carrier and label-source combination. Which of Shopify’s two pages names the carrier tells you what is documented, not what will happen in your store
Identical raw events from every carrier
No
Shopify: “Tracking event sources, accuracy, and timing vary by carrier.” You can still widen coverage and normalise status names; you cannot make two carriers emit the same events
Tracking data available inside one carrier brand
Not by the brand name alone
DHL: “Availability depends on the DHL service and product.” This is about what the carrier’s API returns, not directly about the shopper’s page
Shopify’s own notification documentation says it plainly, as of August 2026: “These notifications are sent when a tracking event with the corresponding status is received from the carrier or fulfillment app.
Tracking event sources, accuracy, and timing vary by carrier.”
That is the platform telling you the variation sits upstream of it. No Shopify tracking setting makes a carrier report an event it did not report.
What you can still change is what you collect and what you call it: a different service, a write-back integration, a consistent status vocabulary. What you cannot change is the raw supply.
The variation does not stop at the brand boundary either. Look at DHL’s unified shipment tracking API reference .
Under the heading “Scope,” it lists six brand names it covers. Post & Parcel Germany and DHL Express are two of them.
DHL Supply Chain is another.
It then lists eleven things integrators can retrieve and marks five of them with an asterisk, piece-level tracking events among them.
The footnote on that asterisk reads: “Availability depends on the DHL service and product.”
That footnote is about what the API can return. It is not about what a shopper sees on a page.
Even so, it points the same way: one carrier name is not one tracking reality.
Hold us to the same test I give you further down. Ask a supplier for one filled sample per carrier. Tracking company string, tracking URL, label source.
Ask us for ours before you sign anything. Where this article describes how we hand tracking over, that description has exactly one source, which is us, and it is not evidence that we run it.
A sample moves you one step further, and only one. Ask whether it is a demo or a redacted record from a real order.
Even a real one covers that order, not a standing practice.
If a shipment has genuinely stopped updating, rather than merely rendering differently, that is a different diagnosis.
I wrote that one up separately, in why tracking updates become a fulfillment bottleneck .
Start with how tracking reaches your store at all, because that decides who is responsible for what.
Our own connection options are an app or a Google Sheet, and different clients run different ones.
Nothing on our site, and nothing in this article, tells you which one your account would use or who would hold the Shopify write-back permission on your store.
Those are onboarding questions, and they come first.
So read this section as what to put in writing before you start, rather than as a description of what is already running on your orders:
Which fields we fill , exactly: tracking company string, tracking number, tracking URL, and which list the company string is spelled from.Who writes back into Shopify — our integration, your tracking app, or your own team — and which of us holds the permission that makes it possible.What happens when a parcel changes carrier mid-route , and whether the two numbers stay attached to one fulfillment or become two.What sits outside it. Anything created outside the agreed workflow, and anything the carrier never reported.
Where supplier inventory is consolidated through one China-side fulfillment operation, that removes supplier-level handoffs, which is the Split lever.
It does not mean every order ships as one parcel. Product restrictions, arrival timing, route requirements and package size can still force separate shipments.
Render and Feed are the two that get moved by carrier selection and label-source testing, and they are also the two nobody can promise.
No fulfillment partner can make every carrier report the same events, at the same frequency, at the same level of detail.
What To Settle With ASG, and What No Fulfillment Partner Can Guarantee
Layer
What to agree with a partner
What no partner can guarantee
Split
Consolidating supplier inventory to remove avoidable fulfillment splits
Every order shipping in one parcel
Field
Which fields get filled, in what format, and who writes them back to Shopify
Data created outside the agreed workflow
Render
Which carrier and customer-page combinations get checked before volume runs through them
Identical Shopify rendering for every carrier
Feed
Which carrier and label-source pairs get tested, and who watches for stalled events
Identical event frequency and detail from every carrier
Read the right-hand column as carefully as the left. A partner who promises the right-hand column has not read the two Shopify pages this article is built on.
All of the above is only worth reading if it changes what you do.
Two things before the steps.
You do not have to start by placing test orders. Most of this can be read off orders you have already shipped.
An order currently in transit beats a fresh one, because it already has events behind it.
Place a test order when you have no representative order for that combination — a carrier you added last week, a supplier you connected yesterday.
And your own view of the customer page has a limit. Shopify documents reaching it from the order itself, through More actions and View order status page.
The same documentation describes customer access to that page as something that can require the customer to log in.
So treat what you see there as a first look, not as proof of what an authenticated buyer sees.
Read “pre-ship” as two things, then. Checks you run before you route volume through a supplier or a carrier, and observation that can only exist after the parcel moves.
Nobody verifies a feed that has not happened yet.
Now the Shopify tracking check itself, in the order of the four layers.
1. Split. How is this order currently divided?
Open the order in your admin and count the Unfulfilled sections. That count tells you how the work is divided between locations right now.
It is not a notification count, in either direction: one group can be fulfilled in more than one go, and notifications can be switched off at each fulfillment.
What your buyer actually receives takes three separate checks. The fulfillment actions themselves.
Whether tracking information gets updated afterwards. And the notification settings, both in your admin and in each supplier’s app.
If the division surprises you, your catalog is mixing suppliers inside typical baskets. No tracking page will hide that.
2. Field. Do the number, the company and the URL describe one parcel?
Pull one recent fulfillment per supplier, read the three values, then open the URL yourself.
A link that resolves to the wrong carrier’s site is a frequent cause of the “my link is dead” email.
It is also the Shopify tracking failure sitting closest to your own hands: a data and handover problem, not a carrier behaviour.
Which is why it belongs in an agreement with your supplier rather than in a support queue.
3. Render. Which Shopify page names this carrier, and what does the buyer’s page show?
Check the clickable list first, and check it for both answers, not just the bad one. As of August 2026, plenty of China cross-border carriers are right there on it. 4PX.
China Post. YunExpress.
SF Express. Anjun Logistics.
SFC Fulfillment. DHL eCommerce Asia.
Chukou1. First Line.
FSC. Others are not, including Yanwen, Cainiao, J&T, Winit and Sunyou.
That second group needs a different action, and this is the step the rest of this check cannot give them: there is no correct string to copy, because the name does not exist in the list.
Shopify’s order tracking help page describes the path for a carrier it does not recognise — select Other and supply the full tracking URL yourself, rather than leaving the field for Shopify to guess from the number format.
A merchant in one of the threads above hit exactly this: the carrier he needed to name was not a supported tracking company, so there was nothing to spell correctly.
Getting that group right is a URL problem, not a spelling problem.
One detail about that page. The main list is the same for everyone, in its own wording it displays for shops located in any country.
A shorter add-on list does vary, and it varies by where your store is located . Not by the carrier’s nationality, and not by where the parcel ships from.
A store located in the United States, shipping out of Shenzhen, reads the US add-on list.
Then the part people skip. Being on the clickable list does not mean the status line will move.
That behaviour comes off the other page. And not being on it does not mean the number produces no link at all.
Shopify will still guess the provider from the number format.
So do not stop at either list. Open the customer-side page for a shipment on that carrier and read it yourself.
4. Feed. Are events still arriving, and where did the label come from?
For each carrier and label-source pair you actually use, follow one shipment.
Watch whether the status line advances on the customer-side page, and compare it against what the carrier’s own page shows at the same moment.
This layer has no shortcut. A status line only advances when real transport events arrive, so this one runs on the calendar rather than on your afternoon.
Use a shipment already in transit where you have one. Do not start every combination at once; pick one route per carrier.
Official documentation on this point was described as not super clear by Shopify’s own staff.
When you are done, count one tracking reality for each fulfillment flow you actually run — not one per supplier.
Two suppliers shipping the same carrier with the same label source can still differ in how their numbers get written back, so check before you merge them into one row.
One supplier running three carrier services is three.
Turn it into a sheet you keep. One row per flow, and only for the label sources you really use: if you never buy Shopify labels, there is no Shopify-label row to fill in.
Six things per row, because four columns cannot carry a four-layer answer.
A Pre-Ship Tracking Check You Can Run
Record group
What goes in it
Identity
An anonymised order reference, the fulfillment, and which items and quantities sit in which parcel
Configuration
The supplier or write-back integration, the specific carrier service or route, the label source
Field
Number, tracking company, full URL, and whether all three describe the same parcel
Legs
Origin number, last-mile number, and how they relate. Mark it not applicable when the number never changes
Render and Feed
Where you looked, what you saw, the upstream events and their times, what Shopify showed, and the date you checked
Open
What is still unresolved, who owns it, and what evidence would close it
The last two columns are the ones people leave out, and they are the ones that turn the sheet from a configuration list into a record of what customers actually got.
That sheet survives moving a product from an AliExpress seller to a private agent.
If you want ours, send us three recent multi-supplier orders — order reference, carrier, tracking number and label source is enough, with customer details stripped out.
We will fill the first three rows with you.
Two related pieces, if the underlying problem turns out to be bigger than tracking. What breaks when Shopify order volume starts growing .
And the declaration fields that decide your duty bill on DDP shipments from China .
Multi-supplier Shopify tracking does not fail loudly. It fails one customer at a time.
The operator checks the admin and sees nothing wrong.
The expensive mistakes run in both directions, and you can see both coming without me inventing a client to hang them on.
A quarter spent shopping for a tracking app when the fault lives in a field mapping. A supply chain rebuilt when a branded tracking page would have covered it.
Neither is a tooling failure. Both are diagnosis failures, and both start the same way: treating one visible symptom as one underlying cause.
Count your layers first. Then decide what to buy.
That order of operations is the whole Shopify tracking argument in one line.
You do not need a perfect tracking experience. You need to know which of your differences the customer can see.
Then which of those you can actually change. Those two lists are shorter than they feel.
Once they are written down, the support emails stop being surprises.
Why does one Shopify order have multiple tracking numbers? Because tracking numbers attach to fulfillments, not to orders.
An order is what the customer bought; a fulfillment is the record of part of it going out, and one fulfillment can cover more than one parcel.
When suppliers are registered as separate locations or fulfillment services, one order can be divided into several groups of work and fulfilled separately, each fulfillment carrying its own number.
Shopify’s notification documentation ties shipping confirmations to fulfillment events rather than to orders, as of August 2026.
Can one fulfillment contain tracking numbers from different carriers? It can hold them, but it cannot describe them separately.
The GraphQL tracking input accepts several numbers on one fulfillment, and “the same tracking company will be applied to all tracking numbers specified”, so one fulfillment presents one carrier identity to the buyer.
A tracking URL you supply explicitly still takes precedence over one built from the company name, paired to its number by position.
So a shared company name does not by itself mean a wrong link.
Whether to open a second fulfillment should follow the real shipment and item count, not the appearance of a second carrier name.
Why does a tracking link open the wrong carrier? The first thing to check is the tracking company field, blank or spelled differently from what Shopify expects.
The tracking input reference asks senders to provide the company name exactly, along with the tracking URL, and warns that guessing from number format can produce an invalid link.
A Shopify staff member replying to one of these threads named a blank or missing tracking company as a cause he had seen before.
That makes it a strong candidate, not a finding about your order. Check one recent fulfillment per supplier before blaming the platform, and before assuming the field is the whole story.
Why does the carrier page update while Shopify does not? Because clickable links and automatic status updates are documented on two different Shopify pages. One decides whether the number becomes a link.
A separate page is the one Shopify points at for automatic status updates.
A carrier can be named on the first and absent from the second, which means the documentation promises you a link and promises nothing about the status line.
Absence is not a ruling that the line will stay blank: a Shopify staff member has named carriers missing from that page that update automatically anyway.
Shopify also states that event sources, accuracy and timing vary by carrier, so test your own carrier and label source rather than reading either page as a verdict.
Can a branded tracking page unify every carrier experience? That depends on which product it is. A page that only restyles what Shopify already holds changes the frame and nothing else.
A tracking service with its own carrier connections can hold events your Shopify order never received, and an integration with the right permission can write events back into Shopify.
What none of them can do is create an event the carrier never sent.
So judge a tracking page by the data arriving in it — sources, carrier coverage, write-back permission, status mapping — and not by how it looks in the demo.
What evidence should I request from a supplier or fulfillment partner? Ask for one filled sample per carrier they use: the exact tracking company string, the tracking URL, and the shipping label source. Then open the URL yourself.
Shopify’s documentation states that how tracking gets added depends on the service in use, which makes your supplier’s integration your ceiling.
A sample you can open beats a verbal assurance. Ask whether it is a demo or a redacted record from a real order, because one real order shows you that order and not a standing practice.
Shopify Help Center, Fulfilling your own orders individually — https://help.shopify.com/en/manual/fulfillment/fulfilling-orders/single-fulfillment
Shopify Help Center, Order tracking — https://help.shopify.com/en/manual/fulfillment/setup/order-status-page/order-tracking
Shopify Help Center, Understanding order status pages — https://help.shopify.com/en/manual/fulfillment/setup/order-status-page/understanding-order-status-pages
Shopify Help Center, Setting up customer notifications — https://help.shopify.com/en/manual/fulfillment/setup/notifications/customer-notifications
Shopify.dev, FulfillmentTrackingInput — https://shopify.dev/docs/api/admin-graphql/latest/input-objects/FulfillmentTrackingInput
Shopify.dev, FulfillmentTrackingInfo supported tracking companies — https://shopify.dev/docs/api/admin-graphql/latest/objects/FulfillmentTrackingInfo
Shopify Help Center, Shipping carriers that integrate with Shopify — https://help.shopify.com/manual/shipping/understanding-shipping/shipping-carriers
Shopify.dev, Build for fulfillment services — https://shopify.dev/docs/apps/build/orders-fulfillment/fulfillment-service-apps/build-for-fulfillment-services
Shopify.dev, FulfillmentOrder object (2026-07) — https://shopify.dev/docs/api/admin-graphql/2026-07/objects/FulfillmentOrder
Shopify.dev, fulfillmentEventCreate mutation — https://shopify.dev/docs/api/admin-graphql/latest/mutations/fulfillmentEventCreate
AfterShip Help Center, Guide to receive destination tracking data — https://support.aftership.com/en/tracking/articles/15441420-guide-to-receive-destination-tracking-data
AfterShip Help Center, Syncing AfterShip checkpoint events to Shopify — https://support.aftership.com/en/tracking/articles/15441385-syncing-aftership-checkpoint-events-to-shopify
DHL Developer Portal, Shipment Tracking Unified — https://developer.dhl.com/api-reference/shipment-tracking
Shopify Community, Automating tracking number upload for multiple dropship suppliers, 2022 — https://community.shopify.com/t/how-can-i-automate-the-tracking-number-upload-process-for-multiple-dropship-suppliers/102066
Shopify Community, Fulfillment REST API multiple tracking numbers, 2023 — https://community.shopify.com/t/fulfillment-rest-api-multiple-tracking-numbers/189012
Shopify Community, Order tracking button on a drop-shipping site, 2020 — https://community.shopify.com/t/can-i-add-an-order-tracking-button-to-a-drop-shipping-site/20867
Shopify Community, Tracking numbers for dropshipping platforms, 2024 — https://community.shopify.com/t/how-can-i-set-up-tracking-numbers-for-my-sites-dropshipping-platforms/291443
Shopify Community, Incorrect logistics company displayed, 2024 — https://community.shopify.com/t/issues-with-shipping-confirmation-incorrect-logistics-company-displayed/341428
Shopify Community, Shopify carrier tracking link, 2023 — https://community.shopify.com/t/shopify-carrier-tracking-link/181381
Shopify Community, Shipping from a not supported shipping company with the API, 2025 — https://community.shopify.com/t/how-to-ship-form-a-not-supported-shipping-company-with-the-api/391845
Shopify Developer Community, Automatic delivery status update, 2026 — https://community.shopify.dev/t/automatic-delivery-status-update-bug-or-misleading-documentation/33603
Baymard Institute, Order Tracking UX: 6 Key Details to Provide — https://baymard.com/blog/integrate-tracking-info
Platform behaviour described in this article was read from Shopify’s own documentation on 2026-08-17, covering order splitting, notification triggers, order status page rendering and tracking field requirements.
Passages in quotation marks are the wording captured on that date. The same sources were re-checked on 2026-09-14.
Where the current documentation is wider than the older wording, this article follows the current documentation.
Two references are cited as mechanism only, from documents read on 2026-09-14 rather than quoted: the fulfillment order object and the tracking-service consolidation and write-back features described by AfterShip.
Buyer-behaviour figures come from Baymard Institute research on order tracking, first published in 2019 and carrying a May 2026 update stamp; the quantitative study behind the first figure does not state its own year, so no year is attached to it here.
Merchant quotes come from public Shopify Community threads between 2020 and 2025, one platform only.
They describe individual stores, not measured samples, and they are used here as symptoms rather than as diagnosed causes.
Statements about how ASG connects to a store, fills tracking fields and hands tracking back describe what we agree at onboarding. They are our own account and carry no time commitment.
One item stays open on purpose: the country-dependent part of the carrier list is reported here from the documentation wording, not from opening that page inside a store located in the United States.
I am Janson, founder of ASG Dropshipping. My team runs sourcing, quality control and fulfillment for Shopify and WooCommerce sellers out of Shenzhen and Dongguan.
That puts us on the supplier side of exactly the handover this article is about. Before that I spent years watching sellers move off AliExpress and marketplace sourcing.
Then discover that the Shopify tracking problem had followed them. I write these pieces because the answer is usually structural, and a structural answer is harder to sell than a tool.
