How Retailers Can Choose Tracking Coverage for International Parcels
Retailers should choose tracking coverage for international parcels by matching the level of shipment visibility to the parcel’s route, service type, customer promise, and operational risk—not by selecting the provider with the largest published carrier list. A practical decision starts with the first-mile carrier, the destination delivery partner, the events available at each handoff, the refresh speed, and the actions the retailer must take when a parcel stops moving.
Tracking coverage is a business decision as much as a technical one. A low-value order may only need basic milestone updates, while a high-value, time-sensitive, or regulated shipment may require more frequent events, exception handling, delivery confirmation, and a clear escalation process. The right choice gives customers useful information without paying for visibility that the underlying carrier service cannot provide.
What “tracking coverage” actually includes
Tracking coverage is often reduced to a question such as “How many carriers does the system support?” That number can be useful as an initial screening signal, but it does not explain what a retailer or customer will actually see. Coverage has several separate dimensions.
- Carrier and service coverage: whether the system recognizes the specific postal operator, express carrier, consolidator, freight provider, or last-mile partner used for the shipment.
- Geographic coverage: whether the relevant origin, transit, and destination countries are supported, including cross-border handoffs.
- Event coverage: whether the system receives only label or acceptance events, or also provides departure, customs, arrival, out-for-delivery, delivery, exception, and return events.
- Handoff coverage: whether tracking continues after the parcel is transferred to a destination-country postal operator or another delivery partner.
- Update continuity: whether updates remain available when a parcel changes transport providers, tracking numbers, or data formats.
- Integration coverage: whether the retailer can send tracking data to its store, order-management system, customer service tools, email flows, or analytics environment.
These dimensions should be assessed separately. A carrier may be recognized in a system but provide only limited public events. Conversely, a parcel may have strong end-to-end visibility even when multiple carriers are involved, provided the handoffs can be linked and the destination partner exposes usable status data.
Start with the parcel flows that matter most
Before comparing tracking platforms or APIs, create a shipment map from actual orders. Group parcels by the factors that affect visibility and customer expectations.
- Origin and destination country
- Carrier, service level, and shipping method
- Use of postal, express, economy, consolidator, or local delivery services
- Typical parcel value and product sensitivity
- Expected delivery window shown at checkout
- Frequency of customs delays, address problems, or delivery exceptions
- Return, replacement, refund, or customer-service consequences when tracking goes silent
This exercise prevents a common purchasing mistake: evaluating coverage against a generic list of countries rather than against the retailer’s own shipping lanes. A system that supports a large number of carriers may still be a poor fit if it does not reliably cover the retailer’s highest-volume services or the local partners used after import clearance.
Use a lane-level coverage matrix
Build a matrix with one row for each important carrier and service combination. At minimum, record the origin, destination, first-mile provider, destination provider, tracking-number format, expected event sequence, and the customer-facing promise.
| Coverage question | What to verify | Why it matters |
|---|---|---|
| Is the carrier identified? | The exact carrier and service, not just the parent group | Different services can expose different data |
| Does tracking survive handoff? | Destination partner and linked or replacement tracking numbers | Customers need visibility after import or transfer |
| Which events are available? | Acceptance, transit, customs, delivery, exception, and return events | Event depth determines the actions support teams can take |
| How current is the data? | Polling or push behavior, refresh expectations, and outage handling | Stale data can create false reassurance or unnecessary contacts |
| Can the data be used operationally? | API fields, webhooks, exports, alerts, and status normalization | A tracking page alone may not support intervention |
Distinguish carrier recognition from useful visibility
A provider’s carrier directory is not the same as guaranteed end-to-end tracking. Ask how the provider defines support. Does “supported” mean that a tracking number can be identified, that a current status can be returned, or that a complete event history is available? These definitions should be written into the evaluation record.
Retailers should also check whether coverage differs by service type. A national postal operator may publish tracking for registered or priority services but offer limited events for an untracked economy product. An express carrier may provide detailed scans on its own network, while an intermediary or cross-border injection service may expose fewer events before the parcel enters the destination network.
The most reliable approach is to test real or representative tracking numbers. Use several shipment states rather than one successful delivery: newly accepted, in transit, held in customs, delivered, returned, and inactive for an extended period. Compare the raw carrier response with the normalized status shown to customers and staff.
Evaluate the customer experience separately from the operations layer
International tracking has two audiences. Customers want a clear answer to “Where is my order and what should I expect next?” Operations and support teams need more detail, including the last confirmed event, the responsible carrier, the likely exception category, and the next action.
For the customer-facing layer, assess whether the system can present understandable statuses without overstating certainty. “In transit” may cover several days and multiple transport legs; it should not be presented as a precise arrival forecast unless the underlying data supports that interpretation. Delivery estimates should also distinguish between a carrier-provided estimate, a retailer promise, and an editorial prediction.
For the operational layer, assess search, filtering, alerts, event history, carrier identification, and export or API access. A support agent may need to find all orders affected by a customs issue, identify parcels with no event after dispatch, or confirm whether a delivery attempt occurred. These workflows are often more valuable than an attractive tracking page.
Choose the right technical model
Hosted tracking tools
A hosted tracking tool can be suitable for retailers that need a customer-facing tracking experience without building the full data and interface layer themselves. Check the available branding, order lookup, notifications, language options, analytics, and store integrations. Confirm how the tool handles unknown carriers, duplicate shipments, and tracking numbers that change during a cross-border handoff.
For Shopify merchants, the 17TRACK Shopify app is one product option to evaluate for order-tracking and post-purchase workflows. Its suitability should be confirmed against the retailer’s actual carriers, storefront needs, notification policy, and test shipments rather than assumed from the app category alone.
Tracking APIs
An API is more appropriate when tracking data must be embedded in an order-management system, customer-service platform, mobile application, or custom post-purchase journey. The evaluation should cover authentication, request limits, webhook behavior, event schemas, error handling, carrier identification, data retention, and the treatment of uncertain or conflicting statuses.
17TRACK publishes a tracking API overview and separate API documentation. These are useful starting points for a technical review, but a retailer should still validate the exact carriers, fields, service limits, and commercial terms required for its lanes.
Direct carrier integrations
Direct integrations can make sense when a retailer relies heavily on a small number of carriers and needs carrier-specific features or contractual data access. They can also increase maintenance work as services, authentication methods, event formats, and delivery partners change. A multi-carrier layer may reduce that integration burden, but the trade-off is the need to verify how it normalizes events and handles carrier-specific detail.
Make coverage part of a service policy
Tracking cannot compensate for an unsuitable delivery service. If the selected shipping method produces no meaningful public events, a tracking platform may be able to show that a label was created or that a parcel entered a network, but it cannot manufacture scans that the carrier does not provide. This is a limitation of the data source, not necessarily of the tracking interface.
Set a policy for each service tier. For example, basic economy shipments might receive milestone tracking and a support rule for prolonged inactivity. Higher-value shipments might require delivery confirmation, exception alerts, and a defined escalation path. The exact thresholds should be based on the retailer’s transit patterns, customer promise, and loss or refund policy rather than copied from another business.
Also decide what happens when a parcel is not trackable. Options may include changing the service at checkout, restricting certain destinations, adding a customer notice, requesting a carrier confirmation, or treating the order as a higher-risk shipment. The important point is to make the decision before a customer reports that an order appears to have disappeared.
A practical pilot and buying checklist
Run a controlled pilot before committing to a broad rollout. Include the lanes and services that generate the most orders, plus the edge cases that create the most support work. Ask the provider to explain every result that differs from the carrier’s own tracking page.
- Define success: Decide which events, update behavior, integrations, and support actions are required for each shipment group.
- Submit representative numbers: Include active, delivered, delayed, returned, customs-affected, and newly created shipments where available.
- Compare event histories: Check carrier pages, the provider interface, and API responses for missing, duplicated, delayed, or overly broad statuses.
- Test handoffs: Verify whether destination-carrier events appear and whether a new tracking number is linked to the original order.
- Test exceptions: Confirm how the system handles invalid numbers, carrier outages, no-result responses, delivery failures, and long periods without scans.
- Test business workflows: Send alerts, search orders, export data, trigger customer-service actions, and review the information available to an agent.
- Record evidence: Keep the test date, carrier service, tracking number, observed events, and provider response so future coverage changes can be measured.
Coverage should then be monitored after launch. Carriers change service arrangements, postal partners, data interfaces, and event practices. Review high-volume lanes periodically and maintain a list of cases that require direct confirmation. Public product pages can describe a provider’s scope, but only a lane-specific test can establish whether the result meets the retailer’s operational requirement.
How to make the final decision
Choose the simplest tracking setup that meets the retailer’s real customer and operational commitments. A small merchant with a few reliable services may prefer a hosted tool. A growing cross-border retailer with several destination partners may need normalized multi-carrier data and automated notifications. A business with custom order systems may prioritize an API and webhooks. The decision should follow the workflow, not the other way around.
When comparing providers, give greater weight to verified performance on important lanes than to an impressive carrier-count claim. Ask for a clear definition of supported coverage, document the limits of each service, and separate confirmed capabilities from items that require a proof of concept or direct commercial confirmation. This produces a tracking program that is more transparent to customers and more useful to the teams responsible for delivery experience.
FAQ
Is a larger carrier list always better?
No. A larger list may improve the chance that a carrier is recognized, but it does not prove that the relevant service provides complete event histories, destination handoff visibility, or reliable update timing. Lane-specific testing is more informative than a headline count.
What should retailers do when a parcel has no tracking updates?
First, identify the last confirmed event and the service used. Check whether the shipment is still within the carrier’s normal scan pattern, whether customs or a handoff is involved, and whether the tracking number changed. Then apply a documented support or escalation rule. Do not treat a silent period as proof that the parcel is lost.
Can a tracking platform create tracking events that the carrier does not publish?
No platform can reliably create an underlying carrier scan that does not exist. It may normalize, translate, or combine available events, but retailers should distinguish carrier-reported information from estimates or operational interpretations.
Should every international parcel have the same tracking standard?
Not necessarily. The appropriate level depends on value, delivery promise, destination risk, service type, and the consequences of a missed delivery. A tiered policy can control cost while reserving deeper visibility and intervention for shipments where it matters most.
When should a retailer choose an API instead of a hosted tracking page?
Choose an API when tracking data must drive custom order workflows, support tools, notifications, analytics, or a proprietary customer experience. A hosted page may be more efficient when the retailer needs a ready-to-use experience and has limited development capacity. In both cases, verify the required carriers and events before implementation.
