Every carrier relationship, every customs jurisdiction, every enterprise customer with a connectivity requirement adds another integration point to a freight operation. Five years ago, a forwarder running CargoWise might have managed fifteen. Today, that number sits closer to fifty — and the forces driving it are structural, not cyclical.

Carrier alliances are standardising API protocols and retiring legacy EDI formats. Customs authorities across Asia, Latin America, and the EU are compressing electronic submission timelines — each jurisdiction with its own data requirements, its own tax authority interface, its own compliance framework. Enterprise shippers are embedding real-time visibility and system-to-system connectivity into their procurement criteria, making integration capability a condition of the commercial relationship rather than a convenience within it.

At the same time, CargoWise is undergoing its most significant integration evolution in over a decade. eAdaptor Next replaces legacy SOAP and Basic Authentication with REST APIs, OAuth 2.0, and certificate-based security — a migration that touches every external connection in the environment. The legacy gateway retires in January 2027.

This convergence — carrier digitisation, regulatory acceleration, customer connectivity demands, and platform migration happening simultaneously — is why integration has moved from an IT workstream to a strategic architecture decision. The question is no longer whether to invest in integration. It is whether the integration architecture running beneath the operation was designed for this level of complexity, or whether it simply accumulated over time.

E2E Messaging: Platform-Native Data Exchange

E2E is the most streamlined integration pathway available within CargoWise — a standardised, pre-built protocol for data exchange between CargoWise environments, maintained and updated by WiseTech Global.

When both parties in a trading relationship operate on CargoWise, E2E eliminates the need for middleware entirely. Shipment data, milestones, and documentation flow between environments through a format that requires:

• No custom mapping or transformation logic

• No third-party infrastructure between sender and receiver

• No ongoing maintenance as the platform evolves

For businesses operating within the CargoWise ecosystem — co-loading partners, network agents, group entities across multiple geographies — E2E delivers governed, platform-native connectivity that scales without engineering overhead.

The boundary is precise: E2E operates exclusively within the CargoWise universe. Where the counterparty runs a different system, a different integration pathway is required.

eAdaptor: The Gateway Between CargoWise and External Systems

Every connection that crosses the boundary between CargoWise and the outside world — ERP and accounting platforms, carrier booking engines, customs submission portals, customer visibility tools, OCR and document capture, government authority interfaces — passes through eAdaptor.

With eAdaptor Next, that gateway is being fundamentally re-engineered:

• Authentication architecture shifts from Basic Auth to OAuth 2.0 with certificate-based security — every external system and middleware layer must be assessed for compatibility

• Credential management changes structurally — each external system requires its own EDI Client configuration; shared credentials are no longer architecturally possible

• Certificate governance becomes an ongoing operational responsibility requiring named ownership, managed renewal cycles, and monitored expiry — a missed certificate renewal is a live integration failure

• Multi-entity environments face a multiplier effect, with EDI Client counts scaling across entities in ways rarely accounted for in initial scoping

This is not a version upgrade. It is a re-architecture of every external touchpoint in the CargoWise environment, with coordination required across every partner, vendor, and system on the other side of each connection.

Middleware: The Orchestration Layer

Middleware sits between CargoWise and external systems, managing the complexity that neither the gateway nor the external application is designed to handle — data transformation, validation, error management, routing, and retry logic across dozens of connections operating simultaneously.

The distinction is architectural. Without middleware, each external integration is a point-to-point connection with its own mapping, its own error handling, and its own maintenance requirements. With middleware, the integration landscape operates as a governed system:

• Data normalisation across carriers, customs platforms, and ERPs that each structure their outputs differently — clean, consistent data entering CargoWise regardless of source

• Centralised monitoring providing a single view of every active integration, every message exchange, every exception — replacing the alternative, which is discovering a broken connection when its downstream consequences surface

• Retry and exception logic managing intermittent failures from government portals, carrier APIs, and third-party platforms — automatically, with logging, before the failure reaches an operational workflow

• Scalable architecture where each new carrier, market, or customer connection extends an existing framework rather than adding another standalone dependency

For operations managing twenty or more external integration points, middleware is not additional complexity. It is the architecture that governs complexity — the difference between an integration landscape that absorbs growth and one that is consumed by it.

Designed Architecture vs. Accumulated Connections

Most CargoWise environments use all three pathways. E2E where both parties are on the platform. eAdaptor where external systems require connectivity. Middleware where the volume, variety, and criticality of external connections demand orchestration.

The differentiator is not which pathways are in use. It is whether the integration architecture was designed with intent — documented, governed, and built to scale — or whether it accumulated organically: one connection at a time, built by different teams, at different stages of the business, with varying levels of documentation and no single point of visibility.

Accumulated architectures carry a specific kind of risk. Integration failures rarely present at their point of origin. A billing discrepancy that traces to a failed data exchange. A compliance exception rooted in a mapping error three systems upstream. A customer escalation caused by a milestone update that never transmitted. The operational teams managing these consequences are often unaware that the root cause is architectural.

Building Integration as a Discipline

SFL Tech has delivered more than 250 integrations across the CargoWise ecosystem — middleware development, API and EDI solutions, custom development, and full software lifecycle management across complex, multi-entity, multi-geography operations.

That depth of delivery is the foundation for an approach that treats integration not as a series of isolated connections, but as a single, governed architecture: every pathway mapped, every connection documented, every authentication framework confirmed, and every exception visible before it becomes an operational problem.

Whether the requirement is navigating the eAdaptor Next migration, consolidating a fragmented integration landscape, or designing the connectivity infrastructure for the next phase of growth — the starting point is the same: full architectural visibility into what exists, what it is doing, and what it should be doing.

Integration is not connectivity. It is orchestration. And orchestration, by definition, is designed.

‍