DataShift Logo
You can now cancel freight shipments in DataShift
freightproduct updateapishipmentsintegrations

You can now cancel freight shipments in DataShift

Cancel a booked shipment from its detail page, cancel up to 100 at once from the shipment list, or automate it with the new bookings:cancel API scope. This post covers what changed in the portal and the API, and how to add cancellation to your integration.

Sam

Developer

23 September 202610 min read

Freight gets booked by mistake. An order is cancelled after the label prints, a warehouse books the same consignment twice, or a customer changes the delivery address and you rebook. Until now the shipment stayed in DataShift as a live consignment. It showed up in your reports, the tracking sync kept polling it, and it could be manifested by accident.

Starting today you can cancel a shipment in DataShift. You can cancel one shipment from its detail page, select up to 100 on the shipment list, or call the new cancel endpoint from your own system.

Important: the carrier is not notified

None of the carriers we connect to (TNT, Border Express and Team Global Express) offer a cancel API today. When you cancel a shipment in DataShift, the carrier is not told.

So a cancellation does two things. DataShift stops treating the shipment as live, and you still need to deal with the physical freight:

  • Destroy the printed label and take it off the freight. If the carrier collects or scans a labelled item, you may still be invoiced for it.

  • If the shipment was already manifested, the carrier expects that freight. Contact them as well as cancelling in DataShift.

  • If a pickup was booked, cancelling the shipment does not cancel the pickup.

We designed the feature so you can't miss this. The portal asks you to confirm that you will destroy the label. The API requires an explicit acknowledgement field, and every response includes carrierNotified: false.

Which shipments can be cancelled

You can cancel a shipment while it is still with you. Once the carrier has it, you can't. DataShift checks these conditions in order and stops at the first one that blocks the cancellation:

  1. Already cancelled (ALREADY_CANCELLED). There is nothing left to do.

  2. Delivered (DELIVERED). The shipment has already arrived.

  3. In the carrier network (IN_CARRIER_NETWORK). The carrier has collected it, a tracking scan has been recorded after booking, or it is in transit, out for delivery or in exception.

If none of those apply, you can cancel the shipment. You may also see one or both of these warnings:

  • Manifested (MANIFESTED). The shipment was on a manifest already sent to the carrier. You can still cancel it, but you have to acknowledge this warning first.

  • Pickup booked (PICKUP_BOOKED). A pickup booking exists for the shipment. This is shown for information only.

What's new in the portal

Cancel from the shipment detail page

Open any shipment and choose Cancel shipment from the actions menu. This is the overflow menu on desktop and the actions row on mobile. If the shipment can't be cancelled, the option stays visible but is disabled, and hovering over it shows the reason (for example, that it has already been collected).

Cancel in bulk from the shipment list

Select shipments on the Shipments list and choose Cancel shipments. You can cancel up to 100 at a time. If you select more than 100, DataShift takes the first 100 and tells you so.

The cancel dialog

The same dialog handles one shipment or many:

  • When the dialog opens, it checks every selected shipment with the server. Shipments that can't be cancelled are listed at the top with the reason, and they are left out of the cancellation.

  • A carrier warning names the carrier or carriers involved and reminds you that they have not been notified.

  • If any shipment was manifested, a red callout appears with a checkbox you have to tick before you can confirm.

  • If any shipment has a pickup booked, an information note appears.

  • A reason is required (3 to 200 characters). You can also choose a category: Duplicate booking, Booked in error, Order cancelled, Rebooked or Other.

  • A final checkbox, "I will destroy the label(s) for N shipment(s)", enables the confirm button.

When the cancellation finishes, a notification tells you how many shipments were cancelled and which were skipped, with the reason for each skip.

After a shipment is cancelled

  • A Cancelled banner appears at the top of the shipment. It shows when the shipment was cancelled, who cancelled it (a user, or "API key"), and the reason.

  • Label download and print are removed. Cancelled shipments no longer offer a label, so nobody can reprint one by accident.

  • In the shipment list, the status shows Cancelled. Hovering over it shows the tooltip "Cancelled in DataShift, carrier not notified".

  • Tracking sync and manifesting skip cancelled shipments, so they won't end up on your next manifest.

  • Exports include new columns: Cancelled at, Cancelled by and Cancel reason.

  • Every cancellation is written to the audit log with the carrier, consignment number, reason, category, whether it was manifested, and who cancelled it (a user or an API key).

Who can cancel

Cancelling is controlled by a new permission, freight.shipments.cancel. Owners and Admins have it by default. Any role with freight.shipments.manage also has it. If you want other team members to cancel shipments, add the permission to their role under Settings → Roles. Users without it won't see the cancel menu item or the bulk selection.

What's new in the API

A new scope: bookings:cancel

API keys need the new bookings:cancel scope to cancel shipments. bookings:write alone does not give access, because cancelling is a separate and more sensitive action than booking. Add the scope to an existing key, or create a new key, in Freight → Settings → API keys. The scope is marked in red there as a reminder that the carrier is not notified.

Two new endpoints

The base URL is https://datashift.com.au/api/freight. Authenticate with your API key as a Bearer token, as you do for the other freight endpoints.

POST /shipments/cancel/eligibility is a read-only check. It never cancels anything. It accepts bookings:read or bookings:cancel.

  • Request: send the shipments to check as ids, an array of 1 to 100 shipment IDs.

  • Response: a results array with one entry per ID, plus carrierNotified: false.

  • Each result has the shipment id, eligible (true or false) and a warnings array.

  • A blocked shipment also has a code (for example IN_CARRIER_NETWORK) and a readable message explaining why.

  • An eligible shipment can still carry warnings, each with a code (MANIFESTED or PICKUP_BOOKED) and a message.

POST /shipments/cancel cancels the shipments. It requires bookings:cancel. The response contains:

  • cancelled: the IDs this request cancelled.

  • skipped: the IDs that weren't cancelled, each with a code and message.

  • carrierNotified: always false today.

  • warning: a message to pass on to the people handling the freight, telling them to destroy the printed label.

  • manifestedWarning: included only when at least one cancelled shipment had already been manifested.

Request fields:

  • ids: 1 to 100 shipment IDs.

  • reason: 3 to 200 characters. Required.

  • category: optional. One of DUPLICATE, BOOKED_IN_ERROR, ORDER_CANCELLED, REBOOKED or OTHER.

  • acknowledgeCarrierNotNotified: required, and must be exactly true.

  • acknowledgeManifestedIds: the manifested shipments you have acknowledged. This is the recommended option.

  • acknowledgeManifested: a single true that acknowledges every manifested shipment in the request.

Response codes

  • 200 means the request was processed. Check cancelled and skipped. A batch can partly succeed.

  • 400 means the request failed validation (for example, empty ids, more than 100 IDs, a reason outside 3 to 200 characters, or an unknown category).

  • 401 means the API key is missing or invalid.

  • 403 means the key does not have bookings:cancel.

  • 422 with "code": "CARRIER_ACK_REQUIRED" means acknowledgeCarrierNotNotified was missing or not true.

  • 429 means you hit the rate limit. The cancel endpoints share the same per-key freight budget as your other booking calls.

Each skipped ID comes back with one of these codes:

  • NOT_FOUND: the shipment doesn't exist in your account. IDs from other accounts also return this code, never a 404.

  • ALREADY_CANCELLED, DELIVERED or IN_CARRIER_NETWORK: the same blocking rules described above.

  • MANIFEST_ACK_REQUIRED: the shipment is manifested and you didn't acknowledge it.

  • STATE_CHANGED: the shipment changed while the request was running (for example, a tracking update arrived). Check eligibility and try again.

Other API changes

  • Labels: GET/POST /shipments/{id}/label and /shipments/{id}/print now return 409 with "code": "SHIPMENT_CANCELLED" for a cancelled shipment. IDs from other accounts still return 404.

  • Shipment details: shipment responses now include cancelledAt, cancelledByUserId, cancelSource (PORTAL or API) and cancelReason. For shipments that haven't been cancelled, these are null.

The full schemas are in the Freight API reference.

How to add cancellation to your integration

Most integrations cancel a shipment when something upstream is cancelled, such as an order in your ERP, WMS or storefront. Here is the pattern we recommend.

1. Update your API key

Add the bookings:cancel scope to the key your integration uses. You can also create a separate key just for cancellations, so you can see in the audit log which system cancelled each shipment.

2. Store the DataShift shipment ID with your order

The cancel endpoints take DataShift shipment IDs, which are the id returned when you booked. If you only store the consignment number, start storing the shipment ID as well.

3. Check eligibility first (optional, recommended)

If a person makes the decision to cancel, for example a customer service agent in your ERP, call /shipments/cancel/eligibility first and show them any warnings. That way they see "this was already manifested" before they commit. For a fully automated process you can skip this step, because the cancel call re-checks every rule anyway.

4. Cancel and handle the result

Send a POST to https://datashift.com.au/api/freight/shipments/cancel with your API key in the Authorization: Bearer header and a JSON body containing:

  • ids: the shipment IDs to cancel.

  • reason: something traceable, such as "Order 48213 cancelled in ERP".

  • category: for example ORDER_CANCELLED.

  • acknowledgeCarrierNotNotified: true.

  • acknowledgeManifestedIds: only if a person has reviewed manifested shipments (see step 5).

When the response comes back:

  • Mark every ID in cancelled as cancelled in your own system.

  • Work through skipped using the codes in step 5.

  • Treat any response other than 200 as a failure and log the status and body.

5. Handle skipped shipments deliberately

  • ALREADY_CANCELLED means the shipment is already cancelled. Retrying a cancellation is safe: a shipment that is already cancelled comes back as skipped with this code and nothing else changes. You can treat it as a success.

  • MANIFEST_ACK_REQUIRED means a person should look at the shipment. Send it to someone who can contact the carrier, then call cancel again with the ID in acknowledgeManifestedIds. We recommend acknowledging individual IDs rather than sending acknowledgeManifested: true. With individual IDs, a shipment that gets manifested after your check is skipped instead of cancelled without anyone seeing the warning.

  • STATE_CHANGED can be retried after a short delay.

  • DELIVERED or IN_CARRIER_NETWORK means the freight is already with the carrier. Cancelling in DataShift is no longer possible. Handle it with the carrier, for example with a return or a redirect.

6. Tell the warehouse to destroy the label

Every successful response includes a warning string written for the people handling the freight. Show it to them wherever your warehouse team will see it, such as the pick screen, a Slack alert or the order notes. The label should be destroyed before the carrier's next pickup.

What's next

We are working on two follow-ups:

  • Cancelling with the carrier. When a carrier adds a cancel API, we will call it for you. The carrierNotified field already in every response will then return true for those carriers, so your integration won't need to change.

  • Invoice reconciliation. Carrier invoice lines for shipments you cancelled in DataShift will be flagged, so you can dispute a charge for freight that never moved.

Shipment cancellation is available now for all DataShift Freight accounts. If you have questions or want help updating your integration, get in touch.

See DataShift in action.

Book a demo