A shipping API is the connection between your systems and a carrier. It fetches rates, buys labels, and pulls tracking updates without anyone logging into a carrier site. That is the clean version. The messy version is that every carrier's API is different, some are slow, and a few barely work. One carrier returns 12 status labels, another returns over a hundred, and none of them agree. So your tracking page shows raw carrier jargon instead of a clear step. This guide explains what a shipping API does and how to handle the gaps.
What a shipping API does: rates, labels, tracking
A shipping API does three core jobs. It quotes rates, it buys labels, and it returns tracking updates. Each one replaces a manual task someone used to do in a carrier portal.
Rates come first. Your system asks the carrier "what does it cost to ship this parcel to this address at this service level?" and gets a number back in real time. That number can feed checkout, or feed a routing decision behind the scenes.
Labels come next. Once you pick a service, the API buys the label and returns a file you print. Tracking is the third job. After the parcel ships, the API pulls scans so you can show the customer where it is. These three jobs are the whole reason a shipping API exists.
Direct carrier APIs vs aggregators
You can connect to carriers two ways. Straight to each carrier's own API, or through an aggregator that speaks to many carriers behind one connection.
The trade-off is control versus effort. Here is how the two compare.
| Direct carrier API | Aggregator | |
|---|---|---|
| Connections to build | One per carrier | One, to the aggregator |
| Data control | Full, raw from source | Depends on the aggregator |
| Maintenance | You handle every change | Aggregator absorbs most changes |
| Best when | You need one or two carriers deeply | You want many carriers fast |
Neither is automatically right. A brand on two carriers might go direct and keep full control. A brand adding carriers often takes the aggregator to avoid building the same plumbing five times. Many brands end up with a mix.
Why carrier data is so inconsistent (10 to 115 statuses)
Here is the part nobody warns you about. Carriers do not agree on what a tracking status even means. One carrier ships 12 distinct status codes. Another ships over a hundred. They use different words for the same event and the same word for different events.
So "your parcel is on its way" might arrive as "in transit," "departed facility," "accepted," or a numeric code, depending on which carrier scanned it. If you show that raw data to a customer, your tracking page reads like a logistics dictionary instead of a clear step.
This is not a bug you can fix with one carrier. It is the state of the whole field. The messy carrier data problem sits underneath every multi-carrier shipping setup, and it only gets worse as you add carriers.
What happens when a carrier API is slow or incomplete
Not every API works well. Some are slow to respond. Some return partial data. A few carriers, especially regional ones, barely expose an API at all.
When an API is slow, your tracking page lags behind reality. The parcel is out for delivery, but your page still says "in transit" because the last poll timed out. When an API is incomplete, whole events go missing, so the customer sees a gap and assumes the parcel is lost.
The honest answer is that you cannot always get clean data from the API alone. Sometimes the tracking data lives on the carrier's website but not in a usable API. That gap is real, and pretending otherwise leads to a broken tracking experience.
The difference between raw carrier data and a clean status
Raw carrier data is what the API returns. A clean status is what the customer should see. These are not the same thing, and the work of turning one into the other is where most tracking pages fall down.
A clean status maps every carrier's vocabulary onto one simple set of steps. Ordered. Shipped. In transit. Out for delivery. Delivered. Exception. The customer sees the same five or six steps no matter which carrier carried the parcel.
Getting there means normalizing every carrier's labels into that shared set. It is unglamorous work, and it never fully stops because carriers change their codes. But it is the difference between a tracking page a customer trusts and one that confuses them. Our guide to carrier tracking statuses goes deeper on how that mapping works.
How Pango fits: normalize APIs and scrape gaps where APIs are poor
Pango is one adaptive layer over your orders, carriers, warehouses, and returns. It is not a WMS or a 3PL. On the carrier-data problem, it does two specific things.
First, it normalizes carrier APIs. Pango maps the 10 to 115 different status labels your carriers report into one clean set, so your tracking page shows a clear step instead of raw jargon. Second, where a carrier's API is poor or missing, Pango scrapes the tracking data the carrier exposes elsewhere. That fills the gaps the API leaves.
Live today: returns and exchanges, branded tracking with proactive notifications, and analytics across your orders and carriers. Custom logic beyond that is build-to-fit, built to match your carriers and policies rather than forced into a fixed template. If you are choosing how to route orders across those carriers once the data is clean, see order orchestration. For the full platform view, see the transportation management system (TMS) product page.
What to check before you build on a shipping API
Before you commit to a shipping API, check a few things that save pain later.
Ask which carriers it actually covers, and how it handles the ones with weak APIs. A carrier list means nothing if the data behind three of them is unusable. Ask how tracking statuses come back, and whether they are normalized or raw.
Then check the update speed and the failure behavior. How often does tracking refresh, and what happens when a poll fails? Finally, confirm whether the API buys labels and quotes rates, or only tracks. Knowing the gaps before you build beats discovering them in production.
