Why can Customer and InvoiceRecipient Fields be Empty?

Learn why Customer and InvoiceRecipient fields may be empty in transport drafts and how to resolve this issue.

Orders and TransportDrafts in Orbit support two different ways to store customer information, and these approaches are mutually exclusive:

1. Shipper Reference (Primary Method)

When an Order or TransportDraft references a Shipper entity (along with optional ShipperUser and ShipperTeam), the customer and invoiceRecipient fields remain empty or are automatically populated from the Shipper data.

This is the standard flow for authenticated bookings where the customer exists as a Shipper in the system.

2. Inline Customer Data (Alternative Method)

When an Order or TransportDraft is created without a Shipper reference, the system uses inline customer and invoiceRecipient objects instead.

This approach is used for:

One-time shippers who don't exist in the system
Unauthenticated booking flows (e.g., public Hub bookings)
Manual operator input for ad-hoc customers

Key Points

At the top level, an Order has either a Shipper reference OR inline Customer data – never both as the primary identifier.
Customer and InvoiceRecipient are helper constructs that become redundant when a Shipper is already set.
When a Shipper is selected, the Customer and InvoiceRecipient fields are automatically filled with a combination of Shipper, ShipperTeam, and ShipperUser information.
Empty Customer/InvoiceRecipient fields are normal and expected when a Shipper reference exists.

Orders and TransportDrafts in Orbit support two different ways to store customer information, and these approaches are mutually exclusive:

1. Shipper Reference (Primary Method)

This is the standard flow for authenticated bookings where the customer exists as a Shipper in the system.

2. Inline Customer Data (Alternative Method)

When an Order or TransportDraft is created without a Shipper reference, the system uses inline customer and invoiceRecipient objects instead.

This approach is used for:

One-time shippers who don't exist in the system
Unauthenticated booking flows (e.g., public Hub bookings)
Manual operator input for ad-hoc customers

Key Points

At the top level, an Order has either a Shipper reference OR inline Customer data – never both as the primary identifier.
Customer and InvoiceRecipient are helper constructs that become redundant when a Shipper is already set.
When a Shipper is selected, the Customer and InvoiceRecipient fields are automatically filled with a combination of Shipper, ShipperTeam, and ShipperUser information.
Empty Customer/InvoiceRecipient fields are normal and expected when a Shipper reference exists.

Why can Customer and InvoiceRecipient Fields be Empty?

1. Shipper Reference (Primary Method)Copy Anchor Link

2. Inline Customer Data (Alternative Method)Copy Anchor Link

Key PointsCopy Anchor Link

Related articles

1. Shipper Reference (Primary Method)Copy Anchor Link

2. Inline Customer Data (Alternative Method)Copy Anchor Link

Key PointsCopy Anchor Link

1. Shipper Reference (Primary Method)

2. Inline Customer Data (Alternative Method)

Key Points

1. Shipper Reference (Primary Method)

2. Inline Customer Data (Alternative Method)

Key Points