--- title: "Integrated Carriers" description: "How integrated carriers connect Orbit to a carrier's own booking system: direct booking on assignment, automatic status updates and documents, and why they never appear in the marketplace." url: "https://support.pr-4.orbit.do/en/advanced-features/integrated-carriers" locale: "en" lastReviewed: "2026-09-22" --- # Integrated Carriers How integrated carriers connect Orbit to a carrier's own booking system: direct booking on assignment, automatic status updates and documents, and why they never appear in the marketplace. > **Note:** An integrated carrier is a `Carrier` connected to Orbit through the carrier's own booking system. Assigning a `Tour` to an integrated carrier books the transport directly with that carrier. Its people never log into your Orbit apps, and Orbit receives status updates and documents back automatically. ## Overview Most carriers work inside Orbit: their teams respond to offers in Orbit Connect, and their drivers run tours in Orbit Cockpit. An integrated carrier works differently. It runs its own operational system, such as a freight forwarder or parcel network, or another organisation that works in its own Orbit, and Orbit talks to that system directly. When you assign a `Tour` to an integrated carrier, Orbit places the booking in the carrier's system straight away, then keeps the `Tour` up to date as the carrier reports progress. For you as an operator, an integrated carrier behaves like any other `Carrier` in most of Orbit MissionControl. The differences show up exactly where the carrier's own system takes over: dispatching, execution updates, and documents. **Key highlights:** * **Direct booking:** assigning a `Tour` sends the booking straight to the carrier's system; a confirmed assignment means a confirmed booking * **Automatic status updates:** the carrier reports pickup, transit events, and delivery; Orbit updates the `Tour` and its `Shipments` without anyone touching the apps * **Documents from the carrier:** labels, waybills, and proof of delivery arrive on the `Tour` as the carrier produces them * **No marketplace involvement:** integrated carriers never appear in the Orbit Marketplace and cannot receive `Callouts`; you assign them directly * **The carrier stays in control:** drivers, vehicles, and teams are managed inside the carrier's own organisation, not in your Orbit To book another organisation that works in Orbit, see [Orbit Partner Organisations as Carriers](https://support.pr-4.orbit.do/en/advanced-features/orbit-partner-carriers). It covers what the partner prepares and what comes back from the partner's Orbit. ## How integrated carriers differ from native carriers ![Diagram comparing the native carrier flow, which stays inside Orbit end to end, with the integrated carrier flow, where the booking crosses an API boundary into the carrier's own system and status updates and documents flow back automatically.](https://support.pr-4.orbit.do/images/integrated-carriers/flow-comparison.png) A regular carrier in Orbit has `CarrierTeams`, `CarrierUsers`, and `Vehicles`, receives `Callouts` through the [Orbit Marketplace](https://support.pr-4.orbit.do/en/core-features/marketplace), and executes tours in Orbit Connect and Orbit Cockpit. An integrated carrier has none of these, by design: * It carries an **Integrated** tag in the carriers list in Orbit MissionControl, so you can tell the two apart at a glance. * Its detail page shows no teams, users, or vehicles. Its `Tours` remain visible as usual. * It cannot receive `Callouts` and is excluded from every Marketplace view. The only way to dispatch to it is direct assignment. * While a `Tour` is booked with an integrated carrier, the driver, vehicle, and team controls on the `Tour` are disabled. The carrier decides internally who drives and with which vehicle. ## Setting up an integrated carrier You set up an integrated carrier in Orbit MissionControl, on the carrier create page: 1. Create a `Carrier` as usual and turn on the **Integrated Carrier** switch at the end of the form. 2. Choose a **Provider**. Each provider is one supported carrier network. Providers marked with a **Sandbox** tag never move real freight. Use them to rehearse the flow safely. The provider cannot be changed after the carrier is created; to switch providers, create a new `Carrier`. 3. Enter the **Credentials** the provider requires. For DSV, for example, these are your myDSV account details, your MDM customer number, and the API subscription keys issued in the DSV developer portal. 4. Review the provider's **Settings**, for example a default Incoterm applied to bookings without their own delivery terms, or a mapping from your load types to the package types the carrier expects. 5. Select **Test Connection** to check the credentials against the carrier before saving. A sandbox provider reports **Sandbox Responded** instead of a full connection check, since there is no real carrier behind it. 6. Save the carrier. The **What This Integration Can Do** summary on the same page states each provider's capabilities in plain words: whether the carrier reports status automatically, whether bookings can be cancelled or changed after they are made, whether the carrier returns a price, which documents it delivers, which countries it serves, and how many stops it accepts. ![The Integration section of an integrated carrier in Orbit MissionControl, showing the sandbox provider row, the What This Integration Can Do capability summary, the provider settings, the sandbox behaviour toggles, and the Test Connection button.](https://support.pr-4.orbit.do/images/integrated-carriers/setup-integration-section.png) To change the configuration later, open the carrier's detail page and edit the **Integration** section. Stored credentials are never displayed. To rotate one, type the new value; a field left empty keeps the stored value. ### Where DSV credentials come from DSV issues its credentials in two separate places, and you need both: * **myDSV:** the account your DSV contact sets up for you. Its username and password are the credentials Orbit authenticates with. Your MDM customer number belongs to this account as well; leave that field empty and Orbit reads the number from the account when the carrier is created. * **The DSV developer portal** at `developer.dsv.com`: a free self-service registration where you issue the six API subscription keys: access token, booking, tracking, label, webhook, and download. Create all six under the product **Generic APIs for Air, Sea and Rail**; a key issued under any other DSV API product is rejected. Both portals are normally registered with the same username and password, so one set of details usually covers both. They remain two separate accounts: should the passwords ever differ, the myDSV one is what Orbit needs. The subscription keys stay with your own DSV account, which means the API quota and any key rotation are yours to manage. **Test Connection** checks each key on its own and names the one that fails, which is the quickest way to spot a key taken from the wrong portal product. ## Assigning a tour You assign an integrated carrier from the `Tour` detail page in Orbit MissionControl, exactly as you would any other carrier. Two things help you before you commit: * **Feasibility hints in the carrier picker.** Each integrated carrier in the list carries an indicator: a green tick when Orbit knows of no blockers, a yellow warning when something looks risky, and a red mark when the booking would be rejected, for example because the carrier does not serve the destination country or the load exceeds its weight limit. These hints are advisory; the carrier makes the final decision at booking. * **Stop limits per provider.** The **What This Integration Can Do** summary states how many stops a carrier accepts. DSV books point-to-point tours with exactly one `Shipment`, one pickup and one dropoff. An Orbit partner organisation accepts tours with up to 50 stops. ![The carrier picker on a tour in Orbit MissionControl with integrated carriers showing green feasibility ticks, and the tooltip reading: No known blockers. The carrier makes the final decision at booking.](https://support.pr-4.orbit.do/images/integrated-carriers/carrier-picker-feasibility.png) When you assign the carrier, Orbit books the transport immediately: * **If the carrier accepts**, the assignment completes and a **Carrier Integration** panel appears on the `Tour`. * **If the carrier rejects the booking**, Orbit shows a **Carrier Booking Was Rejected** dialogue listing the reasons, such as a missing booking reference, a delivery window spanning more than one day, or an exceeded size limit. Fix the data and try again, or choose another carrier. ![The Carrier Booking Was Rejected dialogue in Orbit MissionControl, stating that the booking could not be completed and listing the reason the carrier refused it.](https://support.pr-4.orbit.do/images/integrated-carriers/booking-rejected-modal.png) If the provider returns its own price and the carrier is configured to use it, the `Tour` is priced with the carrier's returned price instead of the calculated one. ## Following the booking Every `Tour` booked with an integrated carrier carries a **Carrier Integration** panel. While the booking is healthy it stays deliberately quiet: one line naming the provider and the carrier's booking reference, with a copy button for quoting that reference back to the carrier. ![The Carrier Integration panel on a booked tour in Orbit MissionControl, showing the provider name, the carrier's booking reference with a copy button, and the Carrier Documents row with chips for label, waybill, and proof of delivery.](https://support.pr-4.orbit.do/images/integrated-carriers/booking-panel-booked.png) Progress does not appear in this panel. Carrier events advance the `Tour` itself and are recorded in the tour's timeline, so a booking running to plan needs no separate status to read. The panel speaks up only when the booking diverges from the tour: | Booking state | What it means | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `Booked` | The carrier confirmed the booking; execution has not started. Not shown in the panel, because the tour's own status carries it | | `In Transit` | The carrier reported movement. Not shown in the panel, because the tour's own status carries it | | `Exception` | The carrier reported a problem, such as a delay or a failed delivery attempt. Shown as a red badge; the timeline holds the detail | | `Failed` | Orbit could not transmit the booking to the carrier. Shown as a red badge | | `Cancelled` | The carrier cancelled the booking on its side. Shown as a red badge; the `Tour` itself is untouched, so remove the carrier or cancel the `Tour` | Two further rows appear when they apply: * **Carrier Documents:** one chip per document the provider produces (label, waybill, proof of delivery), marked **pending** until it arrives and **not delivered** if the carrier never supplies it. A **Retry** button restarts the retrieval. Documents that do arrive appear in the tour's regular documents section. * **Update Pending at Carrier:** the `Tour` was edited after booking and the change has not reached the carrier yet. See [Changing or removing a booking](#changing-or-removing-a-booking) below. ### How carrier updates move the tour Carrier updates advance the `Tour` and its `Shipments` automatically. A reported pickup sets the `Tour` to `Running`; a reported delivery sets it to `Review Required`, with arrival and departure times filled in from the carrier's data. The carrier can never complete or cancel a `Tour`: reviewing and completing stays with you, and a carrier-reported cancellation only flags the booking as `Cancelled` in the panel. You decide whether to remove the carrier or cancel the `Tour`. ## Changing or removing a booking **Editing a booked tour.** If you change data that was already sent to the carrier, such as an address, a time window or the load, the **Carrier Integration** panel shows an **Update Pending at Carrier** badge. The **What This Integration Can Do** summary states whether a carrier accepts changes to a booking. If it does not, send the change by removing the carrier and assigning it again, or tell the carrier yourself. Select **Acknowledge** once the carrier knows about the change, or if the change does not matter to the carrier. **Removing the carrier.** Some providers do not support cancelling a booking once it is made. In that case, Orbit warns you before the carrier is removed: releasing the `Tour` frees it in Orbit, but the booking at the carrier stays active, and you need to cancel it directly with the carrier to avoid charges. If a booking could not be cancelled, a notice with the booking reference stays on the `Tour` until the situation is resolved. ## Integrated carriers and Auto-Callout [Automatic dispatch](https://support.pr-4.orbit.do/en/advanced-features/auto-callout-automatic-dispatch) treats integrated carriers with the same rule as everything else: no `Callouts`. A `Sequence` can assign an integrated carrier directly, which books the transport just like a manual assignment. If the carrier rejects that booking, the `Sequence` stops rather than silently moving on, and the `Tour` shows a **Carrier Booking Failed** alert with the rejection reasons so you can dispatch it manually. ## Example Julia, an operator at Orion Industries in Berlin, receives an order for two pallets going to a customer in Munich. Instead of offering the `Tour` on the marketplace, she assigns it to the company's DSV carrier directly from the tour page. The picker shows a green tick, meaning no known blockers, and the booking is confirmed within seconds. Overnight, DSV reports the pickup and the `Tour` switches to `Running` on its own. The next afternoon the delivery event arrives, the `Tour` moves to `Review Required`, and the proof of delivery appears in the tour's documents. Julia reviews the timings and completes the `Tour` without anyone at DSV ever opening an Orbit app. ## Technical details Tours created and assigned through the Orbit API follow the same rules: assigning an integrated carrier books the transport, and rejections return the same structured reasons you see in Orbit MissionControl. See the [Orbit API Reference](https://orbit-api.readme.io) for the relevant endpoints and schemas. ## FAQ **Q: Can an integrated carrier receive callouts or appear in the marketplace?** No. Integrated carriers cannot receive `Callouts` and never appear in the Orbit Marketplace. Assign them directly from the `Tour`. **Q: Can I change the provider of an integrated carrier later?** No. The provider is fixed when the carrier is created. Create a new `Carrier` to use a different provider. Credentials and settings can be changed at any time. **Q: Why can't I assign a driver or vehicle to the tour?** The carrier manages drivers, vehicles, and teams in its own system. While a `Tour` is booked with an integrated carrier, those controls are disabled in Orbit MissionControl. **Q: Where do I see what the carrier reported?** In the tour's timeline. Carrier events are recorded there as they arrive, and they move the `Tour` along on their own; the Carrier Integration panel itself only flags a booking that has diverged. **Q: What happens if I edit a tour after it is booked?** The panel shows an **Update Pending at Carrier** badge. If the carrier does not accept changes to a booking, remove the carrier and assign it again to send the changed data, or tell the carrier yourself and select **Acknowledge**. **Q: What happens if the carrier cancels the booking?** The panel shows the booking as `Cancelled`, but the `Tour` itself is untouched. You decide the next step: assign a different carrier or cancel the `Tour`. **Q: Can a tour with several shipments be booked with an integrated carrier?** It depends on the provider. DSV books point-to-point tours with exactly one `Shipment`. An [Orbit partner organisation](https://support.pr-4.orbit.do/en/advanced-features/orbit-partner-carriers) accepts tours with up to 50 stops and 40 `Shipments`. **Q: Can I try the integrated flow without booking real freight?** Yes. Providers marked **Sandbox** simulate the whole flow, including booking, status updates, documents, and even deliberate failures, without any real transport being booked.