Carrier integration

Carrier integration is the connection between a merchant's systems and the shipping carriers that deliver its orders. It covers sending shipment data to the carrier to produce labels and manifests, and receiving tracking events back as the parcel moves. Each carrier publishes its own interface for that, the USPS Track and Confirm API being one, and the wider connector layer this sits inside is third-party integrations. Integrations are built either directly to each carrier's API or through an aggregator that normalizes many carriers behind one interface, and the choice between those two shapes most of the trade-offs below.

Direct or aggregated, and the checklist stops short of claims

Direct integration means building and maintaining a connection per carrier, each with its own authentication, data format, service codes, and event vocabulary. Aggregators and multi-carrier platforms provide one interface across many carriers, trading some control and per-carrier depth for far less maintenance. The functional coverage to check in either case is label generation, rate retrieval, manifesting, tracking events, address validation, and claims submission, since integrations frequently cover the first three and stop short of the last two. Claims in particular are a defined process on the carrier's terms rather than the merchant's, as FedEx sets out for its own. Sandbox availability and rate limits determine how testable the integration is before it carries live volume, and credentials are part of the same question, since an OAuth 2.0 token that expires without anyone noticing stops a feed as completely as an outage does.

The coverage checklist is right and it skips the obstacle that actually stops these projects, which is getting access at all. Difficulty obtaining API keys from third-party logistics providers is not an occasional problem, it is one of the most common things we hear, and it has nothing to do with technical capability on either side. The practical answer we landed on is that where a provider or a specialist carrier has no usable API, a browser operator logs in the way a person would and pulls the data anyway. That is not elegant. It is the difference between a carrier being visible and a carrier being a black box, and a black box in this layer is where orders go to disappear. What that disappearance looks like downstream is a delivery exception nobody acted on.

Remove the carrier portal from the dispatch path

The efficiency case is the removal of manual work between order and dispatch: labels generated automatically from order data rather than keyed into a carrier portal, service selection applied by rule rather than by judgement, manifests closed on schedule, and tracking numbers written back to the order and the customer without a person copying them. The measures are orders dispatched per labor hour, time from pick completion to label, and the share of shipments requiring any manual carrier-portal interaction. Definitions for the wider set are on ecommerce KPIs, and the tooling category is parcel software.

Rate shopping without promise awareness is the common error

Cost effects come from rate shopping across carriers and services, avoiding surcharges through accurate weights and dimensions, selecting the cheapest service that still satisfies the delivery promise, and reducing failed deliveries through address validation. The often-missed component is invoice auditing: carrier invoices contain adjustments for dimension corrections, residential surcharges, and failed-delivery fees, and reconciling those against expected charges requires the shipment data an integration provides. Rate shopping without promise awareness is a common error, since the cheapest service frequently cannot meet the date the customer was given. Whether it is being met is on-time delivery, and the carrier's own version of that measurement is published by USPS.

Carriers will always drop the ball, so who tells the customer first

Integrations fail in ways that are easy to miss because they are silent. Label generation can fail for a single order while the batch succeeds. Tracking event feeds can stop updating without erroring. A carrier can return a scan sequence that never reaches a delivery event, which for US domestic mail eventually becomes a Missing Mail search rather than a resolution. The design questions are whether failures alert someone, whether they retry, and whether an order that failed to generate a label is visibly distinguishable from one awaiting pickup. This section is where most of the operational value of a good integration actually sits, and it is the least commonly specified.

This is the section that matters, and it is the least specified part of every integration scope I have read. Here is the position underneath it: carriers will always drop the ball. That is not a criticism of carriers, it is the operating reality of moving physical objects, and no integration project is going to change it. The question that is actually in your control is who tells the customer first. Every time a shopper has to go and find something out for themselves, friction has already been added, and by then you are recovering rather than delivering. The way to catch it is to connect to the carriers directly rather than take a feed from something in between, and then cross-correlate: what does the storefront say about this order, what does the carrier say, and where do the two disagree. The disagreement is the exception, and it exists hours before any customer notices. That is the argument I took to Add To Cart, and it is what proactive customer service means in practice rather than as a slogan.

The staleness is measurable. In the 786 pain points we mined from 270 customer call transcripts between May 2025 and May 2026, tracking information was the most consistently broken integration layer, and feeds taken through an intermediate were routinely four to eight hours behind the carrier because of infrequent polling. Connecting to the carrier directly rather than through something in between closes most of that gap, which is why we do it that way.

Who are you going to call

The customer-facing output is the tracking experience, and its quality depends on event normalization across carriers, since each uses different status vocabularies and granularity. Normalization into a consistent set of milestones is what makes a single tracking page or notification flow possible across carriers. The industry already has a vocabulary for it in the GS1 EPCIS standard, which is worth knowing about before inventing a status model. The customer-facing outputs are final mile delivery tracking and delivery notification software. The operational counterpart is internal visibility: a view of every in-flight shipment with its carrier, promise date, and current state, which is what makes it possible to act on a stalled parcel rather than discover it through a customer contact. The merchant-side surface for that is order tracking software.

Event normalization is the technical requirement and there is a simpler test for whether an operation has this working. Multi-geography, multi-warehouse, multi-carrier, and something has gone wrong with one order: who are you going to call? If the answer involves choosing which of several portals to log into first, the visibility is not there regardless of how good the tracking page looks. Every order is a promise, and a promise made across four carriers still has to be answerable in one place. What that place looks like as a system is omnichannel order management, and the operating model around it is post-purchase operations.

• United States Postal Service. USPS Track and Confirm API. One carrier's published interface, as an example of the per-carrier problem.
• FedEx. FedEx sets out for its own. Claims as a carrier-defined process.
• IETF. OAuth 2.0. Credentials expiring as a silent failure.
• United States Postal Service. published by USPS. A carrier measuring itself against a stated standard.
• United States Postal Service. Missing Mail search. Where a scan sequence with no delivery event ends up.
• GS1. GS1 EPCIS standard. An existing vocabulary for event normalization.