Your TMS knows what was dispatched. Your customers know what arrived. The gap between those two facts is where your support queue lives.
Carrier updates sitting in separate portals, ops teams manually copying tracking numbers, and customers sending "where is my order" emails at 9 AM. These are not technology failures. They are integration failures. The data exists. It just never reaches the place where it would actually be useful.
Connecting shipping logistics and tracking management software to your TMS closes that gap. Done correctly, status updates flow automatically from carriers to your system of record, exceptions surface before customers notice them, and your team stops logging into six dashboards to piece together a single shipment view.
Key Takeaways
- Carrier tracking APIs poll on intervals of 2 to 15 minutes. Any vendor describing this as "real-time" is using marketing language, not a technical specification.
- AfterShip supports 1,100 or more carriers. Most US operations use 5 to 8 carriers, which means carrier count is a misleading buying signal when evaluating tracking platforms.
- Status normalization is the hardest part of the integration. UPS, FedEx, USPS, and DHL each use different status codes for the same physical event, and mapping them accurately requires ongoing maintenance.
- Integrations built on direct carrier APIs break on average twice per year due to carrier-side API changes. Middleware layers like EasyPost or Shippo absorb those changes so your application does not have to.
- Operations shipping fewer than 100 parcels per day rarely need enterprise freight visibility platforms like Project44 or Fourkites. The cost-to-coverage ratio inverts below that threshold.
- Webhook delivery from tracking platforms fails 1 to 3% of the time under normal conditions. Any production integration needs a polling fallback to catch missed events.
- Custom-built tracking integrations deliver faster ROI than off-the-shelf tools when your workflow has non-standard status triggers, multi-leg shipments, or carrier combinations the platforms do not support.
What Separates a Reliable Tracking Integration from One That Creates More Problems
The instinct is to connect directly to carrier APIs and pull status data on a schedule. It works in development. In production, it becomes a maintenance obligation.
Each carrier maintains its own API specification, authentication method, and status taxonomy. UPS uses numeric event codes. FedEx uses alphanumeric activity codes. USPS returns different fields depending on whether the package is tracked through their web API or the SCAN form system. DHL Express and DHL eCommerce are separate APIs with different behavior.
When a carrier updates their API, your integration breaks. They do not coordinate this with your engineering calendar.
The better architecture for most operations uses a multi-carrier middleware layer. Platforms like EasyPost and Shippo integrate multiple carrier APIs under a single normalized endpoint. You connect once to the middleware, and they handle carrier-side changes. Status codes come back in a common format regardless of the underlying carrier.
The tradeoff is cost and coverage. EasyPost charges per API call at volume; Shippo works on a per-label or subscription model. Both cover the major US carriers plus several hundred regional and international ones.
For operations with consistent carrier mix and volume, the middleware cost is typically lower than the engineering time required to maintain direct carrier connections.
How to Integrate Shipment Tracking with Your TMS: Step by Step
The steps below assume you are building or configuring an integration between your TMS and a carrier-agnostic tracking layer. The same sequence applies whether you are using an off-the-shelf platform or a custom Glide application.
Step 1: Audit your carrier mix and shipment volume
Before selecting any tracking platform, list every carrier your operation uses in a rolling 90-day window. Include parcel carriers (UPS, FedEx, USPS, DHL), regional carriers, freight brokers, and any 3PL partners who generate their own tracking numbers.
This audit drives platform selection. A parcel-only operation has different requirements than one mixing LTL freight with last-mile delivery. Confirm that your candidate platform supports every carrier on your list before committing. For operations that ship across multiple carrier types and need a full comparison of platform options before selecting one, the shipment tracking software with multi-carrier support guide covers carrier depth and normalization quality in detail.
The expected outcome of this step is a documented carrier list with approximate monthly shipment volume per carrier. That data also determines the pricing tier you will land on with most middleware platforms.
Step 2: Choose between middleware, carrier-agnostic platform, or custom integration
Three integration patterns exist for this problem, and the right choice depends on your volume, workflow complexity, and the team maintaining the integration.
Middleware (EasyPost, Shippo): Best for parcel-focused operations that need normalized tracking data without building carrier-specific connections. Monthly cost scales with volume. Engineering lift is low.
Carrier-agnostic tracking platforms (AfterShip, Narvar, Wonderment, Malomo): Best for operations that need branded tracking pages, customer notifications, and analytics on top of raw status data. These platforms consume tracking numbers, not shipping labels, which means they layer on top of your existing shipping infrastructure.
Custom integration: Best when your TMS uses non-standard data models, your workflow has multi-leg shipment logic, or you need tracking status to trigger internal automations that off-the-shelf platforms cannot support. LowCode Agency builds these integrations on Glide when operations need visibility across carriers and systems that do not connect out of the box.
For enterprise freight and intermodal operations, Project44 and Fourkites provide network-level visibility including GPS positioning and ETA predictions. These are substantively different products from parcel tracking platforms and carry correspondingly higher price points.
Step 3: Map your status taxonomy before building
Every carrier-agnostic platform returns a normalized status, but "normalized" is doing a lot of work in that sentence. AfterShip uses status categories like "In Transit," "Out for Delivery," and "Failed Attempt." Your TMS may use entirely different language or need tracking status to map to specific internal order states.
Before writing a single line of integration code or configuring a single webhook, document the full mapping between the platform's status codes and the states your TMS recognizes.
This mapping document becomes the specification your integration is built against. Changes to it downstream are expensive. Get it right before you build.
Warning: Skipping the status mapping step is the most common reason tracking integrations require a rebuild within 12 months. Discovering mid-production that "Delivered" in AfterShip does not match "Confirmed Receipt" in your TMS, and that nobody mapped the exception states, costs more to fix than the mapping exercise would have taken.
Step 4: Configure webhooks with a polling fallback
Most tracking platforms support webhooks: they push a status update to your endpoint when a carrier event occurs. This is the correct primary mechanism. Polling on a timer creates unnecessary API calls and adds latency.
Set up your webhook endpoint to receive events from the tracking platform. Validate the payload signature if the platform supports it (AfterShip and EasyPost both do). Write the incoming status to your TMS immediately on receipt.
Then build the fallback. A daily or twice-daily polling job that checks active shipments and compares stored status against the platform's current status catches any webhook events that failed delivery. This is not redundant engineering. Webhook failures happen, and the polling job is what prevents a shipment from getting stuck in a stale status for days.
Step 5: Build exception alerting before customer-facing features
The temptation is to build the branded tracking page first because it is visible and satisfying. Build the exception alerting first because it is what actually reduces cost.
An exception is any status that deviates from the expected delivery path: delivery failure, address exception, customs hold, significant delay. Configure your integration to write these events to a separate queue or trigger a notification the moment they are received.
Operations that catch exceptions within the hour of their occurrence can contact the carrier or customer before the customer contacts them. That shift in sequence eliminates a meaningful percentage of support tickets.
After exception alerting is stable, build the customer-facing tracking page or notification emails. At that point you have confidence in the data quality feeding it.
Step 6: Connect tracking status to downstream TMS workflows
A tracking integration that only displays status is an analytics tool. One connected to your TMS workflows is an operational tool.
Common downstream triggers include: updating order status on confirmed delivery, releasing payment holds when a freight shipment reaches its destination, flagging orders for manual review on failed delivery attempts, and generating a replacement shipment workflow when a package is confirmed lost.
The specific triggers depend on your operation. But defining them at integration time, rather than as a later phase, means you design the data model to support them from the start.
Logistics automation platforms handle some of these triggers with pre-built connectors, but operations with non-standard workflows often find the trigger logic requires custom configuration regardless of the platform.
What to Get Right Before You Scale
A tracking integration that works at 200 shipments per week behaves differently at 2,000. The architecture decisions that look fine at low volume become visible at scale.
The first thing to validate is webhook throughput. If your integration endpoint is synchronous (it processes each incoming event before acknowledging receipt), you will see latency and timeouts as volume increases. An async pattern, where you acknowledge the webhook immediately and process the event from a queue, handles volume spikes without dropping events.
The second is status deduplication. Carriers sometimes emit the same event twice. Your TMS should compare incoming status against stored status and skip writes when nothing has changed. Without this, audit logs become noisy and status-triggered workflows fire twice.
The third is carrier onboarding. When you add a new carrier, you need to verify that the tracking platform supports it, that the status codes map correctly into your taxonomy, and that exception handling is configured for that carrier's specific failure modes. This is a process to document and repeat, not a one-time task.
Logistics management software vendors increasingly offer pre-built tracking modules, but these modules typically support a fixed carrier list and limited customization. Operations that outgrow those constraints usually find that a purpose-built integration is more maintainable long-term than a heavily customized vendor module.
For operations running 3PL fulfillment, platforms like Extensiv (formerly 3PL Warehouse Manager) and Deposco have native tracking integrations, but they pass data to your TMS in formats that still require mapping work on the receiving end. The cargo tracking software guide covers how 3PL-specific platforms handle multi-client visibility and where custom integrations are typically required.
Pro tip: Request a sandbox environment from your tracking platform before building against production. AfterShip, EasyPost, and Shippo all offer sandbox modes with simulated carrier events. Testing your exception handling against simulated failure scenarios before go-live catches mapping errors that only appear on edge cases.
Conclusion
The integration itself is not complicated. What makes it hard is the number of places where imprecise decisions compound: a status mapping that does not account for exception states, a webhook setup without a fallback, a data model that cannot support downstream triggers. Start with the audit, build the mapping before the code, and treat exception alerting as the first deliverable rather than the last.
Operations that get this right stop managing tracking data manually. They start managing exceptions only, which is where operational attention actually belongs.
Working Through a Complex Tracking Implementation
Most shipment tracking challenges look manageable until you are the one connecting multiple carriers, syncing data across legacy systems, and maintaining accuracy at scale. The architecture decisions made at the start determine what is possible six months in.
LowCode Agency has built custom logistics and tracking applications for operations ranging from regional distributors to enterprise supply chains. The same integration problems appear regardless of company size: carrier API inconsistencies, data latency, and status normalization across carrier networks.
If you are building something that needs to work without compromise, schedule a consultation with our Senior Partners. We will assess your requirements and tell you exactly what to expect.
Schedule a Consultation
Frequently Asked Questions
Q: What is the difference between a TMS and shipping logistics and tracking management software?
A TMS manages transportation planning, carrier selection, and freight billing. Tracking management software handles post-dispatch visibility. Most modern TMS platforms include a tracking layer, but operations with complex carrier mixes often need a dedicated tracking integration.
Q: Can I integrate AfterShip directly with my existing TMS?
AfterShip offers native integrations with Shopify, WooCommerce, and several ecommerce platforms. Direct TMS integration typically requires using their API or a middleware connector, as most enterprise TMS platforms are not in AfterShip's pre-built integration library.
Q: How often do carrier tracking APIs update shipment status?
Carrier APIs update between every 2 and 15 minutes depending on the carrier and scan event. USPS and regional carriers tend toward longer intervals. FedEx and UPS update more frequently but still use polling, not true push events.
Q: What causes tracking status to stop updating mid-shipment?
Common causes include carrier scan gaps in rural areas, handoffs between carrier networks with no status bridge, and customs holds that freeze the status in the origin country system. Exception alerting configured at integration time surfaces these stops immediately.
Q: Is EasyPost or Shippo better for US parcel integrations?
Both cover UPS, FedEx, USPS, and DHL. EasyPost tends to be preferred for API-first teams needing flexible label generation alongside tracking. Shippo is easier to configure for teams without dedicated engineering resources. Pricing differs; compare at your actual monthly volume.
Q: Do I need a freight visibility platform like Project44 if I ship LTL?
Project44 and Fourkites are designed for high-volume LTL and truckload operations needing network-level ETA predictions and GPS positioning. Operations shipping fewer than 50 LTL loads per week typically find the cost does not justify the coverage at that volume.
Related reading: shipment tracking platform overview, supply chain tracking software guide, order shipment tracking software options