WooCommerce 10.8 Broke Your Abandoned-Cart Tracking: The REST API Fix
As of WooCommerce 10.8, the Orders REST API no longer returns checkout-draft orders when you query status=any. Any abandoned-cart tracking that polls the Orders endpoint for draft orders silently stops seeing them. The quick fix is to request status=checkout-draft explicitly. The durable fix is to stop polling the REST API for an in-progress signal and instead capture the checkout event server-side the moment the draft is created, so a single release note can never blind your tracking again.
What changed in 10.8
A one-line release note quietly rewired what your Orders API returns.
Cart abandonment is the single biggest leak in ecommerce: around 70% of carts are abandoned on average, per the Baymard Institute, which makes the checkout-draft order one of the most valuable signals a store has. It’s the record of someone who got most of the way to buying and stopped.
In WooCommerce 10.8, released May 26, 2026, that signal got harder to read. Orders REST API queries using status=any no longer return checkout-draft orders (#63743), according to the WooCommerce Developer Blog. Consumers that relied on draft orders appearing in unfiltered listings now have to explicitly pass status=checkout-draft. Translation: if your integration asked for “all orders” and counted on drafts being in there, they’re gone.
It wasn’t the only REST tightening in the release. PUT requests can no longer convert non-shop_order records into orders (#64050), and guest fulfillment endpoints were hardened against unauthenticated access. The direction of travel is clear: the Orders API is becoming stricter about what it hands back.
As of WooCommerce 10.8, Orders REST API queries using status=any no longer return checkout-draft orders, so polling integrations silently stop seeing them.
You may be interested in: WooCommerce 10.8 also shipped a cleaner product.published webhook
Why this blinds abandoned-cart tracking
The change is invisible until you notice the drafts stopped arriving.
Here’s the thing: this kind of break doesn’t throw an error. Your polling job keeps running, the API keeps returning 200, and the response just quietly contains fewer rows. Nothing fails loudly — the drafts simply stop appearing, and your abandoned-cart numbers drift toward zero without any alarm going off.
The scale makes it worth caring about. WooCommerce runs on roughly 4.5 million live stores, about 8.7% of all websites, per W3Techs, and a large share of them run some flavour of abandoned-cart automation that reads the Orders API. Add that WordPress 6.9 is now the minimum for 10.8 (#65211), so the upgrade tends to arrive as part of a larger maintenance push — exactly when nobody’s watching the cart-recovery dashboard.
The question isn’t whether WooCommerce was right to hide drafts from default queries. They were — drafts are transient sessions, not real orders. The question is whether your tracking assumed a default that just changed underneath it.
| Behaviour | Before 10.8 | After 10.8 |
|---|---|---|
| GET /orders?status=any | Includes checkout-draft | Excludes checkout-draft |
| Retrieving drafts | Implicit via status=any | Requires status=checkout-draft |
| PUT converting other record types | Silently coerced to order | Rejected (#64050) |
| Guest fulfillment endpoint | Unauthenticated read | Hardened access |
The quick fix: one query parameter
If you must keep polling, ask for the drafts by name.
The immediate patch is small. Wherever your integration calls the Orders endpoint expecting drafts, add status=checkout-draft to the query explicitly instead of leaning on status=any. The drafts come back, and your abandoned-cart job sees them again.
That gets you running today. But it’s worth being honest about what you’ve actually done: you’ve patched one specific symptom of a deeper fragility. You’re still polling a transactional API for a behavioural signal it was never designed to broadcast, and the next release note can move the floor again.
The fast fix is to add status=checkout-draft explicitly; the durable fix is to capture the checkout event server-side instead of polling for it.
You may be interested in: Self-hosted vs managed: which WooCommerce event pipeline fits your store
The real fix: stop polling for it
Capture the event when it happens, not by interrogating the database later.
Polling the Orders API for abandoned carts has always been a workaround. You’re scanning a list on a timer, hoping the thing you care about is still in it. A cleaner model captures the checkout intent at the moment the draft is created, server-side, as a first-party event — independent of how the REST API chooses to list things later.
When the signal is captured at the source, a release note that reshuffles default query behaviour can’t touch it. The event already left the building before any listing decision was made. That’s the difference between reading state and recording events.
For WooCommerce stores, Transmute Engine™ captures checkout and order events server-side on your own WordPress infrastructure and forwards them to your analytics and ad platforms. The point isn’t to react faster to the next breaking change; it’s to not depend on default REST behaviour for a signal this valuable in the first place.
Key Takeaways
- The change: WooCommerce 10.8 excludes checkout-draft orders from default status=any REST queries (#63743).
- The impact: polling-based abandoned-cart tracking silently stops seeing drafts — no error, just fewer rows.
- The scale: ~4.5 million WooCommerce stores, with ~70% average cart abandonment making drafts a high-value signal.
- The quick fix: add status=checkout-draft explicitly to your Orders API query.
- The durable fix: capture the checkout event server-side at creation, so release notes can’t blind your tracking.
Not by default. As of 10.8, queries using status=any no longer include checkout-draft orders. You must explicitly pass status=checkout-draft to retrieve them. Integrations that relied on draft orders showing up in unfiltered listings stop seeing them after the upgrade.
Draft orders are transient cart sessions, not real orders, and including them in unfiltered listings bloated results and confused integrations. Excluding them by default makes status=any return placed orders, which is what most consumers actually expect.
The quick fix is to add status=checkout-draft to your REST query so drafts come back. The durable fix is to stop polling the Orders endpoint for an in-progress signal and capture the checkout event server-side when the draft is created, so a release note can’t blind your tracking again.
PUT requests can no longer convert non-order records into orders, guest fulfillment endpoints were hardened against unauthenticated access, and WordPress 6.9 became the minimum requirement. Each can affect polling integrations that read order data.
References
- WooCommerce Developer Blog — WooCommerce 10.8.0 Release Notes (2026). developer.woocommerce.com
- WooCommerce Developer Blog — WooCommerce 10.8: What’s coming for developers (2026). developer.woocommerce.com
- Baymard Institute — Cart Abandonment Rate Statistics (2025). baymard.com
- W3Techs — Usage statistics of WooCommerce (2026). w3techs.com
If abandoned-cart recovery is part of your revenue, don’t leave it hanging on a default query that can change — see how a server-side event pipeline captures checkout intent at the source.