Order update API endpoint now rejects non-order IDs in WooCommerce 10.8

Starting in WooCommerce 10.8, the order update endpoint (/wc/v3/orders/{id} and the equivalent /wc/v2 route) responds with HTTP 400 and the error code woocommerce_rest_shop_order_invalid_id when the targeted ID does not belong to a shop_order.

Previously, this endpoint accepted any ID and would silently convert non-shop_order records (e.g. shop_subscription) into regular orders on save, dropping their type-specific data. See woocommerce/woocommerce#63936 for the original report.

The same upfront type check has always existed on the v1 endpoint; v2 and v3 now share it.

How can developers tell if they are affected?

You are affected if any code or integration sends update requests to /wc/v2/orders/{id} or /wc/v3/orders/{id} against IDs that are not shop_order records. After upgrading to 10.8, those requests will return:

{
	"code": "woocommerce_rest_shop_order_invalid_id",
	"message": "ID is invalid.",
	"data": {
		"status": 400
	}
}

What action do developers need to take if affected?

• Updating subscriptions: use the REST endpoints registered by WooCommerce Subscriptions (e.g. /wc/v3/subscriptions/{id}) instead of the orders endpoint.

• Auditing past requests: previous update requests to /wc/v2/orders/{id} or /wc/v3/orders/{id} against non-shop_order IDs that returned 200 have already converted those records and stripped their type-specific data.

This change will be included in WooCommerce 10.8, currently scheduled for May 19, 2026.

Related PR: woocommerce/woocommerce#64050