How each load carries its own handling outcome, how drivers and operators confirm it when departing a stop, and what a failed load means for the shipment.
Load Statuses enable granular tracking of individual loads throughout their transport lifecycle. Orbit records the handling outcome for each load separately — giving you full visibility into what was loaded, unloaded, or left behind at every stop along a tour.
Every Load on a Tour carries its own status that reflects its current position in the transport process. When a driver departs from a stop, they confirm the handling outcome for each load scheduled for pickup or dropoff at that stop, unless your organisation counts pickups as loaded.
Load statuses are visible across the entire Orbit platform — in Orbit MissionControl, Orbit Connect, and Orbit Cockpit — and are included in webhook payloads, making them available to external systems.
Key highlights
Per-load tracking: Each load carries its own status, independent of other loads at the same stop
Driver-confirmed: Statuses are set explicitly by the driver when departing from a stop, ensuring accurate records
Barcode scanning support: Drivers can use the Cockpit barcode scanner to quickly identify and confirm loads
Full history on the Shipment: The Shipment maintains a complete status log across all transport attempts of a load
A note on a successful handover: A load can be collected or delivered with a note, so a difference is recorded without calling the handover a failure
A photograph of every deviation: A failed load and a load completed with a deviation can carry a photograph, and your organisation can make that photograph mandatory
A load progresses through a defined set of statuses as it moves through the transport process:
Status
Description
Routed
The load has been assigned to a Tour but has not yet been handled. This is the initial status.
Loaded
The load was successfully picked up at the pickup stop.
Unloaded
The load was successfully delivered at the dropoff stop.
Not Loaded
The load could not be picked up at the pickup stop (e.g. damaged, missing, or refused).
Not Unloaded
The load could not be delivered at the dropoff stop (e.g. refused by the recipient). It stays on the vehicle.
Carried Back
The load was refused at its dropoff, stayed on the vehicle, and was later put down at one of your organisation's cross-dock hubs. It is no longer aboard and is waiting at that hub.
Returned
The load was moved onto a return shipment, which now carries it. It no longer travels on this transport.
Dropped
The load can never be delivered, either because it cannot be found at all or because it still exists but is no longer deliverable. Nothing carries it onward. Reported through the API as Perished.
The status of a load follows a strict progression:
┌─── Loaded ───┬─── Unloaded │ │Routed ────────────┤ └─── Not Unloaded ─── Carried Back │ └─── Not Loaded
At the pickup stop, a load transitions from Routed to either Loaded (success) or Not Loaded (failure).
At the dropoff stop, a loaded item transitions from Loaded to either Unloaded (success) or Not Unloaded (failure).
Not Loaded and Not Unloaded end the load's progress on that tour: it cannot go further on the same run. They are not the end of the story. An operator can retry the stage, which returns the load to Routed for a fresh attempt, or move it onto a return shipment, after which it reads Returned.
A load refused at its dropoff is a special case, because it never left the vehicle. Before it can be redelivered or returned, Orbit needs to know where it was put down: once it is recorded at a cross-dock hub it reads Carried Back, and the recovery choices follow from there. See the When a Delivery Fails article.
Some goods will never travel again, whatever is attempted: a pallet that has gone bad, or a crate that cannot be found anywhere. Those are dropped rather than retried or returned. A drop is recorded against the single Load it concerns, and creates no onward movement of its own. See the Dropping Goods That Cannot Be Delivered article.
When a load is marked as Not Loaded or Not Unloaded, the driver can optionally provide a reason:
Reason
Description
Load Damaged
The load was found to be damaged and could not be handled.
Load Missing
The load was not present at the expected location.
Load Refused
The load was refused by the receiving party.
Nobody was there
Nobody was there to hand over or take the goods.
Other
A reason not covered by the above options.
In addition to selecting a predefined reason, the driver can enter a free-text comment to provide further context and, in Orbit Cockpit, take a photograph of the load. Because the reason is optional, a failed load may show no reason at all; this is a gap in what was reported, not a fault in the record.
Not every difference is a failure. A pallet can arrive with a dented corner and still be accepted, and a receiver can take part of a quantity without refusing the rest. Recording those as Not Unloaded would say the goods never arrived, which is not what happened. Instead the load is marked Loaded or Unloaded as normal and carries a note describing the difference.
On a successful load, Complete with note offers an optional Deviation:
Deviation
Description
Accepted damaged
The goods were damaged and the receiving party took them anyway.
Packaging damaged
The packaging was damaged, with no indication that the goods themselves were.
Partial quantity
Part of the expected quantity changed hands and the handover still counts as done.
Other
A difference not covered by the above options.
Alongside the deviation, a free-text note can be added, and in Orbit Cockpit a photograph of the load. All three are independent: a note can be left without a deviation, and a deviation without a note. They are optional unless your organisation requires a photograph for every deviation, see Photo Policies.
A note never changes the outcome. The load stays Loaded or Unloaded, the Shipment is unaffected, and nothing waits for an operator. It records what the driver saw, so that a later claim can be answered from the record.
Notes on successful loads appear:
on the stop's load list in Orbit MissionControl, Orbit Connect and Orbit Cockpit, beside the load's status
at the delivery stop in Orbit Cockpit, as a line under the load on the stop's load list, in the load status panel and in the load's details, so the delivering driver sees a difference recorded at loading before handing the goods over. A Shipment carried in several Legs shows every loading on its current route in order, the shipper's pickup first and then each reload at a cross-dock hub. The driver of the next Tour, who takes the load over at a cross-dock hub, sees the same line in the same three places at that pickup stop, with the notes of the earlier loadings and not the one recorded at that stop. At the shipper's pickup there is no earlier loading, so no line appears there. When a load was loaded with a note more than once on its way, each of those loadings has its own line, in route order. The line stays when the delivery fails, and a note the driver adds on delivery is kept as a record of its own. Where the stop asks for a Documented Signature, the Signing Summary shows the recipient the same lines, and the delivery or collection receipt prints them in the load's row: see Documented Signatures & Delivery Receipts
in the review of the Tour in Orbit MissionControl, where the Loads figure counts them and the Findings list names them under For Information, so a tour carrying one is easy to spot without holding up its review. A load handed over with damaged goods or packaging is also named under Check
on the Signing Summary the recipient reads, and on the delivery or collection receipt rendered from it
in Orbit Hub, where the shipper sees the deviation on the load. The free-text note stays internal
in webhook payloads, alongside the load's status
Warning
A note is available only on a successful outcome. On a failed load the failure reason, its comment and the photograph do that job, and a note sent with a failure is ignored.
A photograph taken in the failure modal or in Complete with note attaches to that individual Load at that stop, which is what distinguishes it from the handover photographs taken during a signing ceremony. It is also one of the stop's proofs, so it counts towards a Photo the stop or the Shipment requires.
If a photograph cannot be uploaded, Orbit Cockpit keeps it visible in the modal and offers a retry. When the link was not sent, retry uses the stored photo, so the driver does not need to take it again. If the photo still cannot be linked, the driver can take it again. Where the photograph is optional, confirming while a photo has failed asks the driver to retry or continue without the photo.
Load statuses are updated when departing from a tour stop. This is the operationally meaningful point at which it can be determined whether the planned actions at a stop (loading or unloading specific items) were carried out successfully.
Statuses cannot be updated outside the departure flow — they are tied to the tour advance action.
When a driver initiates a departure from a stop in Cockpit, a load status panel slides up from the bottom of the screen. This panel lists all loads that require handling at the current stop, grouped by action (pickup or dropoff).
For each load, the driver sees:
Two lines: the count, the type and the description, for example 4 × Euro pallet · Printed matter, and below it the reference or, for a load without one, its dimensions and weight
The notes recorded when the load was loaded earlier on its way, where there are any
Two buttons: × to mark the load as failed, and Unloaded or Loaded to mark it as successfully handled
A tap on the row opens the load's details, with its dimensions, weight, reference and route and the status the driver has marked so far.
Marking a load as successful sets the status to Loaded (at a pickup stop) or Unloaded (at a dropoff stop). A line with a pencil then appears under the load: Add a note (optional). Where the load changed hands with a difference worth recording, it opens Complete with note, which adds a deviation, a note and a photograph to that successful outcome without failing it. Once a note is saved, the line shows it.
Marking a load as failed opens a modal where the driver can optionally select a failure reason, add a comment and add a photograph with Add photo. The status is set to Not Loaded (at a pickup stop) or Not Unloaded (at a dropoff stop). The line under the load then shows the reason, or the comment without one, in red. A tap on it opens the modal again to change them.
When a Shipment has more than one load at the stop, the details of each of its loads offer All 3 loads not unloaded, or All 3 loads not loaded at a pickup stop. The button opens the same modal for every load of that shipment at once. A photograph taken there documents every one of those loads: Orbit Cockpit stores it once for each load, so each load carries its own copy.
A "Mark All Successful" button is available for situations where all loads at the stop were handled without issue. This allows drivers to quickly confirm all loads at once while still maintaining explicit per-load records.
The driver must confirm the status of every load in the panel before the departure can proceed. Where your organisation counts pickups as loaded, the panel leaves those pickups out, see Counting Pickups as Loaded.
A load refused earlier on the same tour is still aboard the vehicle. If the tour later calls at one of your organisation's cross-dock hubs, that load appears in the panel again when the driver departs that stop — under its own heading, apart from the work scheduled for the stop, so it is never mistaken for one of the stop's own pickups or dropoffs.
Ticking it records that the goods were put down at that hub, and the load reads Carried Back. Leaving it untouched is equally valid — the driver may be carrying it further — and does not hold up the departure.
These items sit outside the stop's completion count for the same reason: the count covers the work planned for that stop, so confirming it says nothing about cargo that merely arrived on the vehicle. Each refused load stays an explicit choice, and completing the stop never implies that all of it was put down.
Cockpit includes a barcode scanner that serves as a fast alternative to selecting loads from the list manually. When the scanner is active, the driver points the camera at a barcode or QR code on a package. The system identifies the corresponding load and displays a confirmation card. The driver then taps the success or failure button on this card — the same interaction as in the list view.
Scanning identifies the load, but the driver decides the outcome. No status is set automatically by scanning alone.
Tip
The scanner supports the following barcode formats:
QR Code
Code 128
Data Matrix
How barcode matching works:
When a barcode is scanned, the system attempts to identify the corresponding load using the following steps, in order:
Orbit Resource Number (ORN) — If the barcode contains a valid ORN, the load is uniquely identified. This is the recommended approach for labels generated through Orbit's Document Engine (learn more about ORNs here)
Load ID — The scanned value is checked against the IDs of all loads at the current stop.
Load properties — The scanned value is matched against the load reference, description and property fields of loads at the current stop.
If the scanned barcode matches a load at a different stop on the same tour, a message informs the driver which stop the load belongs to. If no match is found at all, an error message is displayed.
When an operator triggers a departure from a stop in Orbit Connect or Orbit MissionControl, a confirmation modal appears. This modal lists all loads at the current stop with a status selector for each.
For each load, the operator can toggle between success and failure. When failure is selected, input fields for a failure reason and an optional comment appear inline. On success the same place offers Complete with note, for a deviation and a note on a load that was handled but not quite as booked. Photographs of an individual load are taken in Orbit Cockpit, so a load failed or completed with a note here has none.
A "Mark All Successful" option and a progress indicator showing how many loads have been confirmed are available. The departure can only be confirmed once all loads have a status.
Cargo refused earlier on the tour is offered here as well, when the stop being departed is one of your cross-dock hubs, and behaves exactly as it does in Orbit Cockpit.
Where the warehouse loads the vehicle, the driver has nothing to confirm at the pickup. For such operations, the loads at a pickup stop can be counted as Loaded without the driver confirming them in Orbit Cockpit.
In Orbit MissionControl, open Settings and select Review.
On the Loading at Pickup card, turn on Count pickups as loaded.
Select Save.
Changing the setting requires permission to edit the company profile; without it, the card shows the current value and cannot be changed. Turn the switch off and save to have drivers confirm every load again.
A pickup load is counted as loaded only when its Shipment requires no Scan at that stop. Dropoffs are always confirmed by the driver. With the setting on, Orbit Cockpit behaves as follows when the driver departs:
Stop
What the driver sees
Only pickups, none requiring a Scan
No load status panel opens. The departure records every load at the stop as Loaded.
Pickups and dropoffs
The panel lists only the dropoffs. When the driver confirms them, the same departure records the pickups as Loaded.
A Shipment requires a Scan
Its loads stay in the panel with the scanner, as without the setting. The other pickups at the stop are still counted as loaded.
At one of your cross-dock hubs, cargo refused earlier on the tour still opens the panel, as described in Cargo carried from an earlier stop. Where the stop asks for a Documented Signature, the Signing Summary shows the counted pickups as loaded.
With automatic stop detection enabled, the counted pickups are never reported as missing. At a stop with only such pickups, Orbit Cockpit records the departure on its own when the driver leaves, with every load Loaded. At a stop with dropoffs, the departure still waits until the driver has confirmed them.
Because no driver confirms the counted pickups, the driver cannot mark one of them as Not Loaded or add a note to it at the pickup. A load that was not loaded after all is marked at its dropoff, as Not Unloaded with the reason Load Missing, or corrected by an operator in Orbit MissionControl, for example by reverting the departure as described in Reverting a single advance.
The setting changes only what Orbit Cockpit asks of the driver. A departure confirmed in Orbit Connect or Orbit MissionControl still lists every load.
Your organisation decides whether a driver must take a photograph. Two settings do this, independently of each other. Each is either optional or mandatory, and a setting nobody has chosen reads as optional.
Setting
When it applies
When it is mandatory
loadDeviationPhotoPolicy
A load marked as failed, with any reason or none, and a load completed with a deviation such as Accepted damaged
Orbit Cockpit asks for a photograph of the load before the driver can confirm the deviation and before the stop can be left
scanExceptionPhotoPolicy
A load the driver confirms by hand with Confirm Manually instead of scanning it
Confirm Manually stays unavailable until a photograph has reached Orbit
While both are optional, Orbit Cockpit offers Add photo and the driver decides.
Confirm in the failure modal stays unavailable until a photograph of the load counts, whatever the reason. In Complete with note the same holds once a deviation is chosen; a note without a deviation needs no photograph. Photo required under Add photo says why. For a whole shipment, the one photograph taken in the modal serves every load.
Confirm without photo is not offered.
The stop cannot be left while a load the driver marked there has a deviation without a photograph. A line above the confirm button of the load status panel names how many deviations lack one, and a tap on it opens the first of them, where the driver can retry the upload or take the photograph again.
A photograph counts from the moment it is taken, while it uploads. It stops counting when its upload fails or is cancelled, for example without a mobile connection, and the stop is held again until the driver retries or takes it again.
Once the driver has left the stop, a photograph that fails afterwards does not hold the driver back, and Orbit never refuses a departure for a missing photograph. A load failed or completed with a note in Orbit Connect, in Orbit MissionControl or through the API carries no photograph either. The review catches these cases: with automatic tour completion, the exception Deviation Photos Are Missing is active by default under a mandatory photograph and keeps such a tour in review, and the review's Findings list names "1 deviation without photo" at the stop. See Automatic Tour Completion and Reviewing a Tour.
Orbit MissionControl has no screen for these two settings. GET /v5/tenant reads them, and PATCH /v5/tenant sets either or both: a setting left out keeps its value. You can also ask Luna, or an AI assistant connected over MCP, to read or change them. A change needs the permission to change your company settings, which the admin role has by default; an API key needs a role with that permission. Orbit agents that work on their own, without a person, cannot change them.
Once statuses have been set, they are visible across the Orbit platform:
Tour detail pages: In Orbit MissionControl, Orbit Connect, and Orbit Cockpit, each completed stop shows the status of its loads with colour-coded indicators. Failed loads display their failure reason and comment, and a load completed with a note displays its deviation and the note. Photographs of a load appear among the stop's proofs, and in the review of the Tour in Orbit MissionControl under the failed or noted load they document. In Orbit Cockpit, a completed stop marks each load with a green check or a red cross and shows the reason or the deviation as a badge under it. A tap on the load opens its details, with the full comment.
Shipment detail pages: In Orbit MissionControl, the loads section of a shipment shows a status badge for each load. Hovering over the badge reveals the full status history, including timestamps and the associated tour.
The shipment timeline also groups a Leg's Load outcomes into its attempt row. Its load count includes only the Loads on that Shipment, so other Shipments carried on the same Tour do not change the quantity shown.
When a tour advance is reverted (undone), the affected loads return to their previous status.
Tip
A load that was marked as Loaded at the reverted stop returns to Routed.
A load that was marked as Unloaded at the reverted stop returns to Loaded.
A load that was marked as Not Loaded or Not Unloaded returns to its previous status as well.
Failure reasons and comments are cleared during reversal, and so are notes recorded on a successful load, including their deviation and comment. A reverted load carries no handling record until it is confirmed again.
When a tour is fully reset, all tracked loads return toRouted, regardless of their current status. All failure information is cleared. The status history on the Shipment is adjusted accordingly to reflect the reset.
Load status updates can be submitted through the Tour Actions API as part of the advance action. The loadStatusUpdates field accepts an array of per-load status updates, each specifying the load ID, the new status, and optionally a failure reason and comment on a failure, or a deviation and a note on a success.
Load statuses are included in webhook payloads for tour and shipment events, making them available to external integrations. Developers should consult the API Reference for detailed schema information and endpoint documentation.
Load Status Tracking on Tours vs. Shipments
Load statuses are tracked in two places, serving different purposes:
On the Tour: Each load carries a single, current status reflecting its state within that tour. This is what the driver and operators see and interact with.
On the Shipment: Each load maintains a status log — a chronological history of all status changes across transport attempts. This provides a complete audit trail and supports shipments carried in stages, where a single shipment may be handled across multiple tours. See the Legs article.
When a load's status changes on a tour, the update is automatically synchronised to the corresponding Shipment's status log.
A failed load does not automatically fail the whole shipment. Orbit works out the shipment's status from where each of its loads has actually got to. A shipment reads Failed when one of its loads has failed and nothing is carrying that load onward.
So a load that fails on one stage of a journey, and is then picked up by a later stage, does not leave the shipment reading Failed. Neither does a load that has been moved onto a return shipment, nor one that has been put down at a hub and is waiting there. And retrying a failed stage clears it too: once the load is waiting to travel again, the shipment recovers on its own, with no status to reset by hand.
A dropped load is the one outcome that does not recover. Nothing is carrying it onward and nothing will, so the shipment closes as undeliverable. Loads on that same shipment that were delivered stay delivered. When no loads remain to move, Orbit MissionControl shows a shipment with delivered loads and failed or dropped loads as Partially Delivered; the stored shipment status remains Failed.
Note
Real World Example:
A driver for Orion Logistics in Amsterdam arrives at a pickup stop with twelve pallets scheduled for loading. Using Orbit Cockpit, the driver initiates the departure and sees all twelve Loads listed in the status panel. Ten pallets are loaded successfully — the driver taps the success button for each. One pallet is damaged and another is missing from the warehouse floor. The driver marks these as failed, selecting "Load Damaged" and "Load Missing" as the reasons and adding a short comment. The dispatcher at Orion's office sees the two failures immediately in Orbit MissionControl, and the associated Shipment reads Failed, flagging it for follow-up. It stays that way until the dispatcher acts: retrying the collection for a fresh attempt, or moving the two pallets onto a return shipment.
The goods were damaged but the receiver took them anyway. Delivered or failed?
Delivered, with a note. Mark the load successful and use Complete with note to record the deviation, a description and a photograph. Marking it Not Unloaded would say the goods never arrived, which would misstate what happened and would leave the Shipment waiting for a recovery it does not need.
Can I make a photograph mandatory for every failed load?
Yes. Set loadDeviationPhotoPolicy to mandatory, through the API or by asking Luna. Orbit Cockpit then asks for a photograph of every failed load and of every load completed with a deviation, before the driver can confirm it and before the stop can be left. See Photo Policies.
The driver took the photograph but cannot leave the stop. Why?
Its upload failed, so it no longer counts. The line above the confirm button names the deviations that lack a photograph; a tap on it opens the first one, where the driver can retry the upload once there is a connection or take the photograph again.
Can drivers skip the loading confirmation at a pickup?
Yes. In Orbit MissionControl, turn on Count pickups as loaded under Settings → Review. The loads at a pickup are then recorded as Loaded when the driver departs. Loads whose Shipment requires a Scan at the stop are still scanned and confirmed by the driver. See Counting Pickups as Loaded.
Can I update a load's status outside of the departure flow?
No. Load statuses are exclusively updated when departing from a stop, as this is the point where handling outcomes are operationally determined.
A load failed. Is that the end of it?
No. An operator can retry the stage, which puts the load back to Routed for a fresh attempt, or move it onto a return shipment to bring it back. Cargo refused at its dropoff takes one step first, because it never left the vehicle: it is put down at a cross-dock hub and reads Carried Back, and the choices follow from there. See the When a Delivery Fails article. Where the goods will never travel again, they are dropped instead of retried or returned.
A refused load is showing at a stop it was not scheduled for. Why?
Because it is still on the vehicle and that stop is one of your cross-dock hubs, so it is somewhere the driver can put it down. It appears under its own heading, separate from the stop's scheduled work, and ticking it is optional: leave it if the driver is carrying it further.
Are load statuses visible in webhooks?
Yes. Tour and shipment webhook payloads include the current load statuses and the full status log, respectively.
Can I use the barcode scanner to update statuses outside of the departure flow?
The barcode scanner within the load status panel is available only during the departure flow. However, Orbit Cockpit also offers a standalone Identify function that allows scanning an Orbit-generated QR code at any time to view information about a load and its associated tour, without updating any statuses.
What barcode formats are supported?
The scanner supports QR Code, Code 128, and Data Matrix formats. For the most reliable identification, we recommend using Orbit Resource Numbers (ORNs) encoded as QR codes on your labels.
