WooCommerce 11.0 adds limits and deduplication for product collection-data count requests, with an extension filter for sites that genuinely need a different threshold. A new HTTP 400 can expose a filter extension that sends duplicate or unbounded count work.
Use this for stores with product filters, faceted search, custom blocks, headless catalogs, marketplace extensions, or frontend code that calls the Store API collection-data endpoint.
Quick answer
Record the exact failing request and count payload before changing the limit. Remove duplicate dimensions, batch only the counts the interface can display, and prove server time and database work stay bounded. Raise the limit only for a documented extension case with load evidence.
What to check first
- Capture the failing URL, method, request body, response status, response error code, user action, extension version, and the number of requested counts.
- Use browser network tools and server logs to identify duplicate requests, duplicate dimensions, rapid rerenders, and requests canceled by the browser after the server started work.
- Disable only the suspected filter or block extension on staging and repeat the same category, search, pagination, and filter interaction.
- Reduce the requested dimensions or apply the documented extension filter at a measured threshold, then run concurrent cold-cache and warm-cache tests.
- Confirm the UI handles a 400 as an actionable state instead of an empty catalog, infinite spinner, or retry loop.
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 the failed request | Capture the failing URL, method, request body, response status, response error code, user action, extension version, and the number of requested counts. | One user action produces the expected number of unique collection-data requests. |
| Find duplicate work | Use browser network tools and server logs to identify duplicate requests, duplicate dimensions, rapid rerenders, and requests canceled by the browser after the server started work. | Required filter counts return 200 without an unbounded SQL or latency increase. |
| Isolate the extension | Disable only the suspected filter or block extension on staging and repeat the same category, search, pagination, and filter interaction. | The catalog remains usable when the API intentionally returns 400. |
| Reduce or justify the limit | Reduce the requested dimensions or apply the documented extension filter at a measured threshold, then run concurrent cold-cache and warm-cache tests. | Cold-cache and concurrent tests stay within the site's response-time and database budgets. |
Why this usually happens
- A frontend rerender can send the same count request more than once.
- Filter extensions may request every possible facet even when most are not visible.
- Raising a limit can hide inefficient request design while increasing database load.
- A generic error handler can mistake an intentional 400 for an empty product result.
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 headers.txt -H 'Content-Type: application/json' \
+ -X POST 'https://store.test/wp-json/wc/store/v1/products/collection-data' \
+ --data @collection-data-case.json
# Record response code, error code, requested dimensions, SQL count, and wall time.
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 the failed request
- Find duplicate work
- Isolate the extension
- Reduce or justify the limit
- Test UI and load
Decision rule
Increase the request limit only when the remaining dimensions are necessary, duplicate calls are removed, load tests show acceptable database work, and the site has monitoring for renewed growth.
What to tell the client or owner
Provide the Store API request and response, extension and WooCommerce versions, requested dimensions, network trace, user action, SQL or profiler evidence, cache state, concurrency result, limit value, and UI behavior.
Production verification checklist
- One user action produces the expected number of unique collection-data requests.
- Required filter counts return 200 without an unbounded SQL or latency increase.
- The catalog remains usable when the API intentionally returns 400.
- Cold-cache and concurrent tests stay within the site's response-time and database budgets.
Mistakes to avoid
- Do not raise the limit before inspecting duplicates.
- Do not test only a warm administrator session.
- Do not interpret a 400 response as zero matching products.
- Do not benchmark the endpoint without the real extension and filter set.
Questions teams ask during testing
Why did the error appear only after WooCommerce 11.0?
The release adds explicit request limits and deduplication. Existing extension behavior that was expensive but tolerated can now surface as an HTTP 400.
Is the extension filter a permanent fix?
It can be appropriate for a measured use case, but it should not replace removing duplicate calls or requesting only counts the customer can use.
When HandL WP should help
HandL WP can identify which block or extension creates excess collection-data work, tune the request, and verify catalog behavior under realistic load.
If this is active on a production site, fix WooCommerce Store API 400 errors.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references