Multi-Carrier Logistics Integration for an E-Commerce Operator
An e-commerce operator managing orders across three fulfilment warehouses and five carrier integrations rebuilt their fulfilment orchestration layer, cutting manual intervention on shipments from 30% to under 3% and reducing average dispatch time by half.
2.8%
Manual intervention rate
Down from 30%
55% reduction
Average dispatch time
4.2 hours → 1.9 hours
3 days
New carrier onboarding
Down from 4–6 weeks
The challenge
The operator's order management system connected to each carrier through point-to-point integrations built over five years by different developers. Carrier API changes broke integrations unpredictably. Fulfilment staff spent significant time each day manually intervening in orders that failed to route correctly.
Objectives
- Centralise carrier integrations behind a single fulfilment API
- Reduce manual intervention rate from 30% to under 5%
- Provide real-time shipment status to the customer-facing order portal
- Allow new carriers to be added without changes to the order management system
Discovery
We audited all five carrier integrations, documenting failure modes, retry behaviour, and the manual intervention triggers. 80% of manual interventions traced to three root causes: stale rate quotes, carrier-specific address validation failures, and webhook delivery failures with no retry mechanism.
Strategy
Build an integration layer that abstracts carrier-specific behaviour behind a uniform interface. Each carrier integration becomes a pluggable adapter. Carrier selection logic (rate, speed, reliability) lives in the orchestration layer, not in the order management system.
How we approached it
We built a Node.js fulfilment orchestration service with five carrier adapters (DHL, FedEx, local carrier × 3), a carrier selection engine using configurable rules (cost, speed, destination zone), webhook normalisation and retry logic, and a real-time shipment tracking API consumed by the customer portal.
Architecture
Orchestration service in Node.js with a carrier adapter interface. Each adapter handles authentication, rate fetching, label generation, and status normalisation for one carrier. PostgreSQL stores shipment records and webhook events. Redis handles idempotent webhook processing. A separate tracking API aggregates status updates and pushes to the customer portal via Server-Sent Events.
Implementation
Carrier adapters were built and tested in isolation using carrier sandbox environments. The orchestration layer was deployed alongside the existing point-to-point integrations during a 4-week parallel-run period, processing 10% of live orders. The cutover happened carrier-by-carrier over two weeks based on parallel-run accuracy results.
Key decisions
Rebuild the order management system vs. build an integration layer — rebuilding OMS would have addressed the root architecture problem but taken 12+ months.
The integration layer provided 90% of the reliability benefit at 20% of the cost and time. The OMS rebuild was scoped as a future phase.
What changed
Manual intervention rate dropped from 30% to 2.8%. Average dispatch time reduced from 4.2 hours to 1.9 hours. The operator added a new carrier post-launch in 3 days using the adapter interface.
Impact
Fulfilment staff reclaimed the 2–3 hours per day previously spent on manual intervention. The operator could add a new carrier in days rather than weeks. Customer-facing order tracking became real-time rather than batch-updated.
Lessons learned
- 1The parallel-run period was essential — three carriers had undocumented rate-fetching behaviours that only appeared under real order conditions.
- 2Idempotent webhook processing is non-trivial; building it correctly upfront prevented significant data integrity issues when carriers sent duplicate delivery events.