Real-time TMS sync that gave 2,000+ customer locations live shipment visibility

To maintain client confidentiality, the company and industry in this case study have been anonymized. The underlying solution is the same.

The problem

Westport Foodservice’s customers (restaurants, schools, cafeterias, hospitals, mid-sized hotel kitchens) needed to know where their incoming shipments were. Receiving staff had to know when trucks would arrive. Cold storage had to be prepped. Inventory and menu decisions hinged on shipments showing up when expected.

Westport had the data. Their TMS knew every truck’s location, every stop’s ETA, every delay. The problem was that the data lived in Westport’s TMS, and their customers worked in their own systems: inventory management, restaurant ops platforms, warehouse management for the larger accounts. Customers didn’t want to log into a separate Westport portal to see when their shipment was arriving. They wanted to see it in the system they already used to run their business.

The existing answer was end-of-day data dumps and manual phone calls. Receiving teams were operating on yesterday’s information, and the customer service team at Westport was spending hours each day answering “where’s my truck” calls that the data could have answered automatically.

What we built

A real-time integration bridge that connects Westport’s TMS to the nine different platforms its customers run their operations on. Shipment status, location, ETA, and delivery confirmations stream from Westport’s TMS into each customer’s own system within seconds of the underlying event.

Each customer endpoint speaks a different protocol. Some have modern REST APIs. Some expose webhooks. Some only accept SFTP file drops on a schedule. A few have nothing official at all and required custom integration patterns built against their UI. We built a translation layer that takes a single canonical shipment event from Westport’s TMS and renders it correctly for whichever customer system needs to receive it.

The bridge is built around an event-streaming backbone (Kafka) with stateful enrichment in Python services backed by Postgres. State for every active shipment lives in the bridge: which customer is expecting it, which platforms they run, what format each one wants. When a truck’s GPS ping updates the ETA, the change fans out to every customer system that needs to know, in the format that system can consume, in under twenty seconds.

For customers without modern APIs, we built reliable polling-and-translation patterns with deduplication, retry, and dead-letter handling. For everyone else, the integration is fully event-driven and idempotent. The whole system runs on Kubernetes with horizontal scaling across the Kafka partitions.

Results

Westport’s 2,000+ customer locations now see live shipment status from the systems they already work in. Receiving teams know when trucks are arriving with enough lead time to staff the dock and prep cold storage. Inventory and menu decisions are made on real data rather than estimates. The “where’s my truck” call volume to Westport’s customer service team dropped by more than 70% in the first quarter after rollout.

The bridge syncs shipment status across 9 different customer TMS, inventory, and warehouse-management systems within seconds of the source event. Westport’s operations team adds new customer system types without rebuilding the integration layer each time, because the translation logic is data-driven rather than per-customer code.

More importantly: Westport stopped being the slow-data partner in its customer relationships. The distributor that delivers food on time and tells you where the truck is in real time keeps the contract longer than the one that delivers food on time and answers the phone when you call asking.