Release 2026.09-R3

Released September 5, 2026.

Fulfill or unfulfill a whole order

Two new endpoints act on every fulfillment order in an order at once. You no longer need to look up each fulfillment_order_id first.

• POST /orders/{orderReference}/fulfill fulfills every pending item on the order. Carriyo creates one shipment per fulfillment order. Fulfillment orders with nothing pending are skipped. The optional body takes carrier_account, delivery and ship_zone, which apply to every shipment. The create_draft_shipment and skip_shipping query parameters work as they do on the fulfillment order endpoint.
• POST /orders/{orderReference}/unfulfill undoes every fulfillment on the order and cancels the related shipments.

Both calls return the updated order. Carriyo checks the whole order before it changes anything. The call returns 400 if the order or any of its fulfillment orders is on hold, and fulfill returns 400 when nothing is pending. The order's payment total and cash on delivery amount are split across the new shipments by the value of the items each one carries.

Orders and fulfillment orders by your own reference

Order endpoints now take either identifier in the path. Carriyo matches the value against order_id first, then against your partner_order_reference, and returns 404 if neither matches. The key query parameter is removed, and Carriyo ignores it on requests that still send it.

Fulfillment order endpoints work the same way. The fulfillment order segment of the path takes fulfillment_order_id or your partner_fulfillment_order_reference. If more than one fulfillment order on the order shares that reference, the response is 400.

Creating or updating an order now returns 400 when its partner_order_reference equals an existing order_id. This keeps the two identifiers from pointing at different orders.

Activity for shipments and return requests

The activity timeline, introduced for orders in 2026.07-R1, is now available for shipments and return requests through the API:

• GET /shipments/{shipment_id}/activity
• GET /returns/requests/{return_request_id}/activity

Both take the same page_num, rows_per_page, sort and source parameters as GET /orders/{orderReference}/activity.

All three timelines changed in these ways:

• Customer notifications appear as NOTIFICATION entries, with the channel, recipient, message and delivery status in notification.
• On shipments, customer feedback appears as FEEDBACK entries, with the rating, reasons and comments in feedback.
• source accepts several values separated by commas, such as source=user,api. A new webhook value returns webhook deliveries and retries, which now sit in their own group instead of under system.
• Entries can carry carrier_id for carrier calls, webhook_id for webhook entries, and config_type for entries evaluated against a configuration.

On shipments, creating and confirming a shipment in one call shows a Create Shipment entry followed by a Confirm Shipment entry. Before, both entries read Create Shipment.

Holds on Shopify orders

Order holds, introduced in 2026.08-R5, now cover orders from the Shopify connector. Put on Hold appears on Shopify orders and their fulfillment orders in the Dashboard, and hold rules now apply to Shopify orders too.

While an order is on hold, the merchant can still change it in Shopify. Carriyo does not rebuild the order from Shopify in that case. It marks the order as out of sync instead. The order page shows an Order out of sync with Shopify warning with the reason and the date it was detected. Examples are a fulfillment order split, merged or moved in Shopify, or a fulfillment created in Shopify.

Once an order is out of sync, Carriyo stops applying Shopify's changes to it and stops sending its own changes to Shopify. Cancellations still sync in both directions. The warning stays after the hold is released.

MCP tools for orders

Two new tools for agents using the Carriyo MCP server: fulfill_order and unfulfill_order, matching the new order-level endpoints.

The order and fulfillment order tools no longer take a key input. They accept either Carriyo's ID or your own reference. change_fulfillment_order_location and split_fulfillment_order now take a fulfillment_location object like the API, instead of a location ID.

Fixes

• Order updates: updating an order and sending its current partner_order_reference unchanged no longer fails as a duplicate reference.