WooCommerce 11.0 limits and deduplicates Store API product collection-data count requests, with an extension filter for sites that need to adjust the HTTP 400 threshold. A broken filter panel may therefore be a request-shape or extension-loop problem rather than a catalog outage.
Use this when product filters, layered navigation, category counts, search facets, or a headless storefront starts returning HTTP 400 after WooCommerce 11.0 beta or produces repeated collection-data calls.
Quick answer
WooCommerce 11.0 Store API Collection Data Count Limit 400 Fix should be handled with a narrow evidence-first workflow: capture failing request, count duplicate dispatches, compare versions, then verify the result before making broader changes.
What to check first
- Capture the failing collection-data request URL, method, query parameters, response body, request ID, and initiating script.
- Count identical and near-identical requests during one page load and identify which block, theme, or extension dispatches each call.
- Compare the request count and response on WooCommerce 10.9 and 11.0 staging with the same catalog and filters.
- Disable filter and search extensions one at a time, then inspect any code that changes the count limit or collection parameters.
- Fix duplicate dispatch or oversized request groups before raising a limit, then retest cache and mobile navigation.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture failing request | Capture the failing collection-data request URL, method, query parameters, response body, request ID, and initiating script. | A product archive sends only the expected collection-data requests for its visible filters. |
| Count duplicate dispatches | Count identical and near-identical requests during one page load and identify which block, theme, or extension dispatches each call. | The endpoint returns 200 with accurate counts for desktop, mobile, search, and category views. |
| Compare versions | Compare the request count and response on WooCommerce 10.9 and 11.0 staging with the same catalog and filters. | No custom limit increase is required unless its business case and load test are documented. |
| Isolate extension code | Disable filter and search extensions one at a time, then inspect any code that changes the count limit or collection parameters. | Store API timing and database load remain acceptable with an uncached catalog request. |
Why this usually happens
- Several filter components can ask for the same counts during initial render and state synchronization.
- A React effect or event listener can dispatch again when the first response updates the filter state.
- Extensions can append distinct parameters that prevent otherwise identical requests from being deduplicated.
- Raising the limit can hide a loop and increase Store API, PHP, and database work for every shopper.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D /tmp/collection.headers \
'https://store.example/wp-json/wc/store/v1/products/collection-data?calculate_attribute_counts%5B0%5D=pa_size' \
-o /tmp/collection.json
jq . /tmp/collection.json
# Preserve the exact query and response before changing an extension filter.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture failing request
- Count duplicate dispatches
- Compare versions
- Isolate extension code
- Fix cause and retest
What to tell the client or owner
Provide the request URL, response body, request count, initiator stack, active filters, catalog size, extension isolation result, and any changed limit.
Production verification checklist
- A product archive sends only the expected collection-data requests for its visible filters.
- The endpoint returns 200 with accurate counts for desktop, mobile, search, and category views.
- No custom limit increase is required unless its business case and load test are documented.
- Store API timing and database load remain acceptable with an uncached catalog request.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, 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, fix a WooCommerce Store API regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Extension-specific Store API limit test
If an extension still crosses the guard, use the Store API collection-data HTTP 400 extension test to capture duplicate requests, reduce unused dimensions, measure database work, and justify any limit change.
Verify product search result sets after OR grouping
When product IDs or counts change, run the WooCommerce 11.1 search_products filter regression test across SQL groups, visibility, stock, roles, languages, extensions, caches, and downstream search surfaces.
Helpful references