Marketplace Carrier Integration: Labels, Tracking, and Exception States

Marketplace carrier integration is how a dozen carriers' separate dialects become one vocabulary your support team and your buyers can read, and the vocabulary is yours to own whether you build the integration or buy it.

Between your order and the parcel stand a dozen or more carriers, and each describes the same journey in its own words. If you do not settle on how your version reads, support will improvise it on every call.

This article breaks down:

• Which 3 routes connect you to a carrier?
• Why does the carrier registry break tracking?
• Who should appear on the label as sender?
• Which 5 exception states do you need?

Key insights

• The three routes to a carrier are the seller's own contracts, an aggregator holding many of them, and direct integrations one by one, and they can run side by side as long as the same vocabulary comes out of each.
• The carrier registry breaks tracking when it does not know the name a seller typed: the shipment is created, the status reads shipped, and the tracking link is never generated, which shows up only as questions to support filed under the wrong cause.
• Who appears on the label as sender settles where an uncollected parcel goes back to, who may claim against the carrier, and whose details the buyer sees: put yourself there, and 1.5% of 20,000 shipments is 300 parcels a month in your warehouse, about €4,500.
• The five exception states to name are a missed delivery with a second attempt, available for pickup, return to sender, damage or loss, and silence, and an expired shipment has to mean "we do not know" rather than "delivered".

Why are carrier statuses dialects rather than a standard?

The standard exists, just not at the point where you need it. The exchange of transport statuses has mature formats, decades old: public industry messages carry the shipment status, the reason for it, and the time and place of the event, and they repeat it at every scan.

Public commerce models for describing a shipment go the same way: a tracking number, an event history, and separate fields for the earliest and latest expected delivery date.

The envelope is standardized. The contents are not: how many words exist, what exactly they mean, and which of them will show up on your shipment at all.

One carrier reports several dozen codes and tells of a hold at the sorting hub, apart from a failed delivery. The second reports a handful.

The third can only say "shipped" and "delivered".

Hence the ruling this chapter stands on. You buy the integration, or you contract it out.

The vocabulary has to be your own. It is the vocabulary that decides what support tells a buyer about a shipment nobody has seen for three days.

A vocabulary is a product rather than a setting, and you can tell by three things. It has an owner: one person who approves adding a word.

It has a version and a date, because your sellers' integrators have to know when something changed. It has an openly stated cost of change, calculated before launch rather than after.

What an extra state visible to the buyer costs, and how somebody else's naming maps onto your order model, is carried by who is the source of truth for a status. This chapter works one layer below: where those words come from at the carrier.

One artifact is worth drawing on paper before anybody decides on a vendor. Rows are the states of your vocabulary, columns are your carriers, and each cell holds a yes or a no.

An empty row is a word nobody will deliver to you. An empty column is a carrier for which your vocabulary is fiction.

Which 3 routes connect you to a carrier?

1. The seller's own contracts

The default, and the cheapest at the start.

You get a tracking number from them and a carrier name typed in by hand or fed through an integrator. You chase the statuses yourself, or not at all.

2. An aggregator holding many contracts

One contract, one place where labels are created, and one channel for statuses.

A seller can use it or ignore it.

3. Direct integrations, one carrier at a time

The best data, the highest maintenance cost, and the longest road to a first working status.

Practitioners from large rollouts call it the standard route and say so without enthusiasm: coming to terms with each carrier separately is a project in itself.

One market fact is worth knowing before you talk to a vendor. No reference point available in this class of software has a ready-made hookup for a courier broker.

Every operator builds it alone or buys it separately. A separate trap: in some products the list of carriers is a closed registry held by the vendor, and adding a new one is a ticket you file with them rather than a setting on your side.

The routes do not exclude one another. There is one condition: the same vocabulary has to come out of each of them.

Why does the carrier registry break tracking links?

The registry looks unremarkable: the carrier name, a tracking link template with a slot for the number, a fallback address, and a list of alternate names.

That last item is what matters here. Sellers type the carrier name the way they hold it in their own system: sometimes in full, sometimes abbreviated, sometimes with a country name attached, sometimes with a typo.

If your registry does not know the variant, the shipment is created normally, and the tracking link never gets generated at all. The carrier is tracking it, the buyer cannot see it, and in your panel the order looks correct because the "shipped" status is set.

This is a warning specific to this layer, and there is no alert for it anywhere. You will not see it in the on-time report, because delivery was on time.

You will not see it in the error report, because there was no error. You will see it only as a rise in questions to support, filed under the wrong cause.

Hence the second decision to take deliberately. A closed list accepts only the carriers you know: a seller with an exotic carrier cannot hand over a shipment until you add it, and in exchange every number can be recognized.

An open list accepts any tracking number: nobody is blocked, but some shipments sit with you as text with no link. Operations practitioners at high volume pick the closed variant and say so plainly: the point is to be able to put a status on every order.

The threshold is numeric rather than philosophical. Once a month, count the share of shipments where you failed to recognize the carrier.

Below roughly one percent, an open list is cheap. Above five percent, you are buying a class of tickets you have no way to count.

Who should appear on the label as the sender?

A waybill is a document issued by the carrier, and it names two parties: sender and recipient. Who appears as the sender settles three things at once: where an uncollected shipment goes back to, who can file a complaint against the carrier, and whose details the buyer sees on the box.

There are three variants. In the first, the label is the seller's, on their own contract.

The sender is the seller, the complaint against the carrier is theirs, and the parcel comes back to them. In the second, the label runs on your contract but carries the seller's details as sender.

You pay for carriage, and the parcel still goes back to them. In the third, the label runs on your contract with you as sender.

You control the rate and the data, but the parcel comes back to you, and that is a physical problem rather than an entry in a system.

Do the math on that last variant before you pick it. At 20,000 shipments a month and 1.5% coming back to the sender, you have 300 parcels a month in your warehouse.

They are not yours. They are passing through.

At €15 to receive, identify, and send one on, that is €4,500 a month, or €54,000 a year for an activity nobody planned. Carriage rates and logistics classes are carried by zones, methods, and shipping rates.

Two things to write down right away. A label generated does not mean a parcel handed over.

What that means for the money is settled by when an order counts as delivered. And the second: a label canceled outside your system leaves you with an orphan shipment, waiting for a status until the end of time.

You need an explicit unlink operation, done by a human and leaving a trail.

Which 5 exception states does the vocabulary need?

The happy path is three events and needs no vocabulary. The vocabulary exists to handle the exceptions, and the exceptions are what decide its value.

You have to name five of them, because they happen every day: a missed delivery and a second attempt (the carrier came, found nobody home, and will come again), available for pickup (the parcel is at a point and waiting, which does not mean the buyer has it), return to sender (the shipment is traveling back and nobody knows to whom), damage or loss, and silence (no event of any kind for several days while the status still reads "in transit").

Silence is the interesting one, because formally it is not an event. Some products in this class name it outright and mark the shipment as expired after a few dozen days with no information.

That is a sensible pattern on one condition: "expired" has to mean "we do not know" and not "delivered".

And the mistake that costs the most for the least effort: throwing all five into one word, "problem". Each of those states carries a different instruction for the buyer.

With a missed delivery, the instruction is "wait until tomorrow". With a return to sender, it is "get in touch with us".

A word with no instruction does not reduce the number of calls. It only changes what they are about.

Who answers to the buyer for goods damaged in transit is carried by whether you are an intermediary or a seller. What the buyer can demand is who delivers the buyer's rights.

What does a missing word in the vocabulary cost?

"Where is my order" questions have their own name in the industry, WISMO, and their own arithmetic.

This is something narrower: the quality of the word you show them.

Take 20,000 shipments a month and split the contacts across three causes.

An unrecognized carrier, so no link: 6% of shipments is 1,200, and roughly half of them write in, which is 600 contacts. That entire class disappears once you fill in the alternate names in the registry.

An exception event: 5% of shipments is 1,000. With no readable message, about 60% write in, which is 600 people.

With a message that carries an instruction, the share falls to about 20%, which is 200. The difference: 400 contacts.

Silence longer than three days: 3% is 600 shipments. With no warning, about 40% write in, which is 240.

With a notification you send first, the share falls to about 15%, which is 90. The difference: 150 contacts.

Together, that is 1,440 contacts a month before you put the vocabulary in order and 290 after (600 plus 600 plus 240 against 0 plus 200 plus 90). The difference is 1,150 contacts, and at six minutes per contact, that is 6,900 minutes, or 115 hours a month.

At one euro per minute of support time, that is €6,900 a month and €82,800 a year.

The line for the committee: on a €1,000 cart at a 12% commission, you make €120 per order, so disorder in the carrier vocabulary alone eats the commission from close to 58 orders every month (6,900 divided by 120). Not GMV and not margin.

The commission.

What does carrier integration change about the rest of your build?

1. The shipment vocabulary is a contract rather than a screen

You change it together with your sellers' integrators, so the question "who pays for adding a state" gets asked before launch (the seller panel).

2. The quality of your statuses translates directly into the seller's money

The maturing of what they are owed hangs on the delivery event, and the cadence of payouts hangs on payout cycles, holds and reserves.

3. The number of shipments grows faster than the number of orders

An order split multiplies parcels, and each one is a separate label, a separate number, and a separate opportunity for a question (how one order becomes several).

4. The seller's on-time counter feeds on the same data

Before that counter starts suspending accounts, it has to tell a missing shipment apart from missing information about one (seller quality thresholds).

How do you check carrier integration with a vendor?

Ask about a screen and a specific shipment rather than a row in a feature table.

1. List every shipment state you can record, and show me whether adding a new one is a setting or a change at the integrators.
2. Is the carrier list mine or yours? How long does adding a carrier take, and do I do it myself?
3. Show me the alternate names for a carrier and a shipment where the seller typed a variant that is not on the list. What the buyer sees.
4. Where does the tracking link come from, and what happens when it cannot be assembled?
5. Show me the report of shipments with no event for N days. Not having it means you are not measuring silence.
6. Who appears as the sender on the label, and can that be set differently for different fulfillment models (fulfillment models).
7. How do I unlink a shipment canceled outside the system so it stops waiting for a status?

If questions 3 and 5 have no answer you can be shown on a screen, you are buying a field for a number rather than tracking.

Which mistakes do operators make about carrier integration?

1. A carrier registry with no alternate names

The consequence: some shipments are tracked by the carrier and untracked at your end, with no alert and no trace in any report.

2. One word, "problem", for every exception

The consequence: a message with no instruction, so the buyer writes in anyway, only now quoting your own status back at you.

3. Normalization done inside the integration, separately for each source

The consequence: two shipments in the same physical state show two different words on your side, and nobody can point to the place where you would fix it.

4. Tracking deferred to one carrier for the pilot

The consequence: you design the vocabulary around that carrier's codes, and with the second carrier it turns out not to travel.

5. A label on your contract with you as the sender, switched on without counting the returns

The consequence: other people's parcels in your warehouse and a cost that appears in nobody's budget.

What do you still have to settle about your own carriers?

This article does not describe the order status model, or who has the right to write those statuses, or what to do with an event that arrives out of order. That is, who is the source of truth for a status.

This article does not settle when "delivered" becomes a money event, what you promise the buyer about the date, how to set up zones, methods and rates, or how stock levels work (stock levels and overselling).

This article does not go into the law. Liability for goods damaged or lost in transit is carried by whether you are an intermediary or a seller.

The carriage contract and the limits of the carrier's liability are a conversation with a lawyer rather than with a platform vendor.

All the numbers above are openly hypothetical. What travels is the arithmetic rather than its result: substitute your own volume, your own share of exception events, and your own cost per contact.

Two numbers you have to measure yourself, because they are in nobody's documentation: the share of shipments with a recognized carrier, and the share of shipments where you know at least one intermediate state. Until you know them, your tracking is a declaration and not a capability.

Summary: What does carrier integration really buy you?

One sentence your support team can say about any parcel. The formats for exchanging transport statuses are decades old and standardised; what is not standardised is the vocabulary inside them, so one carrier tells a hold at the sorting hub apart from a failed delivery and the next one knows only shipped and delivered.

That leaves the words to you, with an owner, a version, and a cost of change. Underneath sit two unglamorous things that decide whether any of it works: a registry that recognises the name a seller typed, and a label whose sender has been chosen on purpose rather than by default.

Ask a vendor to add a carrier you do not have, and find out whether it is a setting on your side or a ticket on theirs. Building a marketplace where every shipment carries a status in your own words, including the exceptions?

Talk to us about the build.

Frequently asked questions on carrier integration

What is carrier integration on a marketplace?

Carrier integration on a marketplace is the layer that turns many carriers' separate status vocabularies into one that your buyers and your support team read. The exchange formats are standardised, and the words inside them are not, which is why the vocabulary has to be yours regardless of whether you build the integration, buy an aggregator, or take the numbers from sellers.

Should a marketplace keep a closed list of carriers?

A marketplace should keep a closed list once unrecognised carriers pass about one percent of shipments. A closed list blocks a seller with an exotic carrier until you add it, and in exchange every tracking number can be recognised.

Above five percent unrecognised, an open list is buying you a class of tickets you cannot count.

Who should be the sender on a shipping label?

The sender on the label should be whoever can take the parcel back. An uncollected shipment returns to the name on the waybill, so putting yourself there turns 1.5% of your volume into parcels passing through your warehouse that are not yours, at roughly €15 each to receive, identify, and send on.