WooCommerce 10.8 Drops Checkout-Draft Orders From status=any REST Queries
WooCommerce 10.8, released May 19, 2026, excludes checkout-draft orders from REST API queries that use status=any. Any integration, webhook consumer, or tracking pipeline that polls the orders endpoint with status=any to detect new orders will no longer see draft checkout sessions in the response. If your tracking stack depends on catching orders at the draft stage to fire early-funnel events, those events stop firing silently after the update.
What Changed on May 19
One line in the WooCommerce 10.8 changelog. One query behavior change. Every REST API integration that uses status=any now returns different data.
The WooCommerce 10.8 pre-release notes published on the Developer Blog state it directly: “Checkout-draft orders excluded from default order queries: REST API order queries with status=any no longer return checkout-draft orders. Consumers relying on draft orders appearing in unfiltered listings will need to explicitly pass status=checkout-draft.”
Before 10.8, a GET request to /wc/v3/orders?status=any returned every order regardless of status — including checkout-draft orders that represented in-progress checkout sessions. After 10.8, the same query excludes checkout-draft orders entirely. The results look the same. There’s no error. There’s no deprecation warning. The response is just shorter.
This is a correctness change. Checkout-draft orders are not real orders — they’re placeholder records created by the block-based checkout before the customer submits payment. Including them in status=any queries was technically a bug. But it’s a bug that integrations have relied on for years, and fixing it silently changes what those integrations see.
WooCommerce 10.8, released May 19, 2026, changed the REST API orders endpoint so that queries using status=any no longer return checkout-draft orders — integrations must explicitly request the checkout-draft status to see them.
What Checkout-Draft Actually Is
A checkout-draft order exists before the customer clicks “Place Order.” It’s the skeleton record the block checkout creates so it has somewhere to store the cart.
WooCommerce introduced the checkout-draft status alongside the block-based Cart and Checkout blocks. When a customer reaches the block checkout page, WooCommerce creates an order record with status checkout-draft. This order holds the cart contents, billing and shipping addresses, and selected shipping method — everything the checkout needs to calculate totals and prepare for payment processing.
The draft order is not a purchase. The customer hasn’t submitted payment. They may still be filling in their address. They may abandon the page. The draft order exists purely as a data container for the checkout session. When the customer clicks “Place Order” and the payment gateway processes successfully, the order status moves from checkout-draft to pending or processing depending on the payment method. That’s when the real order begins.
The problem: some tracking integrations don’t distinguish between these stages. They poll the orders endpoint, see a new order appear, and fire an event — regardless of whether the order is a draft or a confirmed purchase. Before 10.8, those integrations caught draft orders in status=any queries. After 10.8, they don’t.
You may be interested in: GA4’s New Assists View Is Empty Because Your Store Never Sent the Events
Which Integrations Break
Any integration that polls the REST API orders endpoint with status=any to detect order creation is affected. Any integration that fires on WooCommerce action hooks is not.
The integrations at risk share a pattern: they periodically call the WooCommerce REST API to check for new orders, process them, and fire downstream events. This includes some CRM sync plugins that watch for new orders to create contact records, inventory management tools that poll for order updates, and — critically — some tracking integrations that detect orders via REST API polling rather than PHP action hooks.
| Integration Pattern | Affected by 10.8? | Risk Level |
|---|---|---|
| REST API polling with status=any | Yes — draft orders no longer returned | High if firing events on draft detection |
| REST API polling with specific statuses | No — explicit status queries unchanged | Low |
| WooCommerce action hooks (PHP) | No — hooks fire on PHP action, not REST | None |
| Webhooks configured for order.created | Depends — webhook payload unaffected, but draft vs confirmed distinction matters | Medium |
| Store API (block checkout frontend) | No — Store API handles drafts internally | None |
The failure mode is silence. The integration doesn’t crash. It doesn’t throw an error. It just stops seeing draft orders in its polling results. If it used the appearance of a draft order to fire an “initiate checkout” event or an “add to cart” signal, that event stops firing. The data gap shows up days or weeks later when someone notices the checkout-initiation metric dropped — and by then, the root cause is buried under a WooCommerce core update that nobody flagged.
The Order Type Rejection Change
The same release also changed how the orders endpoint handles non-order IDs. Two breaking changes in one update.
WooCommerce 10.8 includes a second breaking change at the same endpoint: the orders endpoint now rejects PUT updates when the persisted order type is not shop_order. Previously, sending a PUT request to /wc/v3/orders/{id} with a subscription ID or other non-order record would silently convert that record into a regular order, stripping its type-specific data. After 10.8, the same request returns HTTP 400 with error code woocommerce_rest_shop_order_invalid_id.
The same release changed the orders endpoint to reject PUT updates when the persisted order type is not shop_order, returning HTTP 400 instead of silently coercing the record — a correctness fix that breaks integrations relying on the old permissive behavior.
Both changes are correctness fixes. The old behavior was wrong — checkout-drafts should not appear in general order queries, and subscription IDs should not be silently converted to orders. But both changes also break integrations that relied on the old behavior, and neither change produces a loud failure. One returns fewer results. The other returns an error code that may not be surfaced to the store owner.
You may be interested in: Klaviyo Customer Hub Shipped to WooCommerce — Now You Have Two Data Layers
Why Hooks Don’t Break and Polling Does
WooCommerce action hooks fire on PHP events. REST API polling reads database state. The 10.8 change affects the query, not the event.
The woocommerce_payment_complete hook fires when the payment gateway confirms a successful charge. It’s a PHP action hook that triggers directly in the WooCommerce order processing flow. It doesn’t query the REST API. It doesn’t filter by status. It fires because a specific event happened in the codebase — and that event is unchanged in 10.8.
This is the architectural difference between event-driven and poll-driven tracking. Event-driven tracking subscribes to the thing that happened. Poll-driven tracking periodically asks “what’s new?” and infers what happened from the response. When the query changes — as it did in 10.8 — event-driven integrations are unaffected because they never used the query. Poll-driven integrations break because the query was their only data source.
Server-side event capture using WooCommerce action hooks like woocommerce_payment_complete is unaffected by REST API query changes because hooks fire on the PHP action, not through the REST API polling path.
Transmute Engine™ captures WooCommerce conversion events at the action hook layer — woocommerce_payment_complete, woocommerce_order_status_processing, woocommerce_new_order — and routes to GA4, Google Ads, Meta, TikTok, and BigQuery from the PHP event. The WooCommerce 10.8 REST API changes have zero impact on this pipeline because the pipeline never touches the REST API. The event fires because the payment happened, not because a query returned a matching row.
What to Do Now
Audit your tracking stack. Find anything that polls the orders endpoint. Decide whether it needs to see drafts — and if so, add the explicit status parameter.
The fix for integrations that legitimately need to see checkout-draft orders is straightforward: change the REST API query from status=any to explicitly include checkout-draft in the status list. This restores the pre-10.8 behavior for those specific integrations.
But before applying the fix, ask whether the integration should have been seeing drafts in the first place. If a tracking integration was firing a “purchase” event when it detected a draft order, it was already firing too early — the customer hadn’t paid yet. The 10.8 change may have accidentally fixed a pre-existing overcounting problem by hiding the draft orders those integrations shouldn’t have been tracking as conversions.
The audit checklist: Identify every integration, plugin, and custom code that calls the /wc/v3/orders endpoint. Check whether it uses status=any. If it does, determine what it does with draft orders when they appear. If it fires conversion events on draft detection, it was already broken — fix the event trigger, not the query. If it legitimately needs draft visibility for checkout-session analytics, add the explicit status parameter.
For tracking specifically, the most reliable path forward is hook-based event capture. The woocommerce_payment_complete hook fires at the right moment — after payment, not during checkout — and is immune to REST API query behavior changes. Every WooCommerce core update that changes how the REST API filters orders has zero impact on hook-based tracking.
Key Takeaways
- status=any no longer includes checkout-draft: WooCommerce 10.8 excludes checkout-draft orders from REST API queries using status=any. Integrations must explicitly request checkout-draft to see them.
- The failure is silent: No error, no warning. The query returns fewer results. Integrations that relied on draft order visibility stop firing events without any indication of why.
- Two breaking changes in one release: The checkout-draft exclusion and the order-type rejection change both affect the same endpoint. Audit both if you have custom integrations touching the orders REST API.
- Hook-based tracking is unaffected: WooCommerce PHP action hooks fire on events, not queries. woocommerce_payment_complete still fires exactly when it should, regardless of REST API changes.
- Ask whether drafts should have been visible: If an integration was firing conversion events on draft orders, it was already overcounting. The 10.8 change may have exposed a pre-existing measurement error.
REST API order queries using status=any no longer return checkout-draft orders. To see draft checkout sessions, integrations must explicitly pass status=checkout-draft in the query. This is a breaking change for any integration that relied on status=any to capture all order statuses including drafts.
No. WooCommerce PHP action hooks fire independently of the REST API. The woocommerce_payment_complete hook still fires when payment is confirmed, regardless of the REST API query behavior change. Only integrations that poll the REST API orders endpoint are affected.
If your tracking integration fires conversion events by polling the REST API with status=any and catching orders at the draft stage, those events will stop firing for draft orders. If your tracking fires on the woocommerce_payment_complete hook or on the order-received page load, it is unaffected.
Yes. The orders endpoint now rejects PUT updates when the persisted order type is not shop_order, returning HTTP 400 with error code woocommerce_rest_shop_order_invalid_id. Previously it silently coerced non-shop_order records into regular orders, stripping type-specific data.
References
- WooCommerce. “WooCommerce 10.8: What’s coming for developers.” WooCommerce Developer Blog, May 12, 2026. developer.woocommerce.com
- WooCommerce. “Order update API endpoint now rejects non-order IDs in WooCommerce 10.8.” Developer Advisory, May 11, 2026. developer.woocommerce.com
- WooCommerce. “WooCommerce 10.7: Performance, Analytics, and a better Store API.” Developer Blog, April 15, 2026. developer.woocommerce.com
- WooCommerce. “Introducing a New Order Status: checkout-draft.” Developer Blog, November 23, 2020. developer.woocommerce.com
- WooCommerce. “REST API Documentation.” WooCommerce Developer Docs. developer.woocommerce.com
REST API query behavior changes break poll-driven tracking. Hook-based tracking doesn’t care — it fires when the payment happens, not when a query returns a matching row. If you want your WooCommerce conversion pipeline to survive every core update without an audit, talk to Seresa.