Every carrier integration is its own project

Logistics briefs tend to list integrations as one item: "connect to our carriers". It reads like a single task. It is closer to one project per carrier, and the variance between them is enormous.

The range you are actually buying

• A modern REST API with sandbox credentials and real documentation — days.
• A SOAP service with a WSDL that has not been updated since 2011 — weeks, plus a permanent maintenance cost.
• An SFTP drop of fixed-width files on a schedule — workable, but you are now building a batch pipeline, not an integration.
• A partner portal with no programmatic access at all, where the honest answer is that automation is not available.

Establishing which of these you face, per carrier, before anyone quotes is the single highest-value hour in the project.

Rates and labels are different problems

Quoting a shipment and generating a compliant label are usually separate services with separate quirks. Label generation in particular is unforgiving: carriers reject consignments over formatting most people would consider cosmetic, and the feedback loop is slow.

Budget them separately. A project that can quote but cannot produce a label that passes is not half done.

Tracking is a polling problem

Few carriers push updates reliably. Most expect you to ask, which means deciding how often — and that decision has a cost on both sides.

Poll too rarely and your customer-facing tracking is stale. Poll too often and you hit rate limits or get throttled silently. The right interval varies by carrier and by shipment stage, and it is a product decision rather than a technical default.

Failure is normal operating traffic

Carrier endpoints are unavailable more often than most APIs you will integrate with. Treat that as expected rather than exceptional:

• Queue requests so a carrier outage does not block the warehouse.
• Retry with backoff, and cap it — infinite retries against a broken endpoint make the outage worse.
• Surface sustained failures to an operations dashboard, not just a log file.
• Reconcile daily; do not assume every message that returned 200 was actually processed.

Scope them one at a time

The pattern that works is to integrate one carrier end to end, in production, before starting the second. The first one teaches you what your abstraction needs to be; designing that abstraction up front, against three sets of documentation, reliably produces the wrong one.

More on how we approach this sector on our logistics page, and on the offline constraints that usually accompany it in offline-first apps.

Why can't all carriers use one integration?

Because they expose fundamentally different interfaces. One offers a documented REST API, the next a SOAP service with a decade-old WSDL, the third an SFTP drop of fixed-width files. The data they need and return also differs by lane and service level, so a shared abstraction only emerges after you have built two or three — which is why designing it up front usually produces the wrong one.

How often should shipment tracking poll?

It depends on the stage. Frequent polling while a parcel is out for delivery is useful; the same interval while it sits in a depot overnight wastes rate limit and battery for no customer benefit. Varying the interval by shipment state is a product decision, and it is usually worth more than simply polling everything faster.