You Sent XML to CargoWise. It Said Nothing Back. Now What?

Push a message into the CargoWise eAdapter and the response is a tracking UUID. Not "processed". Not "rejected". A receipt number.

The Steele Consulting library documentation is candid about the contract: the send "doesn't return message status directly" — you check the CW1 EDI Interchange to find out what actually happened. Success, rejection, or silent mangling: the answer lives inside CargoWise, minutes later, and your integration has to go and get it.

Two facts guarantee nobody else is watching. CW's native logging is limited for integration troubleshooting, and G2 reviewers report CW's customer service running below expectations for integration issues. The watching is yours to build.

The exception dashboard (build it on day one)

The field guidance is blunt: build an exception dashboard from day one — don't wait until production failures force you to. The mechanics:

• Query the CW EDI Interchange for message states (database access or a polling mechanism against the query endpoints).
• Map tracking UUIDs to business identifiers. An ops person staring at 7f3a9c… can do nothing. The same person seeing "booking 20108188 — rejected, schema error" can fix it.
• Persist every failure as one row: raw XML payload, CW's error verbatim, a reason-code tag (schema_error, auth_failure, timeout…), and timestamps. Group by reason code monthly and watch one org's schema error turn out to be most of your failures.
• Let operators replay failed messages from the dashboard after the fix — far more efficient than re-keying.

Even "success" needs forensic parsing

CargoWise's ProcessingLog speaks three verbs for "it worked":

Updated Shipment S00075190 (House Bill='HLCUBC1250952370')
Added Shipment S00075190 (House Bill='HLCUBC1250952370')
[Pending Change] Updating Shipment S00075213 (House Bill='SHIPMENT 1')

CW uses "Updating" when it processes pending changes. A regex that only matched Updated|Added meant S-numbers silently weren't saved for exactly those shipments. Even a green response is data to parse defensively, not a boolean to trust.

Alert on failures — and on silence

The sourced alerting stack: processed-vs-failed metrics, dead-letter queue growth, 3+ consecutive failures (that's systemic, not a bad message), and send→ack latency. Then add the rule no failure metric covers: expected volume. If a flow that averages N messages per hour produces zero, page someone. The absence of messages is a message.

The full system — failure-record schema, correlation IDs end-to-end, operator exception views, and the replay loop — is Chapter 3 of eAdapter in Production. Join the Vol 2 waitlist for early-bird pricing →