What shipping labels don't tell you

There's a moment every shipping platform team goes through: you've integrated your first carrier, labels print, and packages get delivered. Then a second carrier is added. Then a third.

Generating a label is straightforward, but keeping every label correct – across every carrier, service and destination – is a different story.

To make it brief: label creation and label correctness are not the same thing!

Why carrier integration is harder than it looks

Take label format. The 4×6-inch standard is what most carriers accept. But some carriers default to 4×7 if you don't specifically override it. Or getting 4×6 in PNG format requires a support request, while in ZPL it works by default, but only for domestic shipments. That's not something you find in the headline documentation – usually you discover it the hard way, or learn from people who've already been through it.

Carriers often use their own barcode symbologies, sort codes, and product identifiers embedded in the label, which must correspond precisely to the service booked. Get any of those wrong, and the label will print perfectly, scan cleanly, and then get misrouted at the delivery office because the barcode said one thing and the booking said another. The package moves, just not where it was supposed to go.

There's also the return label problem, which is easy to overlook. Different carriers handle return label billing in entirely different ways. Some charge at the point of label creation, regardless of whether the label is ever used. Others only charge when the label is actually scanned into the carrier network. For e-commerce integrations generating pre-printed return labels at scale – particularly in fashion or apparel, where the online return rates are around 30% – choosing the wrong billing model for the wrong carrier can mean paying for thousands of labels that nobody ever uses.

On top of that, carrier requirements change, and every change is a potential failure point for any platform that doesn't catch it in time.

Barcodes aren't just tracking numbers

It's worth spending a moment on barcodes, as it is common to underestimate their complexity.

A barcode on a shipping label encodes the contractual terms of the shipment: the selected service and enhancements, routing information, sort codes, etc. When the barcode is wrong, the package may still be processed based on what the barcode says, which might differ from what was booked or what the shipper intended. That's an easy step to having a next-day shipment that ends up in a standard ground lane: the label was generated, and the barcode was technically valid, but the shipment was handled incorrectly.

What good carrier integration looks like

From an engineering perspective, there are a few patterns that separate stable integrations from fragile ones.

It's never a one-time integration project

Getting the integration right on day one is not sufficient. Carrier requirements evolve, new services get added, existing services change their label specifications, and international customs rules shift. Anyone who lived through the post-Brexit customs changes and had to push updates under deadline pressure knows what this looks like in practice. Someone needs to be watching for those changes, testing against them before they take effect, and pushing updates before platforms and their customers find out through failed deliveries.

Address validation has to happen early

It seems obvious that addresses must be validated, but the question is when. Validating at the point of order ingestion means you can surface the issue to the customer before the parcel is anywhere near a carrier. Validating at label print means the warehouse has already picked and packed the item. Not validating at all means you find out when the carrier's exception-handling system does, which is the most expensive intervention point possible.

Carrier-specific logic beats assumptions

One of the more common mistakes is assuming that what works for one carrier will work for another. A label layout that works for one carrier might fall outside tolerances for another, and even small differences in how optional fields are handled can introduce inconsistencies.

The more carriers you support, the more these differences matter. Treating them explicitly tends to lead to fewer surprises.

Sandbox environments don't always tell the full story

Carrier test APIs frequently behave differently from their production equivalents, e.g. returning success codes for label requests that would fail or produce incorrect output in the live environment. Testing in a staging environment connected to production carrier endpoints helps to close that gap.

Invoice auditing closes the loop

When carrier billing starts diverging from what your label data specifies, something has gone wrong somewhere. The most common sources of divergence are DIM weight recalculations, address correction fees, and fuel surcharge tier changes. Systematic reconciliation of invoices against label data is the reliable way to catch them.

Wrapping up

Label generation is not difficult, but keeping every label correct, for every carrier, as requirements evolve – that's where the real work is. The teams that stay ahead aren't necessarily the ones with the most carrier integrations, but the ones that treat carrier compliance as an ongoing operational discipline. That's the lens Happy Team bring to carrier integration work.

FAQ

What does staff augmentation actually look like in a carrier integration project?

Unlike a fixed-scope delivery, carrier integration is never finished – carriers update label specifications, new services get added, and customs rules shift. Staff augmentation means engineers embedded in your team who monitor those changes, test against updated specs before they take effect, and push updates continuously. Our longest logistics partnership started in 2015 and is still active.

How is staff augmentation different from outsourcing integrations?

Outsourcing typically means handing over a defined scope and expecting a delivery. Staff augmentation means extending your team with engineers who work within your processes, backlog, and release cycles.

For logistics platforms, where integrations evolve continuously, augmentation tends to work better because:

• requirements change mid-stream (e.g. due to carrier updates)
• testing needs access to your production environment
• knowledge needs to stay close to your system

How quickly can your engineers get up to speed on our existing carrier integrations?

Carrier integration has a steep learning curve, and these vary considerably between carriers. Our engineers have hands-on experience with Royal Mail, DPD, DHL, FedEx, GLS, Evri, and others. That means less time spent discovering how each carrier behaves and more time spent maintaining correct implementations from day one.

What skills should augmented engineers have for carrier integrations?

Carrier integration work is not just "API work". It sits between systems, operations, and real-world constraints. Engineers should be comfortable with:

• REST/SOAP APIs and inconsistent carrier documentation,
• data mapping between systems (orders > shipments > labels),
• label formats (PDF, ZPL) and printing constraints,
• debugging issues that only appear in production environments.

Can staff augmentation help with ongoing carrier maintenance, not just new integrations?

Yes, and this is where it often brings the most value because carrier integrations are not static: APIs change, label specifications evolve, billing rules get updated, edge cases appear only after going live, etc.

Augmented engineers can take ownership of:

• monitoring carrier changes,
• updating integrations proactively,
• handling production issues without disrupting your core team.