About5 min read
Ecommerce Shipping Integration: The Four Exchanges That Have To Agree
A shipping integration is not a setting. It is four separate exchanges with a carrier that all have to keep agreeing, at four different moments, while a customer waits. Which one breaks tells you what kind of problem you have.
By Juan Molina
On this page
Ecommerce shipping integration is usually described as a connection between two systems, which makes it sound like a setting. It is closer to a contract: four separate exchanges that have to keep agreeing with each other, at four different moments, while a customer waits.
Most integrations break at one of those four moments, and which one tells you what kind of problem you have.
The four exchanges
1. Rating, while the customer is watching
The cart has items, an address has been entered, and something has to produce a price. This is the only one of the four that happens in front of a customer, and it is the only one with a hard time limit.
A carrier rate call takes a few hundred milliseconds on a good day. Add a slow network, a cold connection, and two carriers queried in series rather than parallel, and you are into the seconds. The customer does not know what a rate call is. They know the page is stuck.
The decisions that matter here are what happens when the carrier is slow and what happens when it fails. A cached fallback rate is not as accurate and is much better than a spinner. An integration with no answer to this is the most common cause of abandoned checkouts that nobody can explain.
2. Labels, and the fact that they cost money
Buying a label is a purchase. It creates a real financial obligation to the carrier, which makes it the exchange where retries are dangerous.
If the label request times out, you do not know whether the label was created. Retry and you may have bought two. Do not retry and the order may sit unfulfilled. This is why the request needs an idempotency key, and why label creation should record its attempt before it makes it, not after.
Voiding matters too. Labels can usually be voided within a window, and an integration that cannot void is one that quietly accumulates paid-for labels nobody used.
3. Tracking, which is a stream, not a fact
A tracking number is issued once. Its status changes many times, and those changes arrive whenever the carrier decides.
Two ways to receive them: poll the carrier on a schedule, or register a webhook and be told. Polling is simpler and wrong at scale, because you spend most calls learning nothing changed. Webhooks are correct and mean handling deliveries that arrive out of order, twice, or for a shipment you already marked delivered.
Either way, the status the customer sees is a copy of something the carrier knows. How stale that copy is allowed to get is a decision somebody makes, explicitly or by accident.
4. Addresses, before any of the above
Validation is the exchange people skip and then reintroduce after their first month of returned parcels. A rate quoted against an address that does not exist is fiction, and a label printed for it is a parcel that comes back.
The subtlety is that validation is a suggestion, not a verdict. Correcting a customer's address without telling them produces a different failure: a parcel confidently delivered somewhere they do not live.
Where integrations actually break
Rate calls in series. Two carriers queried one after another take twice as long as two queried together. This is the single most common cause of slow checkouts, and it is a code change rather than a carrier problem.
No timeout budget. If the integration will wait as long as the carrier takes, the carrier decides how long your checkout is. Set the budget, then decide what to show when it is exceeded.
Retrying a purchase. Covered above and worth repeating, because it is the failure that costs money rather than time.
Test credentials in production. Carrier sandboxes return plausible rates and unusable labels. The failure surfaces at the depot, days later.
Dimensions that are guesses. Carriers bill on dimensional weight. If your products do not carry real dimensions, your quotes are wrong in a direction that is not in your favour, and the adjustment lands on an invoice weeks after the sale.
Build or use what exists
Carrier APIs are documented and you can call them yourself. Whether you should depends on how much of the above you want to own.
Writing it yourself means you own retry semantics, timeout behaviour, webhook ordering, void windows and every carrier's particular interpretation of an address. All of it is tractable. None of it is quick, and carriers change their APIs on their own schedule.
Using an integration means those decisions are made for you. Whether they were made well is worth checking, and the four exchanges above are what to check them against.
Where we fit
We handle the four exchanges inside the same backend that holds the orders: rates at checkout on your own UPS and FedEx accounts, label creation and printing, tracking against the order, and destination rules that can refuse a state before the order is taken. Because the shipment and the order live in one system, there is no sync step where the two can disagree about what shipped.
Where we are the wrong answer: if you need carriers we do not support, that is a hard stop. If you are staying on your current platform, a dedicated integration is far less work than moving your backend for this alone.
If you want to see the actual shape of the calls before deciding, the docs have the endpoints.
