Your Shopify Delivery Notifications Are Late by Design

There is a thread on r/shopify from July that captures the whole mess in three paragraphs. A Netherlands merchant, low order volume, ships PostNL and DHL. Native Shopify does not poll either carrier for tracking status, so they installed Track123. Track123 promptly emailed their customers status updates for the wrong parcels. They uninstalled it, installed 17Track. Now the delivery emails fire, but two to three hours after the actual scan. They asked, in visible frustration, what the point of any of these apps actually was. A commenter answered honestly: without a direct carrier API account, tracking apps can only poll on their own schedule. You inherit the delay.

That thread is the whole category compressed. Shopify delivery notifications sent through third-party apps land late because the entire category is built the same way. The reason most Shopify delivery notifications arrive after your customer already has the package has nothing to do with a bug in the specific app you installed. Once you see that, the advice you keep getting from support articles and other merchants starts to look wrong.

The advice everyone gives, and where it comes from

Ask this in any Shopify community and the answers converge in about a day. Install a tracking app. Track123, AfterShip, 17Track, ParcelPanel. The threads are full of them. Merchants swap recommendations, complain about whichever one burned them last, and then name the next one to try. The premise underneath the whole conversation is that if your Shopify delivery notifications are broken, another app is the fix.

For carriers that Shopify does not natively poll (roughly every European regional carrier, plus DHL through most non-US accounts, plus any label you did not buy through Shopify Shipping) the app is the only mechanism that turns a raw tracking number into "Out for Delivery" and "Delivered" emails. So the premise is not exactly wrong. The gap is in what those apps actually do once installed.

Polling is not a bug in your tracking app. It is the app.

The boring truth: most tracking apps do not receive events from carriers when a scan happens. Instead of the carrier pushing scans out, your app has to poll the carrier on a schedule. Every two to four hours on the standard plans of every major app I have looked at.

Every "Delivered" email a polling app sends is sent because, on the app's next scheduled check, the carrier's API happened to return "delivered" for that tracking number. If the actual scan happened five minutes after the previous poll, your customer gets the email up to four hours after the package hit their porch. If the last two carrier events, "Out for Delivery" and "Delivered", both landed inside the same polling gap, the app dutifully sends both emails within a minute of each other. Track123's own support has written this on their App Store page: carrier efficiency governs notification timing, and customers may receive multiple notifications inside a short window. That is a vendor politely admitting that a short window is what their app produces at baseline. Every delivery email inherits the polling lag, whichever app you have installed.

The alternative is webhook-based. The carrier pushes to you the moment a scan is recorded, and the notification email fires within seconds. That exists for some carriers (USPS has partial webhook support and AfterShip advertises it), but for most EU regional carriers and small US 3PLs, webhooks require a direct carrier API account with a shipment volume minimum. In practice: 100 to 500 shipments a month, on a business shipping contract, with a developer or somebody comfortable wiring up n8n or Zapier. If your store is not there yet, no amount of app-shopping changes the architecture below.

The merchant on that Netherlands thread said out loud what I say to clients. The "Delivered" email showing up three hours after your customer already got the package is noise. By the time it lands they have checked the tracking page, possibly emailed you, and moved on. Delivery-notification value is time-sensitive and the value curve drops off a cliff. A late delivery email is close to worthless.

Half the time, the tracking app is not even the problem

Here is the part I only learned by chasing enough of these. A meaningful share of "my Shopify delivery notifications are not firing" reports have nothing to do with polling. They come from a single boolean flag in the Fulfillment API called notify_customer. If a fulfillment partner calls the API with notify_customer: false, Shopify accepts the tracking number, the order shows fulfilled in your admin, your notification templates stay active in Settings, and no shipping confirmation email fires. Nothing surfaces in the admin log to tell you what happened.

The list of partners that default the flag to false is longer than you would hope. ShipStation. Veeqo. CJdropshipping. Contrado. SyncSpyder. Each one is documented in a Shopify Community thread where a merchant surfaced the same symptom and a community member (rarely a Shopify staffer) traced it back to the flag. If you use any of them and your customers have stopped getting shipping confirmations, do not go install a tracking app. Look at your fulfillment integration first.

The fix per platform is small and finicky. In ShipStation there is a "notify customer" checkbox inside ShipStation's own settings; enable it once and Shopify keeps it wired going forward. CJdropshipping wraps it in a permission called "allow CJ to send a email to your customer via shopify," which merchants often disable because CJ was sending incomplete emails, then find themselves with no emails from either side. Contrado's engineering team confirmed in a community thread that they send fulfillment data to Shopify and rely on Shopify to email customers, which of course fails, because they do not set the flag. If you built a custom Fulfillment API integration on GraphQL, the field is notifyCustomer in camelCase; the REST name notify_customer in snake_case gets silently ignored and falls back to the default of false.

I spent an evening on a merchant call last spring tracking down what turned out to be exactly that flag. Ninety minutes, three false leads, both of us squinting at the wrong screen. No tracking app would have fixed it. There is no app for somebody else's platform's default integration setting.

The advice that actually works

You have two failure modes hiding behind the same complaint, and if you do not sort them first, the app-shopping cycle can run for months.

If tracking numbers appear in your order admin, the initial shipping confirmation email fires, and only the "Out for Delivery" or "Delivered" emails are late or missing, you are in polling-land. A different app will not help you. Accept the delay, set customer expectations in the shipping confirmation email ("you'll get a final delivery confirmation shortly after your package arrives"), and if the lag actually costs you money, spend an hour with your carrier on a direct API account or bring somebody in to wire up a webhook listener. That is the actual escape hatch. If you want a second pair of eyes on that hour, help1's expert chat is where I would spend it; the first fifteen minutes are free.

If no shipping confirmation email is firing at all, not just the delivery ones but the initial one too, you have a notify_customer problem and the fix lives at your fulfillment partner. Our walkthrough on Shopify tracking stuck after fulfillment covers the sibling failure at the Shopify-native carrier layer; the two look identical from the admin and are worth checking together before you decide which one you have.

One more thing worth naming, because it caught out a merchant I worked with in June: Track123 sends "Delivered" emails retroactively for every order delivered in the seven days before you install it. That is intentional. Vendor-confirmed. It will blast a week of stale "your package arrived" emails to customers who have long moved on. If you are going to install any polling app for the first time on a live store, install it on a development store first, or write to their support and ask specifically how to activate notifications without the retroactive send. Track123 is the loudest example. I would test the same behavior on any of them before flipping notifications on.

Closing take

I have a low opinion of the tracking-app category as a category. The apps themselves are mostly built fine. What bothers me is that the entire market has agreed to sell a solution that inherits the exact latency a merchant is trying to escape, and to charge a monthly fee for that inheritance. If your Shopify delivery notifications matter to your customer experience, they matter inside a window measured in minutes, and no polling app is ever going to hit that window. The useful question, once you accept the architecture, is whether your customer experience truly depends on that email being fast, and if it does, whether you have enough shipments to earn a direct carrier account. Which app to install matters less than either of those.