CargoWise Trigger
The CargoWise Trigger starts a workflow when CargoWise — WiseTech Global's logistics execution platform — reports an event. When a shipment is updated or an operational event is raised in CargoWise, CargoWise posts a Universal event to Splice, and this trigger turns it into a workflow execution. Use it to react to CargoWise activity in real time: sync shipments and containers into another system, generate and transmit EDI, update milestones, validate data, or raise exceptions as they happen.
Overview
Use the CargoWise Trigger when you need to:
- React to shipment updates - Start a workflow the moment a CargoWise forwarding shipment or consol changes
- Act on operational events - Respond to CargoWise events (e.g. container/milestone events) as they are raised
- Keep systems in sync - Push shipment, container, and milestone changes from CargoWise into a WMS, ERP, TMS, or data warehouse
- Drive EDI from CargoWise activity - Generate and send EDI (e.g. 214/315/990) in response to CargoWise events
- Act on full shipment data - Shipment update events carry the complete Universal Shipment object, so the workflow can branch and transform without an extra lookup
Endpoint & Setup
The CargoWise Trigger is delivered over the same HTTP ingress as the Webhook trigger. CargoWise posts events to the workflow's public endpoint:
POST https://<your-splice-api-domain>/hook/{workflowId}
Configure CargoWise (via its eAdapter integration) to send events to this URL (copy it from the workflow), then choose which events should start the workflow with the Action setting below. CargoWise delivers events as an eAdapter SendStreamRequest SOAP envelope carrying a compressed UniversalInterchange message; Splice decodes it and unwraps the inner Universal Event or Shipment document, which becomes the trigger's data.
The trigger node itself takes no credential — it only receives the inbound event. If a workflow needs to call back into CargoWise (to fetch related records or push updates), use the CargoWise service node with its own CargoWise credential (Client Url, Username, and Password) for outbound API calls. That credential is not used by, or required for, the trigger.
Configuration
Action (required)
The set of CargoWise events that may start the workflow. Select one or more; only the selected event types trigger a run.
| Event | Value | Fires when |
|---|---|---|
| Event Update | event-update | CargoWise raises an operational event (e.g. a container/milestone event) |
| Shipment Update | shipment-update | A CargoWise forwarding shipment / consol is updated |
There is a single Resource (Event); the Action field selects which of its event types are enabled.
Output
The trigger emits a single output keyed by the node's name, using the { event, data } envelope. The event field is the action value (event-update or shipment-update), and data carries the CargoWise document (the unwrapped Universal Event or Shipment). The two event types use different data shapes, so inspect the captured sample for the events you actually receive before mapping fields downstream.
The trigger output envelope uses event as the discriminator key (e.g. { "event": "shipment-update", "data": { ... } }). The bundled metadata sample labels this field type; the live trigger emits it as event. Branch on event downstream.
Both shapes share a data.DataContext block describing the originating company, branch, department, event type, user, and trigger metadata.
Event Update
event-update delivers a compact operational event. data.DataContext carries the context (including the target type), and the event itself is described by EventType, EventTime, and a ContextCollection of typed key/value references (e.g. container numbers):
{
"CargoWise Trigger": {
"event": "event-update",
"data": {
"DataContext": {
"DataTargetCollection": { "DataTarget": { "Type": "ContainerStock" } },
"Company": { "Code": "EDI", "Country": { "Code": "AU", "Name": "Australia" }, "Name": "Eagle Datamation International" },
"DataProvider": "EDIDATEDI",
"EnterpriseID": "EDI",
"EventBranch": { "Code": "BNE", "Name": "BN - AUBNE" },
"EventDepartment": { "Code": "BRN", "Name": "Branch" },
"EventType": { "Code": "ATH", "Description": "Authorized" },
"EventUser": { "Code": "E", "Name": "CargoWise One Support" },
"ServerID": "DAT",
"TriggerCount": "1",
"TriggerDate": "2018-05-28T10:05:36.193",
"TriggerType": "Manual"
},
"EventTime": "2018-05-29T10:01:36.2",
"EventType": "GIN",
"IsEstimate": "false",
"ContextCollection": {
"Context": [
{ "Type": "ContainerNumber", "Value": "CONT8003017" },
{ "Type": "ContainerNumber", "Value": "CONT8003320" }
]
}
}
}
}
Key fields:
data.EventType- The CargoWise event code (e.g.GIN= Origin Receival from Wharf/Depot).data.EventTime- When the event occurred.data.IsEstimate- Whether the event time is estimated (true/false).data.ContextCollection.Context[]- Typed references for the event; each has aType(e.g.ContainerNumber) and aValue.data.DataContext.DataTargetCollection.DataTarget.Type- What the event targets (e.g.ContainerStock).data.DataContext- OriginatingCompany,EventBranch,EventDepartment,EventType,EventUser, and trigger metadata.
Shipment Update
shipment-update delivers the complete Universal Shipment object under data. It is large and deeply nested; data.DataContext.DataSourceCollection identifies the source records (e.g. the forwarding consol and shipment keys), and the rest of data describes the shipment, its containers, dates, milestones, parties, and transport legs. The sample below is trimmed to show the top-level structure:
{
"CargoWise Trigger": {
"event": "shipment-update",
"data": {
"DataContext": {
"DataSourceCollection": {
"DataSource": [
{ "Type": "ForwardingConsol", "Key": "C00001011" },
{ "Type": "ForwardingShipment", "Key": "S00001048" }
]
},
"Company": { "Code": "EDI", "Name": "Eagle Datamation International" },
"EnterpriseID": "EDI",
"EventType": { "Code": "ATH", "Description": "Authorized" }
},
"ContainerCount": "1",
"ContainerMode": { "Code": "FCL", "Description": "Full Container Load" },
"TransportMode": { "Code": "SEA", "Description": "Sea Freight" },
"ShipmentType": { "Code": "AGT", "Description": "Agent" },
"PortOfLoading": { "Code": "AUSYD", "Name": "Sydney" },
"PortOfDischarge": { "Code": "NZAKL", "Name": "Auckland" },
"VesselName": "ADMIRALENGRACHT",
"VoyageFlightNo": "BL33",
"TotalWeight": "3000",
"TotalVolume": "3",
"ContainerCollection": { "Container": { "ContainerNumber": "CONT3333443", "/* ... */": "..." } },
"DateCollection": { "Date": [ /* ShippedOnBoard, BillIssued, ... */ ] },
"MilestoneCollection": { "Milestone": [ /* DEP, ARV, ... */ ] },
"OrganizationAddressCollection": { "OrganizationAddress": { "/* parties */": "..." } },
"SubShipmentCollection": { "SubShipment": { "/* house shipment detail */": "..." } },
"TransportLegCollection": { "TransportLeg": { "/* legs */": "..." } }
}
}
}
The most commonly used fields are:
data.DataContext.DataSourceCollection.DataSource[]- The source records, each with aType(e.g.ForwardingConsol,ForwardingShipment) and aKey(the CargoWise job number, e.g.S00001048).data.TransportMode/data.ContainerMode/data.ShipmentType- Mode and shipment classification.data.PortOfLoading/data.PortOfDischarge/data.PlaceOfReceipt/data.PlaceOfDelivery- The routing ports/places (each a{ Code, Name }).data.VesselName/data.VoyageFlightNo- The carrying vessel and voyage.data.ContainerCollection.Container- Container detail (number, type, seals, weights, milestones).data.DateCollection.Date[]- Typed shipment dates (e.g.ShippedOnBoard,BillIssued), each withIsEstimateandValue.data.MilestoneCollection.Milestone[]- Milestones withEventCode,Description,ActualDate, andEstimatedDate.data.OrganizationAddressCollection.OrganizationAddress- Parties (consignor, consignee, agents) withAddressTypeand address detail.data.SubShipmentCollection.SubShipment- The house-level shipment(s) under the consol, including packing lines, instructions, and costing.data.TransportLegCollection.TransportLeg- The transport legs, with carrier, ports, and estimated/actual departure and arrival.
A shipment-update event contains hundreds of fields across nested containers, dates, milestones, parties, sub-shipments, and legs — and CargoWise serializes single-item collections as objects but multi-item collections as arrays. Use a Set or Code node early in the workflow to pull out just the fields you need, reference them by path (e.g. {{$json.data.PortOfDischarge.Code}}), and guard against a collection being an object vs. an array.
The optional Raw Body setting, when enabled, stores the decoded event to storage and passes a file reference as the trigger output instead of the inline { event, data } object. Leave it off to receive the parsed JSON envelope shown above.
Example Usage & Common Use Cases
Sync a Shipment into Another System
[CargoWise Trigger] → [Set: map DataSource Key / ports / vessel / containers]
→ [HTTP Request: upsert into WMS]
Generate EDI on a Shipment Update
Action: Shipment Update
[CargoWise Trigger] → [Set: extract shipment fields] → [EDI: build 315] → [AS2 / FTP: send to partner]
React to a Container Event
Action: Event Update
[CargoWise Trigger] → [If: data.EventType == "GIN"]
→ [Set: container numbers from ContextCollection] → [Notify / update record]
Branch on Event Type
[CargoWise Trigger] → [If: event == "shipment-update"]
↓ true ↓ false (event-update)
[Process shipment] [Process event]
Update Milestones Downstream
Action: Shipment Update
[CargoWise Trigger] → [Set: map MilestoneCollection] → [HTTP Request: push milestones to portal]
How It Works
- CargoWise posts an event - CargoWise sends a
POSTto the workflow's/hook/{workflowId}URL when a subscribed event occurs, including the Universal event document. - Match the trigger - The webhook ingress resolves the workflow and selects its trigger node.
- Filter by action - Only events whose type (
event-updateorshipment-update) is enabled in Action start the workflow. - Enqueue - The event envelope (
{ event, data }) becomes the trigger output and a workflow execution is started.
Best Practices
- Select only the events you handle - Enabling just the event types the workflow is built for avoids unnecessary runs.
- Extract early - The shipment payload is deep and verbose; map the handful of fields you need up front so downstream nodes stay readable.
- Handle object-vs-array collections - CargoWise emits a single-item collection (e.g.
Container,Milestone) as an object and multiple items as an array; normalize before iterating. - Make downstream actions idempotent -
shipment-updatecan fire repeatedly for the same job; key downstream updates on theDataSourceKeyso repeats are safe. - Handle event vs. shipment distinctly - Branch on
eventwhenevent-updateandshipment-updateshould do different things. - Guard against missing fields - Optional sections and empty string values are common; don't assume a fixed shape.
Troubleshooting
Common Issues
- No workflow runs on a CargoWise event - Confirm CargoWise's integration points at the correct
/hook/{workflowId}URL, the workflow is active, and the event type is enabled under Action. - A field is missing from
data- CargoWise omits or blanks sections that don't apply to a given shipment/event. Inspect the captured sample for the actual shape and code defensively. - A collection isn't iterating - A single-item collection arrives as an object, not an array. Normalize the collection before looping.
- Outbound CargoWise API call fails - The trigger and the CargoWise API are separate concerns. Verify the CargoWise credential (Client Url, Username, Password) used by the downstream CargoWise service node, not the trigger.
Debugging Tips
- Inspect the captured sample - The trigger output is stored as node sample data on each run; use it to navigate the nested Universal document and build downstream field paths.
- Test with a manual POST - Send a sample
event-update/shipment-updatebody to the URL withcurlto confirm the endpoint and downstream logic before relying on live CargoWise events.
Related
- Webhook - The general-purpose HTTP trigger this node is built on
- CargoWise - The CargoWise service node for outbound calls into CargoWise
- Trigger Nodes - Overview of all available workflow trigger types