API-Created CargoWise Jobs Skip the Defaults. Nobody Tells You.
Jobs created via eAdapter do not inherit the org/UNLOCODE defaults the CW UI applies. The defaults engine with four-tier precedence that closes the gap — including when NOT sending a field is the right move.
When an operator creates a shipment in the CargoWise UI, CW applies organisation- and UN/LOCODE-based defaults as they type — transport mode, service type, charge codes. Jobs created via the eAdapter often do not inherit those defaults. The Inbound Service treats your XML as the source of truth: it does not run the UI's default-population logic.
This is a known architectural decision, not a bug: the eAdapter assumes the sender is providing a complete, well-formed record. API messages must be self-contained. The practical consequence: every serious integrator builds a "shadow" reference database of the defaults CW would have applied — with the drift risk that implies.
But CW doesn't leave your input alone either
"No UI defaults" does not mean no server-side rules. The sharpest example is party creation: the org code you send is just a seed. Send DAPPATAE and CW may assign DAPTESDXB1 — and the creation response does not echo back the assigned code. Store your local code and every later sync fails with No match found for [Org. Code: DAPPATAE]. The only way to learn the real code is to search CW by exact name afterwards.
The precise mental model: CW skips default population on API input, but still enforces certain server-side rules — code mapping among them. You own the defaults; CW still owns its master data.
The defaults engine: four precedence tiers
The field recommendation is to build an opinionated "defaults engine" in middleware, maintained as configuration (not hardcode), treated as a first-class component. The design problem is precedence — when several rules could fill a field, which wins? Evaluate top-down; first answer wins:
| Tier | Rule | Production example |
|---|---|---|
| 1 · Explicit | A value in the source data is never overridden | Operator chose a service level → send it |
| 2 · Derived | Compute from other fields in the message | Container mode: air → LSE; ocean → FCL/LCL by service type |
| 3 · Configured | Org/port-keyed config constants | Consol type: always AGT |
| 4 · Omit | Send nothing — let CW's job-template default win | ServiceLevel omitted unless explicitly set |
Tier 4 is the one integrators miss: omitting an element is itself a defaults decision. Sending ServiceLevel would stomp the defaults configured in CW's own job templates — so the mapper deliberately stays silent unless a human chose a value. Send to override; omit to delegate.
And sometimes no value beats any value: for air jobs, never fall back to a booking reference as the waybill number — an invalid AWB in CargoWise causes worse problems than a blank field.
Chapter 6 of eAdapter in Production builds the full engine — master-data sync with drift monitoring, the DOM-CWAF automation fee strategies, and CW's UTC date traps. Get Vol 2 →
Ready to automate your document processing?
Join freight forwarders saving hours every week with CargoMode.
Start for free