New supply chain management technology that keeps every shipment accounted for

The shipments a 3PL can’t account for

A third-party logistics provider is judged on one thing above all. Every shipment it takes responsibility for has to arrive, on time, with a clean record of how it got there. Behind that promise sits a relay of systems. The warehouse management system handles receive, pick and pack. The transport management system builds the manifest. Each carrier has its own booking and tracking API. The customer wants proof of delivery and an accurate invoice. A single shipment touches all of them, in order, and any one of them can be down at the moment it is needed.

The trouble starts when a link in that relay drops. A carrier API times out during handover, or the warehouse system is offline for a few minutes of maintenance, and the shipment stalls part-way through. With the old integration there was often no record of where it stopped. The order sat in limbo, the customer rang to ask where their freight was, and a staff member spent the afternoon clicking between systems trying to reconstruct what had and had not happened. Multiply that across a busy week and the operations team spends more time chasing lost shipments than moving new ones.

The obligations do not ease the pressure. A 3PL carries customer SLAs on delivery windows and visibility, and needs an auditable trail of who handed what to whom and when, both for billing disputes and for its own quality records. “We think it shipped” is not an answer a logistics business can give. The systems already exist. What was missing was something to hold the whole shipment together as it crossed them.

Why Temporal, and what sits beneath it

The aim is a shipment that can survive any single system going down and still finish, with a complete record of every step. We headline these builds on Temporal because that is exactly the problem it is built for. Temporal is a durable workflow orchestration platform. It lets us model each shipment as one long-running workflow whose state is saved at every step, rather than as a string of fire-and-forget messages that each service has to track for itself.

That durability is the part that earns the trust, so it leads the design. Each shipment becomes a workflow that walks through receive, pick, pack, manifest, carrier handover, track, proof of delivery and invoice. Temporal persists the position after every step. If a worker process restarts or a downstream system is briefly unreachable, the workflow resumes from where it stopped rather than starting over or vanishing. Calls to flaky carrier and warehouse APIs are wrapped as activities with automatic retries and backoff, so a transient failure is handled without code we have to hand-write at every call site. Timers in the workflow drive SLA follow-ups, and the full execution history makes any shipment, stuck or finished, completely visible.

The supporting pieces sit around that core. PostgreSQL backs the Temporal service as its persistence store, holding the workflow state and history that make recovery possible. Docker packages the workers and the Temporal services so the same setup runs the same way in development and in production. We kept the orchestration layer separate from the systems it coordinates on purpose, so the WMS, TMS and carrier integrations stay loosely coupled and a change to one does not ripple through the rest.

Building it, and where it got hard

The orchestration engine was rarely the hard part. The friction lived in the systems it had to talk to, and one problem stood in for the rest. Things going down at the wrong moment.

In the old integration, a brief carrier API outage or a short WMS maintenance window was enough to lose a shipment. The hand-off was a single call. If it failed, the shipment was left in a half-finished state with no record of where it had stopped, and brittle retry logic scattered through the codebase made the behaviour hard to predict. Staff found these orders only when a customer complained, then pieced the story back together by hand. “Mostly reliable except when a carrier hiccups” is not a standard a 3PL can run on, because the hiccups are routine.

The fix was to model each shipment as a durable Temporal workflow so its state always persists. Every step that calls an external system is an activity with automatic retries and backoff, so a flaky carrier or warehouse API is retried until it recovers rather than dropping the shipment. The workflow parks at the failed step and resumes exactly there once the system is back, so nothing has to restart from the beginning. Timers raise an SLA follow-up when a step runs long, which turns a silent stall into a visible exception a person can act on. Because Temporal keeps a full execution history, any stuck shipment can be found and recovered, and the audit trail the business needs for billing and quality falls out of the same record.

Two constraints shaped the rest. Carrier APIs enforce rate limits, so handover calls were paced and batched rather than fired on every retry. And because every shipment is a record the business may have to answer for, the execution history was retained to match the 3PL’s auditability and customer-visibility obligations, with sensitive customer detail kept out of logs.

What changed

In a representative build, shipments stopped going missing during the moments that used to break them. When a carrier API or the warehouse system was briefly down, the affected shipments parked at the failed step and resumed on their own once the system recovered, instead of waiting for a person to notice. A shipment that breached an SLA window or failed a handover raised itself as an exception, so the operations team worked a short queue of genuine problems rather than auditing every order to find the few that had stalled. And because every shipment carried a complete, replayable history, any question about where an order was, or why it stopped, had a precise answer instead of a guess.

These figures are illustrative. They describe the pattern we see rather than a published result for a named provider. The shape is the point. The work of chasing lost shipments by hand comes off the operations team, exceptions surface early enough to act on, and the business can account for every shipment it touched, which is the whole job.

Where this fits

Durable shipment orchestration is one application of our Integration Services work, built on Temporal, for the realities of an Australian third-party logistics provider. It is a contained, high-return starting point, because the WMS, TMS and carrier systems already exist and the value comes from holding a shipment together as it crosses them. If shipments go quiet whenever a carrier or warehouse system blinks, the place to start is to map your shipment journey across those systems and decide where a durable workflow would stop orders falling through the cracks.