CargoWise Will Only Send Outbound Messages to ONE URL. Here's the Fix.

CargoWise's Outbound Service configuration accepts a single SOAP endpoint URL. Not one per message type. Not one per recipient. One URL, for everything the instance will ever emit.

The setting lives at Maintain > System > Registry > eServices > eAdaptor > Outbound Service URL — and the first integration never notices the constraint. You point the URL at your webhook receiver and move on. The problem surfaces the day a second system needs the same events: accounting wants invoice messages, the customer portal wants milestones, the BI pipeline wants everything. CargoWise offers no fan-out. If you change the URL, you move the entire firehose.

Never point the URL at a business system

The outbound URL is a scarce, load-bearing resource. The moment two consumers exist, whoever owns that endpoint owns everyone's uptime — and repointing it during business hours drops in-flight messages for every downstream consumer at once.

The fix is architectural, not configurational: put a relay you own on the end of that URL, and give every consumer its own feed from the relay.

The relay does four things — and nothing else

1. Receive and acknowledge fast. Unwrap the SOAP envelope, persist the raw XML, return success. Target under a second.
2. Classify. Read the message type (UniversalShipment / UniversalEvent) and routing hints.
3. Queue per consumer. One delivery job per subscribed consumer, on a durable queue (RabbitMQ, SQS, Azure Service Bus — not a cron job and a database table).
4. Deliver with retries. Each consumer gets an independent retry budget (3–5 attempts, exponential backoff) and its own dead-letter queue.

Routing rules belong in a subscription table, not in if statements — a new consumer becomes an INSERT, not a deploy.

What this buys you at 2am

The alternative — every failure mode shared by every consumer through one URL — is how "the portal is down" becomes "accounting is missing invoices" by lunchtime.

Buy or build?

This problem is solved commercially: Complect's eAdapter Relay is purpose-built for it, and Chain.io offers relay-as-a-service with CW connectors. The honest field guidance: smaller forwarders should consider a managed option before building. If you build, use a real message queue with dead-letter support from day one.

Want the full blueprint? Chapter 2 of eAdapter in Production (Vol 2 of the CargoWise eAdapter Series) covers the complete relay architecture — the receive handler, the subscription table, loop prevention, idempotency and replay, and the 12-point go-live checklist. Join the Vol 2 waitlist for early-bird pricing →