Logistics carrier integration

Pain

A logistics operator worked with 12 carrier partners. Each had a different API or EDI format for bookings, status updates, and proof of delivery. The internal team maintained a custom integration for every carrier, and those integrations broke whenever a carrier pushed an update. Nobody was monitoring proactively - operations staff discovered failures, not tooling. Adding a new carrier took weeks.

What we built

A normalised carrier layer that sits between the internal TMS and all 12 carriers. Each carrier’s format is translated in both directions (booking, status, POD) behind a single consistent API. The layer monitors carrier API health and response times and surfaces unified shipment status across all carriers in real time.

flowchart LR
C1[Carrier 1<br>REST] --> NORM[Normalised<br>carrier layer]
C2[Carrier 2<br>EDI] --> NORM
C3[Carrier 3-11<br>mixed] --> NORM
C4[Carrier 12<br>SOAP] --> NORM
NORM --> TMS[Internal TMS]

What we own

All 12 integrations, permanently. When a carrier changes their API, updates their EDI schema, or deprecates an endpoint, we detect it and fix it before operations is affected. New carrier onboarding follows a standardised adapter pattern: the internal team requests a carrier, we deliver the integration within the agreed SLA.

Business outcome

The internal team stopped doing carrier integration maintenance entirely. No more emergency fixes at odd hours when a carrier pushes an update. Onboarding a new carrier went from weeks to days. One avoided outage that would have hit same-day delivery SLAs paid for six months of the contract.