Shippers, Shipper Teams, and Shipper Users

Overview

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.

Shippers

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:

• Company name and legal information (tax ID, VAT ID)

• Primary business address

• Company-wide settings and configurations

• Pricing models and tariff assignments

ShipperTeams

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:

• Departmental organization (e.g., logistics, procurement)

• Regional divisions

• Functional groups

ShipperUsers

ShipperUsers are individual users who belong to a Shipper organization and can be assigned to specific ShipperTeams. Each user has:

• Personal information (name, contact details)

• Individual access rights and permissions

• Specific roles defining their capabilities within the system

• Personal notification preferences

Orbit Hub Access

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:

Activation Link (Default)

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.

1. The operator creates the ShipperUser in Orbit MissionControl (or via the API with inviteToSetPassword: true)

2. The user receives a branded activation email with a Set Password link

3. The user clicks the link, receives a verification code by email, and sets their own password

4. 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).

Manual Password

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.

Suppressing the Welcome Email

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.

Partial Data Inheritance

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.

How Inheritance Works

• ShipperTeams inherit base company information from their parent Shipper, such as company address and general settings

• Teams can override certain inherited settings with team-specific configurations

• ShipperUsers inherit settings from both their Shipper and assigned ShipperTeam

• Properties and configurations can be set at any level, allowing for flexible customization

Benefits of Partial Inheritance

• Reduces redundant data entry

• Maintains consistency across the organization

• Enables local customisation when needed

• Simplifies management of shared settings

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.

API Access

All these entities can be managed through Orbit's REST API, which provides endpoints for:

• Creating and updating Shippers, Teams, and Users

• Managing relationships between entities

• Configuring settings and properties at each level

• Retrieving entity information and hierarchical relationships