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

> The eAdapter Outbound Service accepts exactly one endpoint for everything your instance emits. The relay architecture every multi-system shop ends up building — explained.

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

| Failure                         | Recovery with a relay                                                                |
| ------------------------------- | ------------------------------------------------------------------------------------ |
| Consumer down for 4 hours       | Its queue backs up and drains on recovery. Others unaffected.                        |
| Poison message                  | Lands in that consumer's DLQ with the raw XML attached. Everyone else keeps flowing. |
| A burst of redelivered messages | Dedup at the door absorbs it. Zero duplicates downstream.                            |

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. [Get Vol. 2 and the companion worksheet ($149) →](/eadapter/production-ops?channel=article_relay)