Shippers, Shipper Teams, and Shipper Users
Hierarchical organisation of Shippers, ShipperTeams, and ShipperUsers, including Orbit Hub access, why some order fields are inherited from the address book, and shipper-only visibility.
Hierarchical organisation of Shippers, ShipperTeams, and ShipperUsers, including Orbit Hub access, why some order fields are inherited from the address book, and shipper-only visibility.
Was this article helpful?
Did not find your answer?
Ask Luna, or write to our support team.
Note
A Shipper is the customer a transport is booked for. In Orbit MissionControl you organise each shipper, its teams and people, and its saved locations — and each shipper sees only its own bookings through Orbit Hub.
In Orbit, shippers are organised in a hierarchical structure consisting of Shippers (companies), ShipperTeams (organisational units), and ShipperUsers (individual users). This structure enables efficient organisation and precise control over access rights and operational capabilities.
A Shipper represents a company or business entity that needs to send goods via road transport. Shippers are the top-level entity and contain core company information such as:
ShipperTeams are organisational units within a Shipper entity. Teams help organise users and manage access within the Shipper's organization. Common uses for teams include:
ShipperUsers are individual users who belong to a Shipper organization and can be assigned to specific ShipperTeams. Each user has:
A ShipperUser can optionally be granted access to Orbit Hub, the customer-facing portal where they can independently book and manage transports. When creating a ShipperUser with Hub access, you choose between two account activation modes:
The recommended approach. The ShipperUser is created and receives an activation email with a link to set their own password. No password is shared or transmitted in any communication.
The operator creates the ShipperUser in Orbit MissionControl (or via the API with inviteToSetPassword: true)
The user receives a branded activation email with a Set Password link
The user clicks the link, receives a verification code by email, and sets their own password
After setting the password, the user is automatically signed in to Orbit Hub
This mode ensures that passwords are never included in emails, aligning with security and compliance requirements (e.g., NIS2, TISAX).
The operator sets a password directly during user creation. The password can optionally be included in a welcome email. This mode is available for backwards compatibility but is not recommended for security-sensitive environments.
When using the API, you can set sendWelcomeEmail: false to prevent Orbit from sending any email. The API response includes an activationUrl that you can use to send your own branded communication.
A shipper is the customer a transport is booked for, so in Orbit Hub a shipper sees only its own bookings — its own Orders and Shipments, and never another shipper's. A short list under a shipper account is therefore the portal working as intended, not missing data. For a fuller picture of who sees what across Orbit, see What can each role see in Orbit?
When you open an order or a stop, you may notice that fields such as the contact, the exact loading point, or the opening hours are empty. This is usually because those details are inherited from the shipper's Address Book rather than stored on the booking itself — so they are filled in by reference, and are not missing.
When a booking uses a saved location, Orbit draws its address, contacts, and opening hours from that saved record. If a field looks blank, the information typically lives on the saved location — and often on the specific loading point within it, which can keep its own opening hours. Checking the shipper's address book is the first place to look before treating anything as absent.
To manage these saved locations and the people attached to them, see Managing Locations & Contacts. To set when a location can receive or hand over goods, see Operating Hours for Locations.
Orbit implements a partial data inheritance concept between these entities. This means that certain data automatically flows from parent entities to their children, while allowing for customization at each level.
For example, while a Shipper might set company-wide pricing models, individual teams can have specific rate adjustments, and users within those teams might have personalized notification preferences.
All these entities can be managed through Orbit's REST API, which provides endpoints for:
Note
Orbit's extensive API reference is separated from Orbit Docs and can be found here: Orbit API Reference.
Those details are usually inherited from the shipper's Address Book rather than stored on the order. Open the saved location — and its loading point — to see them. A blank field here means "inherited", not "missing".
No. Each shipper sees only its own orders and shipments in Orbit Hub. Other shippers' bookings are never shown.
In the shipper's Address Book. See Managing Locations & Contacts and Operating Hours for Locations.