WooCommerce draft orders are temporary checkout work records, not completed purchases. If your order integration no longer sees them in a broad REST query, first check whether the draft exists at all, then check the requested status. A checkout page visit alone is not proof that a draft order was created.
Check the checkout lifecycle before the API filter
The current WooCommerce order-status documentation explains that a fresh block checkout keeps interaction state in the session and creates its draft when the shopper attempts to place the order. A retry can reuse an eligible pending or failed order. An empty Draft list can therefore be normal for a visitor who only opened checkout or changed a field.
On staging, record a synthetic journey at three points: checkout opened, details entered, and Place Order attempted through the store's test payment path. At each point, note whether an order ID exists and its actual status. If it has already moved to Pending payment, searching only for checkout-draft should not find it. Never force a paid order back to Draft to make a test pass.
Only compare REST filters against a known record with the same ID, status, permissions, and time window. If you cannot retain a draft long enough for inspection in your test setup, document that limit rather than assuming a lower API count is data loss. Keep the stock reservation and cleanup review separate from query visibility.
WooCommerce 10.8 changed REST API behavior so status=any no longer returns checkout-draft orders by default. Integrations that used an unfiltered order list for abandoned-checkout analysis, debugging, support, or cleanup can suddenly show lower counts after an update even though the draft rows still exist. Production sales, financial exports, and fulfillment usually should not include drafts. The diagnostic identifies which workflows genuinely need the status and adds it explicitly without polluting completed-order reporting.
Use this when an API client, dashboard, support tool, cleanup job, or custom integration stops seeing checkout-draft orders after a WooCommerce update.
Quick answer
Confirm the WooCommerce version, endpoint, authentication, HPOS state, requested status, and expected count. Compare the admin draft count with REST status=any and an explicit status=checkout-draft request. Update only the workflows that intentionally need drafts. Keep revenue, fulfillment, CRM, and conversion pipelines limited to business-valid statuses. Repeat the test with HPOS enabled and with the exact pagination and date window used in production.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| status=any | Current REST behavior | Draft excluded |
| status=checkout-draft | Explicit request | Fixture returned |
| Sales export | Paid statuses only | Draft excluded |
| Abandonment tool | Explicit draft scope | Fixture included |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Capture endpoint and expected count | Record the WooCommerce version, REST endpoint, API version, HPOS state, requested status, page size, date range, and caller purpose. | The explicit diagnostic request returns the known draft fixture. |
| Create one draft fixture | Create a known checkout-draft fixture through the Checkout block and record its ID, creation time, customer state, and expected cleanup window. | Sales, fulfillment, CRM, and conversion feeds exclude drafts unless intentionally designed otherwise. |
| Compare default and explicit status | Compare admin, wc_get_orders, REST status=any, explicit checkout-draft, pagination, cache, and permission results for the same fixture. | HPOS, pagination, permissions, and date filters produce expected counts. |
| Classify every caller | Classify each integration as sales, fulfillment, analytics, support, abandonment, cleanup, or debugging before changing its status filter. | The integration contract records the status behavior and WooCommerce version. |
What to check first
- Record the WooCommerce version, REST endpoint, API version, HPOS state, requested status, page size, date range, and caller purpose.
- Create a known checkout-draft fixture through the Checkout block and record its ID, creation time, customer state, and expected cleanup window.
- Compare admin, wc_get_orders, REST status=any, explicit checkout-draft, pagination, cache, and permission results for the same fixture.
- Classify each integration as sales, fulfillment, analytics, support, abandonment, cleanup, or debugging before changing its status filter.
- Retest counts, webhooks, CRM sync, exports, stock, conversion events, and cleanup so drafts enter only the intended path.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Default query, checkout-draft is excluded
curl -sS -u ck_x:cs_x 'https://store.example/wp-json/wc/v3/orders?status=any'
# Diagnostic query, request the internal status intentionally
curl -sS -u ck_x:cs_x 'https://store.example/wp-json/wc/v3/orders?status=checkout-draft'
Why this usually happens
- An integration assumed status=any meant every internal order state forever.
- The caller does not distinguish a checkout work record from a submitted order.
- HPOS or pagination changes are blamed before the versioned status behavior is tested.
- A broad repair adds drafts to revenue, fulfillment, or conversion feeds that should never receive them.
Decision rule
Do not restore drafts to every order query. Add checkout-draft explicitly only to an owned abandonment, support, debugging, or cleanup workflow with a documented retention and privacy purpose.
Production verification checklist
- The explicit diagnostic request returns the known draft fixture.
- Sales, fulfillment, CRM, and conversion feeds exclude drafts unless intentionally designed otherwise.
- HPOS, pagination, permissions, and date filters produce expected counts.
- The integration contract records the status behavior and WooCommerce version.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Capture endpoint and expected count
- Create one draft fixture
- Compare default and explicit status
- Classify every caller
- Retest HPOS and downstream scope
Mistakes to avoid
- Changing production configuration before recording the exact version, failing request, timestamp, and rollback point.
- Treating a clean dashboard or one successful request as proof while the public page, background job, log, stored record, and downstream system remain unchecked.
- Testing a different role, device, locale, order state, form, cache state, or integration path from the one that users actually reach.
- Leaving debug logging, temporary exclusions, duplicate hooks, helper code, test endpoints, or broad permissions active after the verification window.
Questions teams ask during testing
Can I make this change directly in production?
Start with read-only evidence and use staging for code, update, security, checkout, form, or queue changes. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, role, URL, device, locale, cache state, and downstream integration. Compare stored evidence rather than relying on a visual impression.
What evidence should I retain?
Keep UTC time, exact versions, URL or record ID, expected and actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair the WooCommerce order integration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Add privacy and retention to the explicit-status contract
Use the checkout-draft REST privacy and retention guide to map every draft consumer, define allowed statuses, suppress business events, and propagate cleanup to CRMs and warehouses without deleting required submitted-order records.
Helpful references
Checkout lifecycle clarification reviewed October 9, 2026. Original publication date retained.