How to Search Organisations in CargoWise via eAdapter (The Missing Guide)

You need to look up an organisation in CargoWise programmatically. You try the Universal XML schema that works for shipments. It does not work. You search the documentation for a search endpoint. There is no clear answer.

This is one of the biggest gaps in CargoWise eAdapter documentation: organisation search uses a completely different XML format than everything else, and if you do not know that, you will waste days trying to make Universal XML do something it cannot.

Universal XML Does Not Support Organisation Search

Let us get this out of the way immediately. The Universal XML schema (UniversalShipment, UniversalEvent, etc.) handles shipments, events, milestones, and documents. It does not handle organisation lookups.

To search for organisations, you need Native XML — a different schema format that maps directly to CargoWise's internal data structures.

This is the part that trips up every developer who has only worked with eAdapter's Universal XML for shipment data. The two schemas are fundamentally different in structure, namespaces, and behaviour.

The Native XML Search Request

Here is what an organisation name search looks like:

<?xml version="1.0" encoding="utf-8"?>
<Native xmlns="http://www.cargowise.com/Schemas/Native">
  <Body>
    <OrgHeader>
      <CriteriaGroup>
        <Criteria>
          <Entity>OrgHeader</Entity>
          <FieldName>OrgName</FieldName>
          <Value>ACME SHIPPING</Value>
        </Criteria>
      </CriteriaGroup>
    </OrgHeader>
  </Body>
</Native>

Notice what is different from Universal XML:

Namespace: http://www.cargowise.com/Schemas/Native instead of the Universal namespace
Structure: CriteriaGroup / Criteria pattern instead of the Universal data elements
Field references: Internal field names like OrgName, OrgPK, OrgCode instead of the Universal naming convention

You can also search by organisation code:

<Native xmlns="http://www.cargowise.com/Schemas/Native">
  <Body>
    <OrgHeader>
      <CriteriaGroup>
        <Criteria>
          <Entity>OrgHeader</Entity>
          <FieldName>OrgCode</FieldName>
          <Value>ACMSHIP</Value>
        </Criteria>
      </CriteriaGroup>
    </OrgHeader>
  </Body>
</Native>

The response returns matching organisations with their codes, names, addresses, and related data. Multiple matches are possible — especially for name searches — so your code needs to handle a collection.

Why You Need This: The Org Code Assignment Gap

Here is the scenario that forces every CargoWise integrator to learn Native XML search eventually.

When you create a new organisation via eAdapter, CargoWise assigns the org code through internal mapping rules. Your request does not specify the code — CargoWise generates it based on configuration that varies by instance.

The critical problem: the creation response does not contain the assigned org code.

Read that again. You create an organisation. CargoWise says "success." But the response does not tell you what code it assigned. You need that code to reference this organisation in future shipments.

The only reliable way to get it: search for the organisation you just created.

1. Send org creation XML → CargoWise creates org, assigns code "ACMSHI"
2. Response: success, but no org code in response body
3. Search by name "ACME SHIPPING" → Response includes OrgCode "ACMSHI"
4. Store the code for future shipment references

This search-after-create pattern is not optional. It is the only way to close the loop.

The Address Suppression Pattern

Once you have an org code stored from a previous search, you face another decision every time you reference that party in a shipment: do you send the full address or just the code?

The answer depends on whether the code exists in the target CargoWise instance:

Has org code — Send only the org code and company name. CargoWise looks up the full address from its database. If you also send address fields, CW may try to update the stored address with your data, which is rarely what you want.

<!-- Party with known org code — suppress address fields -->
<OrganizationAddress>
  <OrganizationCode>ACMSHI</OrganizationCode>
  <CompanyName>ACME SHIPPING CO LTD</CompanyName>
</OrganizationAddress>

No org code — Send the company name plus all address fields. CargoWise will attempt to match by name, or create a new local party if no match is found.

<!-- Party without org code — include full address -->
<OrganizationAddress>
  <CompanyName>ACME SHIPPING CO LTD</CompanyName>
  <Address1>123 Port Road</Address1>
  <Address2>Building 4</Address2>
  <City>Sydney</City>
  <State>NSW</State>
  <Postcode>2000</Postcode>
  <Country>
    <Code>AU</Code>
  </Country>
</OrganizationAddress>

Critical rule: always send CompanyName alongside OrganizationCode. If the org code does not exist in the CW database (maybe it was deleted, or you are pointing at a different environment), CargoWise falls back to name matching. Without the name, you get a "No match found" warning and the party field is left blank on the shipment.

Common Mistakes

Sending Universal XML for org search — It silently fails or returns an empty response. No error tells you that you are using the wrong schema.

Assuming org code is stable across environments — An org code in your staging CW instance may not exist in production. Always code defensively with the name fallback.

Not handling multiple search results — Name searches can return dozens of matches. Your code needs a matching strategy: exact match first, then closest match, then prompt for manual selection.

Sending address fields with an org code — CargoWise may overwrite the stored master address with your shipment-level data. This causes data quality issues across the entire system, not just your integration.

The Bigger Picture

Organisation management through eAdapter is one of the trickiest areas of CargoWise integration. The Native XML schema has its own rules for filtering, pagination, and field mapping that are entirely separate from Universal XML. Getting party data right affects every downstream process — customs, transport, invoicing, and compliance.

Our Complete eAdapter Integration Guide covers the full party management lifecycle: creation, search, matching strategies, address suppression logic, and the edge cases around multi-branch organisations that can silently corrupt your data if handled wrong.

Get the Complete Guide →