Docs
Sign in

Release 2026.10-R9

Updated October 22, 20267 min read

Released October 22, 2026.

Manifest confirmation generates the documents

Confirming a manifest now generates its documents and nothing else. The shipments on it keep their status, and Carriyo doesn't request a pickup from the carrier. Before, confirming moved every shipment to ready_to_ship and asked the carrier for a pickup. Requesting or scheduling a carrier pickup is still available as its own action on shipments. It is no longer tied to confirming the manifest, so you decide when each happens.

  • Carriyo manifest: on confirmation, Carriyo adds its manifest PDF to the manifest's documents right away, and the manifest moves to confirmed.
  • Carrier manifest: for Royal Mail, USPS and DHL eCommerce Americas, the manifest stays pending while Carriyo requests the carrier's own document. That's the Royal Mail container manifest, the USPS SCAN Form or the DHL eCommerce manifest. When it arrives, the manifest moves to confirmed with the carrier document added and the carrier's reference in carrier_manifest_id. If the request fails, the manifest moves to error.
  • Retry: on the Manifests list and the manifest page, Retry replaces Reschedule. It appears only for manifests in error, and asks the carrier for the document again. A Royal Mail retry adds only the shipments that aren't in the container yet, instead of starting over. It also no longer fails when the first attempt created no container.

Via the API: POST /manifests/{manifest_id}/confirm replaces POST /manifests/{manifest_id}/ready-to-ship. The old path still works and returns a Deprecation header, with a Link header pointing to the new path. POST /manifests/{manifest_id}/retry is accepted only for a manifest in error; before, it was accepted from any status. Manifest responses have two new fields, confirmed_date and carrier_manifest_id, and no longer return created_by_user, updated_by_user and cancelled_by_user. Manifest errors now carry the trigger MANIFEST instead of SCHEDULING.

Feed failure alerts

Carriyo can now raise alerts when an inventory feed or product feed fails. Turn them on in Settings > Account > Alerts, under the new alert event Feed Failure. The Carriyo team sets up feeds. When you ask for a new feed, or about an existing one, you can now also ask Carriyo to set up alerting for it. That includes how long an import feed may go without a file.

  • Feed Import Missing is raised when no file has arrived for an import feed within that time, and resolved when a file arrives.
  • Feed Export Failure is raised when a scheduled export can't deliver its file to its destination, and resolved when the next export succeeds.

One alert covers one incident. Later failures add to it, and once it's resolved or dismissed, the next failure opens a new one. On the Alerts Dashboard, a feed alert shows the feed and what went wrong. VIEW opens a new alert details page with the status, the cause, and the first and last failure times. For an export, it also shows the last successful export and the task reference. You can dismiss the alert there or from the list. These alerts are shown to users who can edit connectors.

In the alert email, a feed alert carries a short description and a View incident link to its details page. The Go to Alerts button now opens the Alerts Dashboard of the tenant that raised the alerts.

Products API

Changes to the Carriyo Products API from a review of its contract against the documentation:

  • Deleting a product: DELETE /products/{merchant_id}/{product_id} and DELETE /products/{merchant_id}/product-ref/{product_ref} now work without a request body or Content-Type header. Before, a request without them failed with 500.
  • Merchant access: reading or deleting a product of a merchant outside your credentials' merchant access now returns 403. Before, Carriyo didn't check merchant access on these requests.
  • Status: status: REDACTED is rejected with 400. The product statuses are ACTIVE, INACTIVE and DELETED.
  • Bulk import: the results of POST /products/{merchant_id}/bulk/import come back in request order, so entry n answers item n. Each result names the item's product_id and product_ref. Before, results came in processing order, and the fields were productId and productRef.
  • Request errors: a body that isn't valid JSON, a value outside its type or enum, or a missing required query parameter now returns 400. The message names the problem and the field. Before, these returned 500.
  • Product list: GET /products no longer returns the index-only fields variant_attribute_color, variant_attribute_size, variant_attributes_keyword and custom_attributes_keyword.
  • Reading by product_ref: a product is found by its reference as soon as it's created or its reference changes. The same applies when a bulk import matches existing products by reference. Changing a product's product_ref, or deleting the product, releases the old value for another product to use.
  • Concurrent writes: a write that collides with another write to the same product or product_ref now returns 409 and stores nothing. Retry the request. A bulk import item in the same situation is rejected with a reason starting Processing failed:.

Order allocation ranks locations by distance

The Maximize customer proximity priority, under Settings > Account > Order Management, now ranks locations by their distance to the customer's address:

  1. Locations in the customer's country come first. When at least one location is in the same country, Carriyo leaves out locations in other countries.
  2. Among those, Carriyo measures the distance from the customer's address to each location that has coordinates, and keeps the nearest. Locations within 1 km of the nearest count as equally near, and the next priority decides between them. A location with coordinates outranks one without.
  3. When no location has coordinates, Carriyo matches on city and state, as before.

This fixes a bug where the priority did not rank locations by their distance. Carriyo could choose a location far from the customer over a nearer one.

Security: changing your password needs your current password

When you change your password, you now enter your current password as well as the new one. This applies to Change Password in the Carriyo Dashboard and the Fulfillment App, and to the password dialog on your account page. A wrong current password is rejected and nothing changes.

Carrier updates

  • AxiomX:
    • A new Merchant Order Type setting on the carrier account is sent to AxiomX with every consignment. Choose Same Day, Next Day, 1-4 Hours or Once a Week, or leave it empty to send none.
    • For cash or card on delivery, the amount to collect is now sent on the package as well. On a multi-parcel shipment the whole amount goes on the first package and the others carry 0.
    • Each SKU is linked to the packages that carry it, from the parcel items you send. On a single-parcel shipment every SKU is linked to that parcel. On a multi-parcel shipment without parcel items, no link is sent.
    • The pickup address of a forward shipment is sent as a warehouse address. Reverse shipments keep the facility type.
  • Royal Mail:
    • A new UKIMS Number setting under Registration Numbers on the carrier account. It's sent as the pre-registration number on shipments from Great Britain to Northern Ireland, so the goods can use the green lane. Other shipments don't send it.
    • Reverse shipments now send the pickup address as the return-to-sender address, so the label carries it. Before, Royal Mail printed the shipping location address.
  • Elite: four more tracking codes are recognized. SHA (forwarded to third party agent) moves a forward shipment to in_transit with the reason handed_over_to_partner. INA (consignee address invalid) moves it to failed_delivery_attempt, or a reverse shipment to failed_collection_attempt, with incorrect_address_details. DAT (delivery attempted) moves a forward shipment to failed_delivery_attempt with refused_by_customer. CRR (customer request to return) moves it to ready_for_return.
  • iMile: reverse shipments now follow more iMile events. 500 (out for delivery) moves them to out_for_delivery, 2302 (pick up) to in_transit, and 3300 or operation_return_delivered_scan (return signature) to delivered. PR0404011 (invalid number) moves a reverse shipment to failed_collection_attempt with incorrect_contact_details. PR0393011 (scheduled delivery) and PR0400011 (schedule a pickup) do the same with rescheduled_by_customer. The 1600-PR0404011 and 1600-PR0393011 "Back to DS" events move a shipment, forward or reverse, to failed_delivery_attempt with the matching reason.
  • Parcel: the Parcel Branch setting is removed from Parcel carrier accounts. It wasn't used in bookings.

Fixes

  • USPS SCAN Form mailing date: when the shipments on a manifest have no scheduled collection, the SCAN Form now uses their booking date as the mailing date. Before, it used the next business day.
  • New alerts on the Alerts Dashboard: new alerts are now announced with the standard toast, "You have N new alerts", like new shipments on the Shipments list. Use Refresh to load them. Before, a banner sat over the list. The dismiss actions are now shown only to users who can dismiss alerts.